I am getting the classic exception
Could not load file or assembly 'XXX.Base, Version=11.0.0.0, Culture=neutral, >PublicKeyToken=xxxxxxxxx' or one of its dependencies. The located assembly's >manifest definition does not match the assembly reference. (Exception from >HRESULT: 0x80131040)
The assembly D:\xxx\xxxx\xxx\bin\xxx.xxx.xxx.xxx.dll was found but could not >be loaded.
It might have the same name as the referenced one but different version, >culture or public key token.
I know there are tons of these posts on SO and all over the web, but I have one question to which I have not been able to find an answer. Where else, other than web.config, does an ASP.NET get these version numbers from? In the references section of my app, the version is listed as 9.0.0.0. However, when I compile the app and put into IIS, I'm getting exceptions for the wrong version number.
I have already tried:
recompiling the app,
restarting the server,
restarting IIS,
clearing the ASP.NET temp files
restarting the app pool,
putting a newly recompiled version of the app onto the server,
checking the web.config (I can't even find some of these dlls referenced at all in the web.config file)
checking the packages.config file (it's not in here either)
Are there any other spots where these references are stored? I know that in visual studio I can expand references, but I'm assuming that list is stored in a file somewhere and I'm wondering where that file might be?
Where does my app get the idea that it needs version 11.0.0.0 of the assembly when it's listed as 9.0.0.0 in references?
Related
So I have created a NuGet Server via an ASP.Net Web Application following this tutorial: http://nugetserver.net/ which is hosted in IIS. I have placed the files on my D: drive on my server along with my packages.
IIS Sites Virtual Path:
I get the following error when I navigate to the url:
In case the picture is not clear enough, please see below:
Could not load file or assembly 'NuGet.Server, Version=2.11.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Here is my project's web.config file along with my publishing profile:
My target .NET Framework version is 4.6 but the packages themselves are those of an earlier version of .NET. Could this be the problem? I took the project folder and put it on my physical path on my local machine and it works just fine when I run the project in debug mode. Please see screenshot below:
NOTE: I have to hide the package names due to organizational confidentiality policies.
I am pointing to these package files:
D:\Backup\Dropbox\vox_server_01\nuget\Packages
The reason I am creating this NuGet server is because the existing one is buggy.
Could this be a permissions thing to the users group in IIS? This link Could not load file or assembly 'someProject' or one of its dependencies. Access is denied lead me to that question. Any suggestions on how I can get around this?
Update: Here are my package sources below:
I could not replicate your error, but here are some notes how nuget server problems can be solved:
The packagesPath key in web.config can be left blank, as you are already using the default folder \Packages.
When deploying to the server, you might find an error in the line of Access to the path server.cache.bin is denied. Just create a blank file with that name on your server.
Came here because of the same problem. Funny enough, I had my solution named "Nuget.Server" as well. Changing my Assembly name (under project properties) fixed it. Renamed it to "NugetServer"
If in your Web.config you have a reference to this NuGet.Server package, delete it from the file and try running again. Fairly similar to a BadImageFormatException from a bad reference in the web.config
I'm attempting to do an update to something that I have no code for. I have pulled the source using Reflector, created a new project and can build it successfully after my changes. I can run a local copy pointed at the proper database with no issues.
However, when I deploy to the site I keep receiving the error.
Could not load file or assembly 'xxxxxxxx' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I don't see anything in the web.config that would make me think it's looking for a specific version, and I saw nothing in the GAC.
Where do I go from here?
Where are assembly refernces stored for a web application?
In a Web Site, I see assembly tags written to the assembly node in the web.config when you add a reference. I am just curious as to how the Web Application Project makes the connection to get the correct local dll?
I manually add the reference and the application builds, but the dll is not imported into the BIN folder, and the assembly nodes are not created in the web config as they are in a Web Site. I do a solution search for the text 'assembly="SomeAssembly..." and no results are found.
I am just curious as I am trying to centralize updating assembly references as a 3rd party control vendor puts out hotfixes on a regular basis and we end up having to run around and update all the individual page refernces to the assembly. I was able to do this effectively in the Web Site project, but I am fairly new to Web Application Projects. Any advice or links would be appreciated. I guess I'm looking for tips on assembly & control reference management for ASP.NET Web Application Projects.
Like most Visual Studio projects, references are kept in the project.
There are two kinds of reference:
Project References are references to another project in the same solution. They look like this:
<ProjectReference Include="..\VBClassLibrary1\VBClassLibrary1.vbproj">
<Project>{045D7D9F-8E44-4C4B-95F8-620E86593C5B}</Project>
<Name>VBClassLibrary1</Name>
</ProjectReference>
File references are references to an arbitrary file on disk:
<Reference Include="System.Core">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
If you expand the References folder and click on a reference, then look in the Properties window, you'll see that both kinds of reference have a "Copy Local" property. For project references it defaults to true, for file references to false (though maybe that's only if the file is in the GAC). Changing the default adds:
<Private>False</Private>
Since the assembly was not imported to the BIN folder, and your application works, I assume that it is stored in the GAC (global assembly cache) and marked as "copy local=false" in the reference properties. You don't see the reference to the assembly in the web.config, since your code behind assembly - YourApp.dll (which is always created for web-applications), contains a standard assembly reference to that assembly. When you run your application it loads the assembly from the GAC.
Those "missing" dlls are probably in the Global Assembly Cache and are available to all .NET applications.
You can add control references to the pages/controls section of web.config, which will apply to all pages in the application.
I had the same issue, deleting .vs folder in the directory of the project solved the issue for me as it forced the recreation of .suo file which (though bite code) had reference to the web.config file in the wrong directory
I've more than one ASP.NET 2.0 web site on IIS 6 and Windows Server 2003.
Each site reference some DLLs: design, logic and so on.
Each site is on a different ApplicationPool with default configuration about recycling techniques.
Every DLL is strong named (not delayed) and has a version that never changes (2.0.0.0), all DLLs are placed in GAC.
After I update a DLL in GAC (ie. MyLibrary.dll) that has changed in something (method, classes..) for the use in web-site "A", and after recycling only the "A" application pool, when I try to access to web-site "B" that reference the same DLL I get the common error about that DLL:
The located assembly's manifest
definition does not match the assembly
reference. (Exception from HRESULT:
0x80131040)
Of course nothing is changed in DLL rather than code, same strongkey, same version, culture. The error disappear over recycling "B" application pool, of course.
What can generate a strange, RANDOM (I've to say!), behavior? There's something more, like hashing, that it's used to compare assemblies?
Addendum
Perpetualcoder asked me how DLLs are referenced, if with full qualified name, I think it is, here a line of web.config:
assembly="MyNamespace.MyComponent,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=1234567890ASDFGH"
I keep repeating myself: don't store files in the GAC unless you absolutely have to. asp.net copies dlls to a temp folder and runs the site from there, it might be checksums mismatch between the loaded dll and the one in the tempfolder.
You should keep your site's dlls local to the sites, in their bin folder. It will give you more flexibility and you don't hurt application B by updating a dll for application A. you also get xcopy deployment for the low price of giving up a bit of diskspace.
Frans, it is a procedure that I understand and it could be a way to deploy of course, but what I don't understand is why even if full qualified name is correct, error comes however.
I saw in DLL manifest, there's the hashing algoritm specification.
Does ASP.NET perform a hashing compare over DLLs?
What I mean in few words: IIS/ASP.NET finds that DDL "A" doesn't match DLL "B" hash, but triplet "key,culture,version" is the same so why it doesn't just update instead popping out an web.config error?
I have a web application which references an external DLL (lets call this productA.dll)
I have updated my GAC, my web.config, and my references, checked the versions and everything looks consistent.
However, when I run my application, methods that I use from productA.dll cannot be called, and I get a the specified module cannot be found error.
I tried creating a windows application and I can use productA.dll perfectly fine.
Observing the output window during run-time for the web application, I noticed that productA.dll symbols are not loaded. So I'm guessing that is why the module cannot be found.
The question is: why are the symbols not being loaded?
Any tips on the solution or diagnostics techniques would be greatly appreciated.
It's not a requirement that the assembly be in the GAC. I'd say to check the following:
Your assembly is in the website's bin folder.
Your assembly is referenced in the assemblies section of the web.config.
The assembly reference in the web.config has the correct version number.
By the way, symbols will only be loaded if you have the debug file (.pdb) along side the assembly.