Reputation: 51245
I'm having another of these "Could not load file or assembly or one of its dependencies" problems.
Additional information: Could not load file or assembly 'Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have no idea what is causing this or how I could debug it to find the cause.
I've done a search in my solution catalogs .csproj files, and every where I have Unity I have:
Reference Include="Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
Can't find any reference anywhere which goes against 1.2.0.0 in any of my projects.
Any ideas how I should go about solving this?
Upvotes: 341
Views: 1207310
Reputation: 59
<ItemGroup>
<Reference Include="atmocore">
<HintPath>..\..\..\atmocore\bin\out\$(ContainerTaskFramework)\atmocore.dll</HintPath>
</Reference>
</ItemGroup>
only this worked for me. and well it did not run from within the ide -> no debugging. so the challenge was so much accepted... almost went mad. (linux + rider was also a condition)
Important detail:
$(ContainerTaskFramework) -> will get replaced with the proper token. "net8.0" for example. keeps you sane when a new version comes out.
Upvotes: 0
Reputation: 690
Despite the original question being posted five years ago, the problem still persists and is rather annoying.
The general solution is thorough analysis of all referenced assemblies to understand what's going wrong. To make this task easier I made a tool (a Visual Studio extension) which allows selecting a .NET assembly (a .dll
or .exe
file) to get a graph of all the referenced assemblies while highlighting conflicting or missing references.
The tool is available in Visual Studio Gallery:
Upvotes: 43
Reputation: 2119
For me this issue was caused because CPU compatibility issue azure pipeline was building the DLL using 64 bit but my app is running in 32 bit which caused to issue Here's how i was able to debug that:
You should see error similar to this
ERR: Invalid assembly platform or ContentType in file (hr = 0x8007000b).
ERR: Run-from-source setup phase failed with hr = 0x8007000b.
To validate the dll which platform that was built you can use dnspy than from optional header
The solution was to set the pipeline to build any CPU
msbuildArgs: '/p:Platform="Any CPU"'
Upvotes: 0
Reputation: 334
I was getting the same error with some DLL missing from Bin Folder. I tried to delete , get back up everything from Team Foundation Server but didn't work. Got a copy of Bin folder from my office-matelocal machine, and replaced it. It didn't work either. At last, I manually FTPed server, got the copy of DLL which was showing up as missing, and then it started showing up that next file in the file list sequence is missing.
So I ftped server Got all Bin Folder, Manually replaced each file one by one. (Not Ctrl + All and replace.. I tried : it didn't work.) And somehow it worked...
Upvotes: 2
Reputation: 4443
Sometimes packages have different versions specificed for AssemblyVersion and AssemblyFileVersion.
I had this situation for the unity:
You have to specify redirects using an AssemblyVersion attribute. In my example pictures 2.1.505.0 should be used instead of 2.1.505.2
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
You can also check next materials: What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?
Upvotes: 13
Reputation: 526
I know this is an old post, but I made a PowerShell module to list dependencies, and which ones failed to load.
You can install it with:
Install-Module LibSnitcher
Import-Module LibSnitcher
To list the complete dependency chain:
(You can use the -Depth
parameter to set the recursion depth)
Get-PeDependencyChain -Path C:\Path\To\Your\Module.dll
To list modules that failed to load:
Get-PeFailedDependency -Path C:\Path\To\Your\Module.dll
There is a complete README at the project page, here
Hope it helps, let me know how can I improve it!
Upvotes: 0
Reputation: 2483
Tried closing and re-opening VS as suggested but it didn't work out.
I had to change from MIXED PLATFORMS to ANY CPU.
Upvotes: 4
Reputation: 23
For me rebuilding the unity game without Unity C# Projects Checkmark worked.
Upvotes: 2
Reputation: 704
At 99% the Could not load file or assembly or one of its dependencies problem is caused by dependencies! I suggest you follow this steps:
Download Dependency Walker from http://www.dependencywalker.com/
Launch Dependency Walker and open the dll (in my case NativeInterfaces.dll
)
You can see one or more dll with the error in red Error opening file...
It means that this dll is missing in your system; in my case the dll name is MSVCR71.DLL
You can download missings dll from google and copy in right path (in my case c:\windows\system32
)
At this point, you must register the new dll in the GAC (Global Assembly Cache): open a DOS terminal and write:
cd \Windows\System32
regsvr32 /i msvcr71.dll
Restart your application
Upvotes: 33
Reputation: 7397
I do the following to work out which dependency cannot be found.
Run regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Create the following:
LogFailures set value to 1 (DWORD)
LogResourceBinds set value to 1 (DWORD)
LogPath (String) set value to C:\FusionLog\
Now run your program and wait for it to raise Could not load file or assembly or one of its dependencies
.
Using explorer, navigate to C:\FusionLog
and there should be a folder containing logs for your program, showing which dependency is missing.
Note: Some people use FUSLOGVW.exe, which is a viewer for these Fusion Logs. On my machine it can be found in multiple places, including:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\FUSLOGVW.exe
Upvotes: 1
Reputation: 10170
TLDR; the solution for me was to restore default settings in visual studio.
I'm on visual studio 2019 community edition and I had this issue for same dll file across different projects that I didn't touch.
After trying out all the answers in this question (as of 2020-07-22 7:13UTC) I decided to repair visual studio installation (backed up my settings beforehand). After installation opened the solutions that had the problem and the problem was gone. After that imported my settings that and the problem came back!! So without repairing visual studio installation again (which takes a few minutes + one restart) I've simply restored VS default settings and then it works. If I end up having time to investigate, I'll edit the answer and pinpoint the underlaying issue
Upvotes: 0
Reputation: 854
Step 1: Remove the Existing Reference Step 2: Clean Solution Step 3: Add project Reference again.
and its done. :)
Upvotes: 0
Reputation: 1592
Your project's csproj file must contain a package reference of Microsoft.Practices.Unity and this could not be found in the global-packages folder (%userprofile%.nuget\packages), running dotnet restore
fixes the issue
Upvotes: 0
Reputation: 21711
I wasted a few frustrating hours on this problem too. We had to update our version of the .NET Framework, and started getting multiple “Could not load file or assembly or one of its dependencies” for several DLLs that had not been changed for years. Strangely, the versions being searched for in the error messages were all extremely old. For example, it was searching for Newtonsoft.Json version 6.0.0 while we had been using 8.0.1 for years.
Reverting to these ancient versions was not an option, and anyway there were a bunch of bindingRedirect
elements in our web.config file that were supposed to redirect calls to old DLLs to the new ones. Rolling back the .NET version made the errors go away, but we needed the new version. What is going on?
The <runtime>
element in our web.config file contained the element:
<assemblyBinding appliesTo="v2.0.50727"
xmlns="urn:schemas-microsoft-com:asm.v1">
The dependentAssembly
elements that seemed to be ignored were contained in that.
The culprit was the appliesTo
attribute. It meant the bindingRedirect
applies only to .NET version 2.0.50727. When we updated the .NET Framework version, all our bindingRedirect elements were ignored.
The solution in our case was to remove the appliesTo
attribute entirely.
Upvotes: 2
Reputation: 9833
Clean the solution and then right click on the project and select Package
Here increment the Assembly
and Assembly file
version and rebuild.
If that does not work,
1 - Open the solution in file Explorer.
2 - Close Visual Studio.
3 - Remove all bin
and obj
folders.
4 - Reopen the project and build it.
Upvotes: 2
Reputation: 1377
A strange fix for me, but I had just pulled this solution from source control.
Was getting this error, went through most of the answers above, and then deleted the solution and re-pulled the solution from source control.
Worked.
Will only apply to a few, but I guess I was one of the few so there will be more. Not sure what happened the first time, but somehow some assemblies must have had some issues when I pulled them across.
Essentially turn it off and on again.
Upvotes: 0
Reputation: 659
I have a C# Winforms project called SetTags with a large number of forms that I use Visual Studio 2013 to work on. After editing one of them and trying to build I got the error:
Could not load file or assembly 'SetTags Version = 2.1.85.0, Culture=neutral,PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
The error also appeared when I tried to save the project or to close the form I had been working on.
I fixed the problem by removing a recently added radio button control and commenting out all references to it, then added the control again and uncommenting the code. This allowed me to save the form, and on closing restarting VS the problem had disappeared.
My Visual Studio environment has many occasional problems - Toolbox not showing or appearing only on VS startup, unrecognized custom controls when trying to view a form in Design mode - and it may be that I need to move on to a later VS version.
Upvotes: 0
Reputation: 420
I had the same problem i solved it via the instructions below:
use the 64bit version of IIS ...
Upvotes: 6
Reputation: 584
For me, it seems that Nuget wasn't playing nice with my project/solution. I used Nuget to install NewtonSoft.Json The project file seemed to reference it correctly, and when I R-clicked the dll name in Solution Explorer/Dependencies/Nuget, then clicked Properties, I found that the dll existed where properties said it should be.
I deleted the Nuget package and did R-click Project > Add > Reference and browsed to the dll in a packages directory when a former Nuget process had installed it, and then the Solution ran fine.
NOTES: this solution is quite a a hodge podge, starting with a Xamarin.iOS solution and adding a .netstandard project (which is where I had difficulty using Nuget). There is also a "portable" project in the solution. I inherited all this from a dev who has been gone for 3 years. Ha ha.
Upvotes: 0
Reputation: 5230
Check the Web.config/App.config file in your project. See if the version numbers are correct.
<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />
This worked for me.
Upvotes: 17
Reputation: 5439
Check if you are referencing an assembly which in turn referencing an old version of unity. For example let's say you have an assembly called ServiceLocator.dll
which needs an old version of Unity assembly, now when you reference the ServiceLocator
you should provide it with the old version of Unity, and that makes the problem.
May be the output folder where all projects build their assemblies, has an old version of unity.
You can use FusLogVw to find out who is loading the old assemblies, just define a path for the log, and run your solution, then check (in FusLogvw) the first line where the Unity assembly is loaded, double click it and see the calling assembly, and here you go.
Upvotes: 139
Reputation: 5766
I had this today, and in my case the issue was very odd:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
</dependentAssembly>0.
Note the stray characters at the end of the XML - somehow those had been moved from the version number to the end of this block of XML!
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
</dependentAssembly>
Changed to the above and voila! Everything worked again.
Upvotes: 3
Reputation: 166
I kept getting this error on my web forms project in visual studio 2015. I shutdown Visual Studio and I killed the ScriptedSandbox64.exe, Microsoft.VsHub.Server.HttpHostx64.exe, Microsoft.VsHub.Server.HttpHostx.exe *32, Microsoft.VisualStudio.Web.Host.exe *32 processes and it seemed to help fix the issue.
Upvotes: 1
Reputation: 513
This issue happened to me where one of my dependent libraries was compiling a DLL with "Any CPU" when the parent library was expecting a compilation of "x64".
Upvotes: 3
Reputation: 190
In solution explorer right click on project (not solution), in build tab choose Platform target : "Any CPU".
Upvotes: 16
Reputation: 483
My solution was:
I have a three-tier application and I forgot to copy the DLL also to the right path at IIS. Just after copied it to the right place it worked for me.
Upvotes: 1
Reputation: 21
Try checking if the "Copy to Local" property for the reference is set to true and the specific version is set to true. This is relevant for applications in Visual Studio.
Upvotes: 2
Reputation: 60193
In my case, none of the proposed answer worked.
Here is what worked for me:
The second step was important apparently as it did not work without it.
Upvotes: 2
Reputation: 4655
Look out for conflicting references. Even after a clean and rebuild, conflicting references will still cause a problem. My problem was between AForge and Accord. I removed both of the references, and re-added the references re-choosing the particular reference (particular to my case, just Accord).
Upvotes: 2
Reputation: 150
In my case in the bin folder was a non reference dll called Unity.MVC3 , i tried to search any reference to this in visual studio without success, so my solution was so easy as delete that dll from the bin folder.
Upvotes: 5