I have a vb.net solution with a separate project containing a file class to access Azure files and 2 projects. In both I call the file class which contains this code
Dim mascThis as ShareClient
... mascThis is initialized ...
If mascThis.Exists.Value then ... do something ..
In one project this works, in the other I get the message
Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I've seen this problem discussed before (assembly issues), but all projects are in the same solution in to which I added Azure.Storage.Files.Shares 12.8.0 via Nuget and only the "File class" project has a reference to it, the other projects don't.
So what am I missing here?
Please check if any of the below is your case.
Sometimes, we will have the situation where different parts(projects) of our solution depend on different versions of the same DLL i.e; assemblies with the same assembly name.
The error
Could not load file or assembly
'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
suggests , your project is looking for assembly version 4.0.4.1
Work arounds
i. Usually Nuget Package 4.5.3 contains assembly version 4.0.4.1.
Please check if both the projects in your solution can be worked on that assembly version and add that particular version as new version(ex:4.0.4.1) through binding redirect in the project where you are getting error. And keep the old version in place of old version.
Also Right click on the package reference and set 'specific version' to false under its properties
Example:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.6.0" newVersion="4.0.6.0" />
</dependentAssembly>
In this example ,this way of adding specifies that the runtime should use version 4.0.6.0 in the Assembly versions between olderversion range 0.0.0.0-4.0.6.0
Else If above is not the case, the solution might need different versions.
ii.
Right click in the project properties and choose the ApplicationConfiguration file and App.config
Add the following settings in the app.config file.
To configure multiple assemblies with the same name through codeBases.
Sample code for some package say “A” :
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="A " publicKeyToken="3d67ed1f87d44c89" />
<codeBase version="3.0" href="...\A.dll"/>
<codeBase version="5.0" href="...\A.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
iii. See if you could solve that problem by using extern alias.
iv. Binding redirects are added if your app or its components reference more than one version of the same assembly .See Enable or disable autogenerated binding redirects | Microsoft Docs .If you do it manually ,you need to disable under project properties.
Manually you can add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> in csproj file in property group.
Ex:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
References that can be helpful.
SO reference
Referencing Multiple Versions
load same assembly of different version-SO
I have a project in which I'd like to use some of the .NET 4.0 features but a core requirement is that I can use the System.Data.SQLite framework which is compiled against 2.X. I see mention of this being possible such as the accepted answer here but I don't see how to actually achieve this.
When I just try and run my 4.0 project while referencing the 2.X assembly I get:
Mixed mode assembly is built against version 'v2.0.50727' of the runtime
and cannot be loaded in the 4.0 runtime without additional
configuration information.
What "additional configuration" is necessary?
In order to use a CLR 2.0 mixed mode assembly, you need to modify your App.Config file to include:
<?xml version="1.0"?><configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup></configuration>
The key is the useLegacyV2RuntimeActivationPolicy flag. This causes the CLR to use the latest version (4.0) to load your mixed mode assembly. Without this, it will not work.
Note that this only matters for mixed mode (C++/CLI) assemblies. You can load all managed CLR 2 assemblies without specifying this in app.config.
This forum post on the .NET Framework Developer Center. It might provide some insight.
(Add to the app's config file.)
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Depending on what version of the framework you're targeting, you may want to look here to get the correct string:
http://msdn.microsoft.com/en-us/library/ee517334.aspx
I wasted hours trying to figure out why my release targeting .Net 4.0 client required the full version.
I used this in the end:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"
sku=".NETFramework,Version=v4.0,Profile=Client" />
</startup>
Once you set the app.config file, visual studio will generate a copy in the bin folder named App.exe.config. Copy this to the application directory during deployment. Sounds obvious but surprisingly a lot of people miss this step. WinForms developers are not used to config files :).
Using 2.0 and 4.0 assemblies together isn't quite straight forward.
The ORDER of the supported framework declarations in app.config actually have an effect on the exception of mixed mode being thrown. If you flip the declaration order you will get mixed mode error. This is the purpose of this answer.
So if you get the error in a Windows Forms app, , try this, mostly Windows Forms apps.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>
<supportedRuntime version="v2.0.50727"></supportedRuntime>
</startup>
Or if the project is not Windows Form. In a Web project add this to web.config file.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
<supportedRuntime version="v2.0.50727"></supportedRuntime>
</startup>
Was able to solve the issue by adding "startup" element with "useLegacyV2RuntimeActivationPolicy" attribute set.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
But had to place it as the first child element of configuration tag in App.config for it to take effect.
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
......
....
The above didnt work for me (I am working on a web app) - but this did...
Edit the sgen.exe.config file in the folder (I had to create one first);
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools
(There is also one in v7.0 folder, but I didnt need to change that one, I am using VS2012)
The conents of the XML should look like this (same in previous answers)
<?xml version ="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<requiredRuntime safemode="true" imageVersion="v4.0.30319" version="v4.0.30319"/>
</startup>
</configuration>
If your are working in a web service and the v2.0 assembly is a dependency that has been loaded by WcfSvcHost.exe then you must include
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
in ..\Microsoft Visual Studio 10.0\Common7\IDE\ WcfSvcHost.exe.config file
This way, Visual Studio will be able to send the right information through the loader at runtime.
I ran into this issue when we changed to Visual Studio 2015. None of the above answers worked for us. In the end we got it working by adding the following config file to ALL sgen.exe executables on the machine
<?xml version ="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
</configuration>
Particularly in this location, even when we were targeting .NET 4.0:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools
I used this config:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v2.0"/>
<supportedRuntime version="v4.0"/>
</startup>
Worked for me
I had this problem when upgrading to Visual Studio 2015 and none of the solutions posted here made any difference, although the config is right the location for the change is not. I fixed this issue by adding this configuration:
<startup useLegacyV2RuntimeActivationPolicy="true">
</startup>
To: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\TE.ProcessHost.Managed.exe.config
Then restarted Visual Studio.
I found a way around this after 3-4 hours of googling. I have added the following
<startup selegacyv2runtimeactivationpolicy="true">
<supportedruntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client" />
</startup>
If this doesn't solve your problem then--> In the Project References Right Click on DLL where you getting error --> Select Properties--> Check the Run-time Version --> If it is v2.0.50727 then we know the problem.
The Problem is :- you are having 2.0 Version of respective DLL.
Solution is:- You can delete the respective DLL from the Project references and then download the latest version of DLL's from the corresponding website and add the reference of the latest version DLL reference then it will work.
I was experiencing this same error, and spent forever adding the suggested startup statements to various config files in my solution, attempting to isolate the framework mismatch. Nothing worked. I also added startup information to my XML schemas. That didn't help either. Looking at the actual file that was causing the problem (which would only say it was "moved or deleted") revealed it was actually the License Compiler (LC).
Deleting the offending licenses.licx file seems to have fixed the problem.
I was facing a similar issue while migrating some code from VS 2008 to VS 2010
Making changes to the App.config file resolved the issue for me.
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"
sku=".NETFramework,Version=v4.0,Profile=Client" />
</startup>
</configuration>
Add following at this location C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64
FileName: sgen.exe.config(If you dont find this file, create and add one)
<?xml version ="1.0"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
</configuration>
Doing this resolved the issue
I Use
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
It's works but just before de </configuration> tag otherwise the startup tag doesn't work properly
Also i had this issue with the class library, If any one have the issue with the class library added to your main application. Just add
<startup useLegacyV2RuntimeActivationPolicy="true">
to you main application which would then be picked by the class library.
I am currently using the Microsoft BCL Async library (here) across a project with a large number of interdependent assemblies all compiled against .NET 4 Full Profile, I have had to use assembly binding redirect in each project to get it to compile (as per issue 2 here).
The problem I now have is that I consume one of these libraries from a C++/CLR DLL project, it does not actually need to use async but I have the following compilation error:
2>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3268: The primary reference "ImInterface.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "ImInterface.dll" or retarget your application to a framework version which contains "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
I have added the same app.config file that I have used in all of the C# projects but it does not seem to be having any effect in the C++ project. Do I have to place it in a specific directory or perform any other steps to enable the app.config file to be recognised?
The content of my app.config file is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.11.0" newVersion="2.5.11.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.11.0" newVersion="2.5.11.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Any suggestions are appreciated!
Regards,
Anthony
I had the same problem and as it turned out, <SpecificVersion>True</SpecificVersion> helped.
Before you continue reading, note that the problem seems to only happen when the C++/CLI project is built using the "Visual Studio 2012 - Windows XP (v110_xp)" platform toolset! That is if you don't need to create a DLL which is compatible with WinXP, switch to "Visual Studio 2012 (v110)" instead and you should be fine.
Let me elaborate my scenario:
I have a C++/CLI console application project (ConsoleAppCLI) targeted for WinXP (v110_xp). ConsoleAppCLI references a library (AsyncLib) which has Microsoft.Bcl.Async installed via NuGet:
[ConsoleAppCLI.vcxproj] (C++/CLI, .NET 4.0 v110_xp)
|
|
[AsyncLib.csproj] (C#, .NET 4.0)
|
|
[Microsoft.Bcl.Async] (via NuGet)
I had the exact same problem and the app.config didn't help either, but what did help was the following:
Unload ConsoleAppCli.vcxproj
Edit the vcxproj File directly
Find the reference to the library which has the Async nuget package installed (in my case, a <ProjectReference> to AsyncLib.csproj)
Between <ProjectReference> and </ProjectReference>, ADD THE FOLLOWING: <SpecificVersion>True</SpecificVersion>
Note however, that ConsoleAppCLI was my top-level project in the dependency tree. If you have Assemblies which depend upon the C++/CLI assembly which produced MSB3268, you likewise have to add <SpecificVersion>True</SpecificVersion> to the reference (e.g. if i had an additional C# library which has ConsoleAppCli as dependency, i would have to make the reference to ConsoleAppCli <SpecificVersion>True</SpecificVersion> as well).
This solution is coming from over here, by the way.
I am trying out Fluent NHibernate 2.12 with System.Data.SQLite (ver 1.0.74.0 with .NET4 x64).
When trying to create my session factory I get the following error (innermost exception):
The IDbCommand and IDbConnection implementation in the assembly
System.Data.SQLite could not be found. Ensure that the assembly
System.Data.SQLite 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.
Tried what was already suggested
my app.config looks like this:
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" >
<probing privatePath="Lib\NHibernate;Lib\Castle;Lib\SQLite"></probing>
<qualifyAssembly
partialName="System.Data.SQLite"
fullName="System.Data.SQLite, Version=1.0.74.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" />
</assemblyBinding>
</runtime>
</configuration>
and My private probing path contains the correct files (already checked that)
anyone has a clue?
I just recently set up fluent nhibernate with SQLite for unit tests so here are some tips I can give you.
If you are debugging with Visual Studio 2010 you will need to use SQLite 32 bit sadly. There is a known bug that should be included with the next release of visual studio when you try to include 64 bit assemblies.
Other than that might I suggest you make sure you have included the following entries in your web config.
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
PS found a reference to the bug
http://connect.microsoft.com/VisualStudio/feedback/details/556670/could-not-load-file-or-assembly-error-when-referencing-a-64-bit-assembly
I have a custom Task that I want to execute when building my C# projects. This task is located in MyTask.dll, which references another assembly, MyCommon.DLL.
The problem is that MyCommon.dll is located at "..\Common\MyCommon.dll" relative to MyTask.dll, which puts it outside the AppBase dir for MSBuild process. I've confirmed that this is indeed the problem by analyzing MSBuild's log and seeing Fusion's report about the binding failure.
What can I do to make Fusion find MyCommon.dll during the build process? Note that moving the assembly would break my app, which also depends on it.
UPDATE: Well, it seems I'll go with using a copy afterall. Other solutions all require system-wide modifications, which isn't really warranted here.
So copy it instead? Just a thought. Have a copy there just to support the build that you delete once you're done with it.
I see multiple solutions :
1st : Add the assembly in the GAC (your assembly must have a strong name)
gacutil /I <assembly name>
2nd : Locate the assembly through Codebases or Probing, in your machine.config file or in msbuild.exe.config .
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyCommon"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<codeBase version="2.0.0.0"
href="file://C:/yourpath/MyCommon.DLL"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
3rd : copy the assembly in the same directory before and delete it after, like David M said.
All of these "solutions" create more dependencies which complicate the environment. There should be an easier way to update the probing path at runtime..
Specifically MSBuild should allow you to add probing paths in your .proj file, or to specify the dependant dlls
You can define a custom UsingTask:
<UsingTask TaskName="Task" AssemblyFile="Assembly.dll" />
but you cant add dependencies? it should be included... here with something like
<UsingTask TaskName="Task" AssemblyFile="Assembly.dll">
<DependantAssembly AssemblyFile="dependant.dll"/>
</UsingTask>
But, no this isn't supported...
An option is to use ILMerge to merge the dependency into the task assembly.