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.
I'm building a c# program that uses a local SQLite database to manage some simple data.
I am using the NuGet System.Data.SQLite (x64/x86) v1.0.98.0 - downloaded using the package manager console in Visual Studio Community 2015. Windows 7 64-bit.
I've built and debugged my code using the "Any CPU", x64, and x86 settings and it works fine. After I publish any of these versions though, I get the following error:
An unhandled exception of type 'System.DllNotFoundException' occurred in System.Data.SQLite.dll
Additional information: Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The error occurs here:
SQLiteConnection.CreateFile("local-db.sqlite");
sqlite = new SQLiteConnection("Data Source=local-db.sqlite;Version=3;"); //Error on this line
Suggestions that haven't worked:
copying the bin/debug/x64 (and x86) folders (They contain versions of Interop.dll) up one directory
add SQLite.Interop.dll as a project reference (error - can't add as a reference)
add to project as existing item, set property "Copy to output directory = always". (still gets original error)
copying the most recent version of Interop.dll to the System.Data.SQLite directory (the directory referenced by my project)
At the very least, it's not failing to load the .dll but failing to find it. I don't know my way around dll's but it might work if I know where it's looking. Does anyone have a fix for this? There are a handful of related questions but they are either unanswered or don't work for me.
We're trying to set up a Jenkins (build server) job to build our Office add-in based on VSTO. However, I keep getting a strange error that fails the build process after the DLL is copied to the bin directory of the project:
Error 11 The "FindRibbons" task failed unexpectedly.
System.IO.FileNotFoundException:
Could not load file or assembly 'MyAddIn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified.
File name: 'MyAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
So the problem is that the "FindRibbons" task, triggered by the Office add-in build target, has successfully identified the MyAddIn DLL as being an Office Add-In, but is not able to locate and load it!
Any ideas? I'd love to be able to debug the FindRibbons task directly but hooking into and debugging the compile process seems a little extreme...
Here are some observations:
In our build server's Fusion logs for binding the MyAddIn assembly it looks like it's looking in the folder where MSBuild.exe lives (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) and nowhere else.
On my dev machine, there is no Fusion log entry for MyAddIn! But the build process succeeds and Kivo works fine.
On both my dev and build machines I also have Fusion log entries for WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll) and ExplicitBind!FileName=(MyAddIn.dll) which show the binding succeeding.
This error comes up on the build server whether I use Visual Studio or MSBuild from the command line to build the project.
I've ensured that the .NET/MSBuild/VS2012 versions are identical on both my dev machine and the build server and the error still occurs. The only difference seems to be that the build server is running Windows Server 2012 (since it's Azure, and we can't spin up a Windows 7 image).
This has worked for me every time I upgrade Visual Studio - I don't use ribbons.
This worked for my solution, but use at your own risk:
Open the following file in an XML editor (make a backup first): C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (the v10.0 part may be different for you, e.g., it might be v14.0)
Remove the following section:
<FindRibbons AssemblyName="$(AbsolutePathToCustomization)" TargetFramework="$(TargetFrameworkVersion)">
<Output TaskParameter="RibbonTypes" ItemName="RibbonTypesCollection"/>
</FindRibbons>
Replace all occurrences of "#(RibbonTypesCollection)" with the empty string ""
Save the file and restart the visual studio
If you migrated the project from a previous version of Visual Studio, be sure to remove the ExcelLocale1033 and SecurityTransparent attributes from the AssemblyInfo.cs file (as answered by Swati in this other question)
If the project still fails to build, it may be because your .csproj file has some references to msbuild's tasks of previous versions of Visual Studio. I suggest you to create a new empty Excel AddIn project, and uses the msbuild structure of the new project file as base for your project.
I had this problem. It was apparently caused because I changed the "Copy Local" setting on reference "Microsoft.Office.Tools.Common.v4.0.Utilities" from True to False. ISYN. (I sh*t you not)
I had upgraded a project from VS2012 to VS2013 and noticed that that reference was the only one set to "Copy Local = True". So I set it to false, because it was different. This caused the error. Changing it back to True solved it.
I had the same error message and finally found a fix. The problem stemmed from the VSTO project being targeted for .NET 4.0 (it seems this is the minimum for VSTO4), while also referencing an assembly built for .NET 3.5. The real culprit was that I had a class in the VSTO project deriving from an interface defined in the .NET 3.5 assembly that in turn derived from a .NET 3.5 library interface. i.e.,
using System.Xml;
class MyVSTOClass : IMy35AssembyInterface // This caused the error
class MyVSTOClass : IXmlSerializable // This compiled OK
using System.Xml;
interface IMy35AssembyInterface : IXmlSerializable
The fix was to update the .csproj to explicitly reference the older version of System.Xml.dll and System.Data.dll which would otherwise default to 4.0 and conflict with the 3.5 assembly references.
<Reference Include="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Data2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
<Reference Include="System.XML, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Xml2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
For those who need to simultaneously reference both the newer and older versions of a DLL, note that it is in theory possible using:
extern alias XmlDll1
using XmlDll1::System.Xml
See http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx for more info.
This problem can also be caused by adding a reference to an unsigned assembly to a signed/strong named add-in project. In my case I added the RestSharp Nuget package and started receiving this error on build as soon as I referenced RestSharp in code. After some digging I noticed that RestSharp was the only unsigned assembly in the project references. If you have this problem, there are 3 possible solutions:
In the case of RestSharp, I found that there was a signed version available on Nuget - searched for "restsharp signed" and installing that solved the problem.
If you have access to the source code, you can configure Visual Studio to build a signed version of the assembly in the Project Properties page.
If you do not have access to the source code, you can sign the assembly with your own key by following these instructions.
I had the same error and none of the answers from the internet help me fix this problem. The reason why I was getting that error is because I was referencing an assembly of type Console Application. I changed that assembly to be of type ClassLibrary and I did not got that exception any more.
Also I would only get that exception when inheriting from a class that was located on my ConsoleApplication. It took me forever to figure it out.
May be a little late here, but I just resolved this for myself - after following numerous suggestions (via google) all of which did not solve my problem I manually went down the line. Turns out I had compiled a set of libraries with a dependent assembly with a lower version (not the latest). In my main project I also had a reference to this dependency but it was pulled via nuget and was at the latest & greatest version. For some reason VS.NET couldn't figure that out and would completely trip out and drop the error you posted. Once I updated the set of libraries to the latest version of the dependency all worked as normal.
The crazy part is - it worked fine initially and then out of nowhere the issue came about. Hope this helps someone along the way.
After enabling Fusion the output showed that it was looking for the assembly in the msbuild/ folder.
I just encountered this same situation today, futzing around for a bit, restarting VS and then rebooting my machine without any success. Than one warning popped out at me - One of my dependent assemblies was not strong named. Setting that assembly to be strong-named solved the problem.
I had the same issue, and even after reading KKG's answer I could not resolve mine.
It turned out to be much simpler for me, but not less frustrating and time consuming. I was working in a Win8.1 VM which does not ship with .net3.5 by default. My .net4 VSTO4 project was referencing an assembly that requires 3.5 somewhere. The same project compiled find on my other VM which was Server2008 and had 3.5 enabled.
In my case, the cause for this error was the mere existence of a field of a generic value type in the assembly (not kidding), e.g.:
class Foo
{
ImmutableArray<int> foo;
}
Workaround (if the additional indirection is acceptable performance-wise):
Wrap the value type in a reference type. This can be done generically with something like
public sealed class Box<T>
{
public readonly T value;
public Box(T value)
{
this.value = value;
}
}
then foo can be of type Box<ImmutableArray<int>>.
I have experienced this same issue with an add-in for Outlook.
The solution for me was to set Embed Interop Types to True on my reference to Office.dll.
This however caused the add-in to crash during startup with an Access Denied on Microsoft.Office.Interop.Outlook. I fixed that issue by setting Embed Interop Types to True on all references to Microsoft.Office.Interop.Outlook.dll as well.
This error can be caused by a clash of dependency versions. For example:
YourAddIn
-- OtherLibrary v1.3
-- BaseLibrary v1.0
-- BaseLibrary v2.0
If a newer version of BaseLibrary v2.0 is released and updated in your project, however this version introduce a breaking change in your other dependency OtherLibrary, you will see this exception because OtherLibrary is still trying to find the old methods that doesn't exist in newer assembly.
Update OtherLibrary with the latest packages will resolve this clash of dependency versions.
This can also happen if the Microsoft.Office.Tools.Outlook.v4.0.Utilities reference is set to <Private>False</Private>.
<Reference Include="Microsoft.Office.Tools.Outlook.v4.0.Utilities">
<!-- Required for FindRibbons task -->
<Private>True</Private>
</Reference>
I have Visual Studio 2010 solution of 2 projects: c# and c++
c++ project using .net framework libraries and exposes class that is referenced from c# project.
Everything compiles fine and c# project intellisence helps me with methods exposed from c++. But when I try to launch c# project it crashes with exception:
Could not load file or assembly 'c++library.dll' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)
Inner exception is null
I tried to use tdump from command line to see library dependencies but it finishes with line:
Key to section:
ERROR: internal error at 0x42213f with base 0x400000
How can I fix that?
Thank you in advance!
A combination of Fusion logger (guide) and dependency walker should give the answer.
Try to use fuslogvw.exe to get the full details for assembly binds.
When i try to deploy mapped table into database with GenerateSchema..i get the exception:
NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.SQLiteDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> NHibernate.HibernateException: The IDbCommand and IDbConnection implementation in the assembly SQLite.NET could not be found. Ensure that the assembly SQLite.NET is located in the application directory or in the Global Assembly Cache. If the assembly is in the GAC, use element in the application configuration file to specify the full name of the assembly..
I tried to solve this with NHibernate.Driver.SQLiteDriver -> NHibernate.Driver.SQLite20Driver..but did not worked..I added all references for NHibernate, Sqlite..Linfu...
Has anyone idea for solution??
A stab in the dark:
The one thing that always catches me out with SQLite is that it's a mixed assembly; it contains both managed and native code and targets one configuration (typically x86). If you're working on a 64 bit operating system and using the x86 version, then you may be having problems with bitness. Unfortunately, this doesn't produce a useful error message.
Try setting your project to build using x86 and see if that helps. Also, make sure you've got the correct version of SQLite. Some versions ('managed only') don't work out of the box. I use this version (unzip and then use the "System.Data.SQLite.DLL" file from the root directory).
I've run into these problems in the past and it took a bit of trial and error to get it working.