views:

378

answers:

2

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"

A: 

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 Bouma
A: 

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?

Andrea Celin
Why it doesn't update the dll is also a mystery to me, but it IMHO doesn't update the dll, which is similar to when you have referenced the same dll twice in several projects and there's a checksum mismatch between them: it will likely give an error with the temp folder during compilation.
Frans Bouma