Baugruppenreferenzfehler auf einer Website mit derselben Signatur

Question

Ich habe mehr als eine ASP.NET 2.0-Website auf IIS 6 und Windows Server 2003. Jede Website verweist auf einige DLLs: Design, Logik und so weiter. Jede Website ist auf einem anderen ApplicationPool mit Standardkonfiguration über Recycling-Techniken.

Jede DLL ist streng benannt (nicht verzögert) und hat eine Version, die sich nie ändert (2.0.0.0), alle DLLs werden im GAC abgelegt.

Nachdem ich eine DLL im GAC aktualisieren (dh. MyLibrary.dll), die in etwas (Methode, Klassen ) für die Verwendung in Web-Site "A" geändert hat, und nach dem Recycling nur die "A" Anwendungspool, wenn ich versuche, auf Web-Site "B" zugreifen, die die gleiche DLL verweisen ich den gemeinsamen Fehler über diese DLL erhalten:

Das Manifest der gefundenen Baugruppe Definition der gefundenen Assembly stimmt nicht mit der Assembly Referenz. (Ausnahme von HRESULT: 0x80131040)

Natürlich ist nichts in der DLL als Code, gleichen starken Schlüssel, gleiche Version, Kultur geändert. Der Fehler verschwinden über Recycling "B" Anwendungspool, natürlich.

Was kann eine seltsame erzeugen, RANDOM (Ich muss schon sagen!), Verhalten? Es ist etwas mehr, wie Hashing, dass es verwendet wird, um Baugruppen zu vergleichen?

Nachtrag

• Perpetualcoder fragte mich, wie DLLs referenziert werden, wenn mit voll qualifizierten Namen, ich denke, es ist, hier eine Zeile der web.config:

assembly="MyNamespace.MyComponent, Version=2.0.0.0, Culture=neutral, PublicKeyToken=1234567890ASDFGH"

Answer 1

Ich wiederhole mich immer wieder: Speichern Sie keine Dateien im GAC, es sei denn, Sie müssen unbedingt. asp.net kopiert dlls in einen Temp-Ordner und führt die Website von dort aus, es könnte sein, dass die Prüfsummen zwischen der geladenen dll und der im Temp-Ordner nicht übereinstimmen.

Sie sollten die Dlls Ihrer Website lokal in deren bin-Ordner aufbewahren. So sind Sie flexibler und schaden der Anwendung B nicht, wenn Sie eine Dll für Anwendung A aktualisieren. Außerdem erhalten Sie die xcopy-Bereitstellung für den geringen Preis, dass Sie ein wenig Speicherplatz aufgeben.

Answer 2

Frans, es ist ein Verfahren, das ich verstehe, und es könnte eine Möglichkeit sein, natürlich zu implementieren, aber was ich nicht verstehe, ist, warum, auch wenn voll qualifizierten Namen korrekt ist, kommt jedoch Fehler. Ich sah in DLL-Manifest, gibt es die Hashing-Algorithmus-Spezifikation. Führt ASP.NET einen Hashing-Vergleich über DLLs?

Was ich in wenigen Worten meine: IIS/ASP.NET findet, dass DDL "A" nicht mit DLL "B" Hash übereinstimmt, aber Triplett "Schlüssel, Kultur, Version" ist die gleiche so warum es nicht einfach aktualisieren statt popping aus ein web.config Fehler?