I just copied an existing project to a brand new machine to start developing on it and have run into a problem with the version of one of my referenced assemblies (a telerik DLL as it happens).
The project originally referenced an older version of the assembly (lets call it v1.0.0.0). My new machine has the latest version of the assembly installed, so I thought I'd updated it (lets call the new version v2.0.0.0).
Now here's the problem: If I copy the old v1.0.0.0 dll to the project folder and add it as a reference, the web site launches without a problem. If I delete that reference (and also delete the old DLL from my system) and add the new version (v2.0.0.0), the page shows the following exception:
Could not load file or assembly
'XXXXXX, Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=121fae78165ba3d4' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference.
(Exception from HRESULT: 0x80131040)
Clearly, the code is looking for the out of date version and can't find it. But why?
I greped the solution folder for that version number and couldn't find a single reference. I double checked the text of the .csproj file and found the version correctly shows the latest version and the HintPath correctly shows the path to the new DLL. Furthermore, because I didn't install the old DLL on the system it doesn't show up in my GAC (though v2.0.0.0 does, as expected).
I then enabled the fusion log viewer to try to figure out why it's looking for that old version, but no luck:
Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.
=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
(Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
All it says it that it starts by looking for that old assembly. I have tried to find a solution online and saw this similar SO question, but it seems to be the exact opposite of my problem. That questioner's program was finding the wrong DLL instead of the referenced one. Whereas my problem is that the program is mysteriously looking for the wrong DLL and unable to find it when the right one can be found locally in the bin folder and in the GAC.
Why is mine looking for the old version? Where else can I search to find this bad reference?
My guess is that another assembly you are using is referencing the old dll. Are you familiar with all of the other project references being used and do any of them have a reference to the Telerik dlls?
Can you put in a binding redirect in your web.config file like this?
<dependentAssembly>
<assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
I tried most of the answers but still couldn't get it to work. This worked for me:
right click on reference -> properties -> change 'Specific Version' to false.
Hope this Helps.
I'm with Chris Conway on this one (upvoted him). The problem is that you are referencing one of the telerik assemblies in your project which references another one that isn't there.
First thing: I wouldn't install ANY vendor (ie: telerik) assemblies into the GAC. Telerik's stuff is compiled down to just two assemblies anyway (telerik.web.design and telerik.web.ui). Just deploy those with the application.
Second, in each of your .proj files (like .csproj) there is going to be a <reference include..> which points to the Telerik.Web.UI file. This normally contains a version number. Make sure the assembly you put in the bin folder matches that version.
Third, make sure ALL of your projects use the latest assembly. Also make sure they are grabbing the assembly from a local path instead of the GAC. (I really really don't like the GAC. It has caused no end of issues on some projects I've been on). We typically have an "Assemblies" folder that all projects use for external assembly references.
Fourth, visual studio automatically searches your gac everytime a web site project is loaded and retargets the assembly locations if it finds something in the gac. I can't remember if it ever does this for web application projects, but I haven't had the issue in a long time with those. This can cause similar issues during deployment.
Fifth, you can rebind version numbers for assemblies in the web.config. In the runtime/assemblybinding section you can use something like the following which takes every telerik assembly deployed in 2008 forward and points it to a very particular version:
<dependentAssembly>
<assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
<bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
</dependentAssembly>
Try:
cleaning temporary project files
cleaning build and obj files
cleaning old versions installed at
C:\Users\USERNAME\.nuget\packages\
That worked for me.
Go to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
Find machine.config file
open in notepad
find conflict dll
Remove this and save.
compilation assemblies
addassembly=dllName,Version=1.0.0000.0000 Culture=neutral,PublicKeyToken="QWEWQERWETERY"
assemblies compilation
works for me.
This isn't a clear answer as to why, but we had this problem, here's our circumstances and what solved it:
Dev 1:
Solution contains Project A referencing a NuGet Package, and an MVC project referencing Project A. Enabled NuGet Package Restore, then updated the NuGet package. Got a runtime error complaining the NuGet lib can't be found - but the error is it looking for the older, non-updated version. Solution (and this is ridiculous): Set a breakpoint on the first line of code in the MVC project that calls Project A. Step in with F11. Solved - never had a problem again.
Dev 2:
Same solution and projects, but the magic set breakpoint and step in solution doesn't work. Looked everywhere for version redirects or other bad references to this Nuget package, removed package and reinstalled it, wiped bin, obj, Asp.Net Temp, nothing solved it. Finally, renamed Project A, ran the MVC project - fixed. Renamed it back to its original name, it stayed fixed.
I don't have any explanation for why that worked, but it did get us out of a serious lurch.
Do you have any other projects in that solution ?(may be another project was referencing an old version) Usually in VS, dll dependency spans all projects in the solution.
I had a similar issue and I had to delete everything from the bin and obj folders and rebuild to get past my issue. Hope this helps.
My problem was that the old assemblies were in the _bin_deployableAssemblies folder under the Web Application.
This meant the old assemblies were overwriting the GAC assemblies when building the project.
In case is saves someone else 3 hours... my case was a bit different. My code used DevExpress v11.1 v11.1.4.0. I had it all referenced correctly in my code. But .net memory profiler installed DevExpress v11.1 v11.1.12.0 in the GAC. In fact it wasn't the components I referenced but the ones they referenced internally that failed. Try as I might, the GAC is always checked first. It compiled and ran fine but I couldn't view the win forms designer and the stack trace was no help at all. Finally uninstalled .net memory profiler and all was restored.
This error was somewhat misleading - I was loading some DLLs that required x64 architecture to be specified. In the .csproj file:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
<OutputPath>bin\Release-ABC</OutputPath>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
A missing PlatformTarget caused this error.
I was getting:
Could not load file or assembly 'XXX-new-3.3.0.0' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
It was because I changed the name of the assembly from XXX.dll to XXX-new-3.3.0.0.dll. Reverting name back to the original fixed the error.
If you are experiencing this problem when testing and/or debugging the application from the Visual Studio environment (ASP.NET Development Server), it is necessary to delete all temporary files on the development website folder. To know where that folder is, look for the ASP.NET Development Server icon on the Windows tray icon (it should have a title like this: ASP.NET Development Server - Port ####), right click the icon and select Show Details; thn, the field Physical path will tell you what the temporary folder is, all items there should be deleted to solve the problem. Build and run again the website and the problem should be solved (again, solved for the Development Environment).
I had the same problem with different assemblies referencing different versions of Newtonsoft.json. The solution that worked for me was running update-package from Nuget Package Manager Console.
Its almost like you have to wipe out your computer to get rid of the old dll. I have already tried everything above and then I went the extra step of just deleting every instance of the .DLL file that was on my computer and removing every reference from the application. However, it still compiles just fine and when it runs it is referencing the dll functions just fine. I'm starting to wonder if it is referencing it from a network drive somehwere.
I had the same message when switching between two versions of an application that referenced different versions of the same DLL. Although I was testing in different folders I accidentally copied the newer version over the older version.
So the first thing to check is the version of the referenced DLL in the application's folder. Just in case.
Maybe this helps or maybe not. I cleaned my debug and release versions then I renamed the OBJ folder. This finally got me thorugh. Previous steps were basically project removing references and them adding them back in at the project properties.
In My Visual Studio 2015, I ensured that the offending Visual Studio Project's Reference Paths List is empty:
This is what worked for me:
I was using the Microsoft.IdentityModel.Clients.ActiveDirectory version 3.19 in a class library project but only had version 2.22 installed in the actual ASP.NET Web Application project. Upgrading to 3.19 in the web app project got me past the error.
In my case i had 3 projects, 1 main project and 2 sub projects referenced by main project.. So i updated the main project, leaving out sub project. That's where the conflict was. After i updated all my project everything worked just fine.
In VS2017, have tried all the above solution but nothing works. We are using Azure devops for versioning.
From the teams explorer > Source Control Explorer
Select the project which driving you nuts for a long time
Right click the branch or solution > Advanced > get specific version
Then make sure You have ticked the checkbox of overwrite files as per screenshot
In my case, I accidentally chose the wrong version of the Telerik package from nuget, which nuget then replaced every package i referenced with the incorrect version. It then inserted a binding redirect to the incorrect version so that even after I replaced everything with the correct version, it was still looking for the incorrect version.
Related
SCENARIO
I undo all my pending changes, and get latest version from TFS. I attempt to build my solution and I get errors to do with two assemblies, these are:
System.Web.Helpers
System.Web.WebPages
A different member of my team does the same as me and for her it all builds fine and the assemblies are found with zero issues.
Our web.config is the same since we both check that out of TFS.
WHAT I HAVE DONE
I asked her for the path to where the two troublesome DLLs sit on her machine, and checked the same path on my machine, they exist. I have those DLLs in the same folder and they are the same version as hers!
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies\
I also compared our projname.csproj.user file to check and see if she had anything different in hers after I read this topic. But that too was the same as mine!
I then proceeded to remove the dlls, then adding them manually from the path above, and now all my errors are gone, but I then get told that my web.config has changed and needs to be checked in, and I know what has changed:
<Reference Include="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies\System.Web.Helpers.dll</HintPath>
<Private>False</Private>
</Reference>
The above used to be a on line, without the HintPath stuff.
I don't want this to be checked in, and it is really tiring to have to remove this stuff each time I want to check-in my code into TFS.
PROBLEM
System.Web.Webpages and System.Web.Helpers are not being loaded on my machine, but are on my other team member's machine.
possible reason is dll was registered on your colleagues machine. So it didn't have any HINTPATH. As per MSDN "Assemblies registered in the GAC won't have a HintPath entry for those references". Make sure this referenced assembly is registered on the GAC on all computers that you are trying to build the project on.
Register your dll and then try again.
This morning it was reported that our web app on our QA server was completely broken with the following error reported from Web.config:
Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified
Remembering seeing a Windows Update that mentioned MVC, I did some digging and found lots of people reporting a recent Windows Update breaking MVC.
After much digging through those questions and our server, it seems that what's bitten us does not match what's in those other questions, but it does appear related. Here's what we think know:
Our app that is broken uses ASP.NET MVC 5.1
MVC was installed via NuGet
Our BuildServer and QA servers do NOT have MVC 5.1 installed (therefore, not GAC'd)
What we believe has broken caused the "bad build" to be created:
A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC
The patch has put the "updated" version of MVC 5.1 in the GAC
CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder
Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found
Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).
Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no <Private> node been added/edited).
We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them.
So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?
A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC
Yes, this behavior is actually by design. See http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx.
The patch has put the "updated" version of MVC 5.1 in the GAC
Yes, that's correct; it's how the patch gets the updated code to run instead of the old code. See https://technet.microsoft.com/en-us/library/security/ms14-059.
CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder
Not exactly. What actually happens is a project that previously was CopyLocal=true gets switched to CopyLocal=false. CopyLocal can be set in one of two ways: 1) If there's an explicit <Private>True</Private> setting in the .csproj file, or 2) By default, if no such setting exists (GAC'd assemblies do not CopyLocal by default; other assemblies do).
So what appears to have happened in this case is that your project file didn't have this setting in the csproj file. As a result, the GUI showed the setting based on the evaluated default value before the patch (CopyLocal = true) but then after the patch was installed, the GUI will now show the new default value for a GAC'd assembly (CopyLocal = false).
Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found
That's correct.
Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).
For any .csproj reference without an explicit <Private>True</Private> setting, that is correct. Also, note the using NuGet to update your MVC reference can remove this setting even if it was previously present. See http://nuget.codeplex.com/workitem/4344.
Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no node been added/edited).
That's correct. Since MVC 5.2 is not GAC'd, even without an explicit <Private>True</Private> setting, the default value of this non-GAC'd assembly will be CopyLocal=true.
We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them.
So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?
The best you can do today is:
Put explicit <Private>True</Private> settings in your .csproj file for all your NuGet package assembly references.
Until NuGet bug #4344 is fixed, any time you use NuGet to update a package reference, go back into your .csproj file and re-add the explicit <Private>True</Private> setting.
I believe this issue is addressed in the .Net Web development tools and UI blog here: link
I won't repeat the whole thing here, as the issue and resolution is explained pretty well at that link.
However just to repeat the key points, which should explain why this has happened:
As part of patch KB2994397 MVC 5.1 was added to the GAC.
There appears to be a NuGet bug that resets CopyLocal flag. (see link ) This means that when a machine with the above patch deploys to a non-patched machine it will break!
MVC 4 has had its assembly version number incremented by the same security update - MS14-059 (so the GAC version will NOT be used) This explains why the MVC 4 version still works - despite it being in the GAC.
I added a note about this issue in my blog:
Microsoft Asp.Net MVC Security Update MS14-059 broke my build!.
Your analysis of the problem is right on the money, by default the Copy Local flag is set to false when the assembly is in the GAC, manually setting it to true should fix this problem.
Upgrading to 5.2.2 is even better, you get the benefits of the new release in addition to the security fix.
I am getting a build error when I attempt to build my asp.net application. The error is:
The type 'MediCare.Framework.Authentication.IUserAuthenticate' is defined in an assembly that is not referenced. You must add a reference to assembly 'MediCare.Framework, Version=1.0.1.95, Culture=neutral, PublicKeyToken=1999fa3c42b9'.
I can see the class in the library which is in the references folder. How do I debug this issue?
My intention is to point the references folder to the library source code's bin directory (since the pdb file is lcoated there and any updates to the library will reflect in the application). However, when I point the references folder to the bin directory of the source code, I get the error message above.
Update The application was originally developed in VS 2008 and I am modifying it in 2010. I think I am confused about where the GAC assemblies would be, if I am using VS 2010 (2.0 framework location or 4.0 framework location) ? .NET 4.0 has a new GAC, why?
Update (06-26-2012)
The file in the GAC ("C:\Windows\assembly\") has been deleted. But this error is still occuring.
This could possibly be caused by version inconsistencies. Meaning, in order to fix this, I would do a complete clean build of your assemblies (and also an assemblies that might be nested inside an assembly). Just go out cold and do a new build on all assemblies. That should work.
Go into windows explorer, right click on the DLL file that your project is using that contains this class, and look at the version tab. Make sure version number matches what you see in the error message. My guess is that it won't.
If it does match, then check the GAC and make sure there isn't a different version of the DLL there that it could be picking up. To do that, go to windows explorer, and navigate to c:\windows\assembly. See if that assembly is in there with a different version number. If it is, you may need to delete it from the GAC (use caution though because other apps may depend on it being there).
Strange. I am trying to deploy my application, normally there is not problems but recently i played with adding LINQ2SQL to the project and adding Entity Framework.. but removed them. Now when i try to deploy to my server, running it i am getting this error.. and i can't find a way to fix it ! I never used this assembly.. but i suspect Entity Framework or LINQ2SQL to have caused this.
Could not load file or assembly
'Microsoft.Windows.Design.Extensibility, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The system cannot find the file specified.
Additional infos:
I am using a Website project and not
a web application project.
I am
using DevExpress but i added all
their dll to the bin folder and that
never caused any problems.
Any ideas ?
Thanks!
I had this issue and solved it by removing the DevExpress.Xpf dlls from the bin folder after reading a comment on this DevExpress thread
This DLL is part of Visual Studio. You should be able to add it through Add Reference > Assemblies
Hover over the name to see where the location is and pick the one corresponding to your version of Visual Studio.
We have a web application that's deployed to many websites with only frontend changes, the shared backend portion has it's DLL in the GAC so we only have to update that one dll and all the sites get the update.
Is there a way to override the GAC with a DLL in the /bin folder to test out new features before they get released?
If it has the same version number as the referenced DLL, the GAC gets used.
If you increment the version number, rebuild the website referencing the new version number, put the new version in the /bin directory, then that DLL will be used.
If you do not want to change the version number, you're pretty much out of luck.
When .NET loads strong named assemblies, first it tries to decide what version number to use. It does this via the reference first, then it looks for publisher policies, then it looks for binding redirects in the configuration file.
After it does this, it looks for the assembly in the GAC, then in any codebase specified, then it probes various file system folders for the DLL. If at any one of those steps it finds the right version assembly, it stops.
If you are not changing the version number of your strong named assembly, .NET will find the original one in the GAC and stop looking. Note that because it stops when it finds one, and because looking in the GAC is first, specifying a codebase for your assembly will do no good unless you also specify a new version number.
I have been able to override the GAC with the assembly in the \bin folder using the <codebase>Element.
By specifying <codebase version="1.2.3.4" href="/bin/MyAssembly.dll" /> in my web.config file I can tell my application to use this version rather than the version specified in the GAC.
You may also want to take a look at the <probing>Element for specifying assembly locations?
I think I might be saying the same think as Adam Sills, but re-worded it for my understanding. Through my own testing, looks like this is what happens:
If your app is compiled with version 1.0.0.0 and 1.0.0.1 is in the GAC, then you can omit the .dll from your /bin.
If your app is compiled with version 1.0.0.1 and 1.0.0.0 is in the GAC, then you MUST place the .dll in your /bin to ignore the GAC. A error will occur if the GAC version is older than the required version of your app, unless you include the newer version in your /bin.
I hope this is correct...
You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the Windows Software Development Kit (SDK).
s