Develop Reference

Desktop application + SQLite - Version=1.0.65.0 vs. Version 1.0.104.0

I am currently writing a desktop application (nothing hosted in IIS or similar, .NET 4.5.2) which makes use of SQLite and the Entity Provider for SQLite. For this to get it to work in Visual Studio, I had to install the 1.0.65.0 version package from the SQLite site to get the EF6 provider for SQLite inside Visual Studio. This worked as expected ad as far as I understood, this is also the only way this can be done.
For my application, I would like to use the current version which is 1.0.104.0 (again, info from the sqlite page). I have successfully added the Nuget package for this version to my application and when I look into the references tab, I can see System.Data.SQLite, System.Data.SQLite.EF6 and System.Data.SQLite.Linq, all with the version 1.0.104.0 and Specific Version set to True. Copy Local is set to true for all three of them.
So now when I run my application and get to the line:
using (var ctx = new SmtAoiLookupEntities())
{
foreach (var lu in ctx.Lookups.Where(d=>!string.IsNullOrEmpty(d.Aoi)))
{
...
}
}
I get the following error message:
An exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll and wasn't handled before a managed/native boundary
Additional information: Could not load file or assembly 'System.Data.SQLite, Version=1.0.65.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
From this, I understand that my application tries to load version 1.0.65.0, although all my references point to 1.0.104.0. I have absolutely no idea where my application gets the idea that I want to load 1.0.65.0. I even did a find in files to catch any reference to "1.0.65" with absolutely no results.
I used
gacutil -l System.Data.SQLite
to see which Assemblies are stored in the GAC -> Version 1.0.104.0
Now, this appears only to happen when I run the application from within Visual Studio; If I run the application outside Visual Studio as an executable I get a different error when saving the context. It appears that this is an application error and not related to the assembly version problem. I have also tried setting the application to a 32bit application, the issue stays the same.
The main issue: I would like to be able to debug the application inside Visual Studio, otherwise this could become quite cumbersome. Any ideas how I tell Visual Studio not to load the 1.0.65.0 libs?

A project in your solution is still pointing to previous SQLite version. In my case it was the project which file was throwing the error. Making sure every project in the solution has the updated package version solved the problem for me.

VS2012EXPRESS Ado.Net SQLite missing DLL issue

I'm trying to work out how to use ADO.Net Sqlite in VS2012 Express with no luck.
Things im doing from begining:
Starting new project and installing "System.Data.SQLite (x86/x64)" via NuGet for solution.
Adding using System.Data.SQLite; to directives.
Writing simple code like:
SQLiteConnection sql_sck = new SQLiteConnection("Data Source=test.sqlite;Version=3;New=False;Compress=True;");
Everything seems to look okay, VS recognize class names and changes their colors. However after running the program, in the sql_sck... line, exception is raised - about missing dll ?
An unhandled exception of type 'System.DllNotFoundException' occurred in System.Data.SQLite.dll
Additional information: Could not load DLL 'SQLite.Interop.dll': Could not find specified module. (Exception HRESULT: 0x8007007E)
Any ideas how can I make this work ? Is there anything I've done wrong / any steps missing ?

Somewhere Visual Studio will have created SQLite.Interop.DLL. You need to find that DLL and copy it to the same directory as your application's executable.
I usually add Interop DLLs to my project as a reference and flag them for copying to the output directory in order to ensure that others that use the projects don't forget the manual step.

c# app can't find dll in its working directory

I just switched from C++ to C# and I am a bit confused about referencing DLLs.
I have a third party DLL and a simple testing application that uses some of its methods. When I compile the project, everything goes well, but when I run the compiled app on another computer, I've got an error that says that the DLL is missing even though the DLL is in the app's working directory. What's even more strange is that I have access to the source code of another app that is dependent on an older version of this DLL and this app works well.
I've gone through the code and all the solution settings without finding anything really different.
Can you tell me how to reference a .dll from a working dir (Visual Studio 2010)?
Below is the exception:
System.IO.FileNotFoundException was unhandled
Message=Could not load file or assembly 'TIS.Imaging.ICImagingControl32, Version=3.2.4.1146, Culture=neutral, PublicKeyToken=257805929e8b7928' or one of its dependencies. The system cannot find the file specified.
Source=ICtestapp
FileName=TIS.Imaging.ICImagingControl32, Version=3.2.4.1146, Culture=neutral, PublicKeyToken=257805929e8b7928
FusionLog=WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
StackTrace:
at ICtestapp.Form1.InitializeComponent()
at ICtestapp.Form1..ctor()
at ICtestapp.Program.Main()
InnerException:

Here's a good blog post from Suzanne Cook from the .net team on debugging .net loader issues.
http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx
and here's the details on how it loads:
http://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.71).aspx

You have to add the dll as reference in your project references, once you added the library in the reference, when you compile the program the dll will be automatically copied to the compilation output folder unless otherwise specified in the reference properties ...
Then if you copy all items that you will find in the compilation output folder in the new location in the other PC, you should not have any problems.
Check also that the .NET framework installed on the other machine is at least as the same level of the project target ..

This also happens when you copy the debug executables over to another machine. Try compiling in release and moving over.

Build number Mismatch : Problem with Sybase ASE version

I have a C# Console application which references Sybase.Data.AseClient.
dev machine has version 1.15.325 version of dll
UAT has version 1.12.XYXZ
Prod has version 1.15.115
I get the below exception on a machine similar to prod
ERROR 2010-11-11 18:18:23,562 15546ms FxSpotRateServer Main - Error System.TypeInitializationException: The type initializer for 'Sybase.Data.AseClient.AseConnection' threw an exception. ---> Sybase.Data.AseClient.AseException: Build number Mismatch - sybdrvado115a.dll. Expecting build number greater than or equal to '325'. Loaded build number 152.
at Sybase.Data.AseClient.AseConnection.CheckVersion()
at Sybase.Data.AseClient.AseConnection..cctor()
--- End of inner exception stack trace ---
at Sybase.Data.AseClient.AseConnection..ctor(String connectionString)
at Applicationname.ClassName.GetAseConnectionString(String connectionString) in -------------------------------------------------------------------------------------------
I am thinking of doing having a runtime binding configured in my app.config and do this redirection on runtime.
Is there some other way/patterns to dynamically plug in these versions?
Is my approach clean and suggested?

This is not a problem you can fix with a .config file. It is finding an old version of the unmanaged code that actually does the heavy lifting. The name is in the error message, sybdrvado115a.dll. I'd look in c:\windows\system32 first.
You are going to have to update the Sybase provider on that machine to get past this exception. Or find an old version of the managed wrapper somewhere. Upgrading, and getting all machines up to date, is definitely the better solution.

By default, .NET binds to the version of an assembly it was built with under the assumption that it's been tested with that version. By adding a runtime binding configuration, you're telling .NET that you've verified that everything works with the alternate versions. You've basically told .NET, "Trust me. I know what I'm doing." This sounds like the most reasonable approach for your situation. (There are more complex situations whereby you can dynamically load DLLs in code without consideration for assembly version, but that is more for plug-ins or other situations where you don't know the assembly upfront.)

I decided to go with making the DEV machine same as UAT , thus downgrading the version of Sybase Provider I have on DEV machine . UAT and PROD are made same by systems people . I think it better than runtime assembly loads as we will have the transparent DEV environment where people would only use the features that they can run in UAT and PROD. Even though I was doing nothing which could not be down with a lower version of Sybase providers it is safe to have all the environments consistent.
Thanks to every one.

Building for x86 and 'Any CPU'

I am trying to use Microsoft.Jet.OLEDB driver to connect to an access database from my C# application. When I try to open a connection, I get an error: "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine." This is because the driver is only supported on 32 bit machines.
My solution was to change the platform target of the project that references it to x86. If I try to change all of my projects to x86 I get major build problems, so I am leaving them all on 'Any CPU'
Problem now is when I start up in VS, it tells me: "Could not load file or assembly 'MyProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."
I've tried about every configuration I can think of and I just can't quite get it to work. Any tips?

You'll have to switch the whole thing to x86. As you've found, there isn't an x64 driver for Access.
Your other code, if compiled x64, can't use x86 assemblies. You might want to review this question: Can an x64 application use x86 assemblies - and vice versa?
UPDATE
Interestingly, I found the Access Database Engine x64 from MS. You might try to grab that and see if it will work for you. You might also check out this discussion on MSDN.

You do have to switch to 32-bit to use Jet. (Edit: unless you use the new driver a couple of other posters have referenced).
If any one of your projects is using image lists, there is a bug that will cause errors when switching from 64-bit to 32-bit. As I recall you either have to rebuild the image lists from scratch or drop them and use something else instead.
You can find more info here and here.