views:

150

answers:

3

I am using Visual Studio 2010 and using web deployment to promote the .Net MVC site to specific environments. I installed Elmah, and it worked great on my DEV environment, but when I pushed TEST, I got exceptions because SQLite was not a good format.

I am not using SQLite in Elmah or otherwise that I know of. I have removed all visible refernces to SQLite, and I have removed the .dll from all configuration bin directories. But it still gets inserted with each build. I realize the exception problem is that SQLite cannot be built for CPU Any, and my environments vary from x86 to x64. But I would prefer SQLite to not even be present.

I have since uninstalled Elmah, and SQLite is still inserted into the \bin directory. I have now re-installed Elmah, and I manually delete the SQLite.dll from \bin after each build. How can I determine what is causing SQLite to be inserted into my \bin after each build?

A: 

Use a text editor with "find-in-files" support to search all your project files for "sqlite". Something must be referencing it.

Sam
Sam, thanks. I did a find in file, but no reference to SQLite was found.
wilk
A: 

I think Visual Studio will detect that SQLite is required by Elmah and copy it if it finds it. In order to achive the same goal as you I removed all SQLite stuff from the Elmah source code and re-built it. It is quite painless thing to do...

Stefan Egli
Cha Ching! Just remove SQLiteErrorLog.cs from the project, build and go. Thanks for the help.
wilk
+3  A: 

If you are not using SQLite then you need to simply remove it from the source location from where you imported the reference. To expand on that, let's assume you downloaded and unzipped ELMAH to the path C:\ELMAH on your local drive. When you added a reference to ELMAH, you probably pointed to one of the platform versions under C:\ELMAH\bin, like C:\ELMAH\bin\net-2.0\Release. From C:\ELMAH\bin sub-directories, remove all other unwanted assemblies and files except Elmah.dll, Elmah.pdb and Elmah.xml. Strictly speaking, you don't even need the latter two but they are nonetheless recommended. Once you've done that, you can add a reference to Elmah.dll to your project in Visual Studio and none of the dependencies will get pulled into your application's bin directory. You may have to delete your bin directory and re-build your project to get rid of a stale copy of System.Data.SQLite.dll from a previous reference. ELMAH will continue to work fine without System.Data.SQLite.dll as long as you do not use Elmah.SQLiteErrorLog as your error log store.

As per other suggestions, you should not have to remove references to SQLite from the ELMAH sources and make a private build.

Atif Aziz
While Stefan's answer accomplishes my objective with little effort, Atif's solution solves the problem without touching the source. This is really what I was looking for. Besides, who am I to argue with Atif when it comes to Elmah.
wilk
While this approach does work it results in VS2010 MSBUILD warning CA0060 if you have code analysis turned on for the project referencing Elmah. I cannot find any way to suppress this warning. So the toss up is: have unnecessary assemblies in my project dependencies, or live with code analysis warnings. I don't like either...
BrettRobi