Jak všichni víme, .net programy vygenerují .dll soubory v adresáři bin po jejich vygenerování, ale odkud pochází soubor .dll.refresh? Ten den jsem googlil nudu a zjistil jsem, že se to automaticky generuje při odkazování na assembler třetí strany (přímo) ve vašem projektu, tento .refresh soubor ukládá původní cestu k souboru třetí strany, pokud je dll pod touto cestou aktualizován, zatímco při generování projektu se assembler aktualizuje a mění podle této adresy. Bez tohoto souboru nebude VS schopen aktualizovat odkazovaný assembler podle nejnovějšího stavu, což způsobí problém s nesprávnou verzí assembleru. Malý detail může vést k velkému problému, všichni dávejte pozor!
Byla vydána nová verze webu a byl objeven vážný problém, kdy jedna z knihoven nebyla automaticky aktualizována, ale automaticky byla generována zastaralá verze.
Po vyšetřování se ukázalo, že to souvisí se souborem dll.refresh ve VSS.
Důvod je jednoduchý:
1。 Během vývoje, když jsou na web přidány další externí DLL reference, systém automaticky vygeneruje obnovovací soubor a tento soubor nebude generován, pokud jsou pod tímto řešením přidány další projektové DLL reference
2。 Obnovitovací soubor specifikuje cestu k automatické aktualizaci dll, a pokud jde o knihovní referenci, určí adresář Dubug nebo Release, a tentokrát je chybou zaznamenán adresář Debug
3。 Vývojář omylem zařadil soubor do kódu VSS
4。 Problém je v tom, že referenční knihovna se po vydání první verze mnohokrát změnila, ale rozhraní se nezměnilo, takže knihovna se generuje samostatně a poté se aktualizuje pouze odpovídající DLL (Release version) všech aplikací, a nenastal žádný problém, ale když je aplikace znovu publikována, kvůli existenci obnovitelného souboru v adresáři BIN projektu, DLL se automaticky aktualizuje podle cesty určené souborem, což vede k uvolnění staré verze DLL (Debug version).
Řešení problémů:
Smažte soubor dll.refresh v aplikaci a znovu ho publikujte
Nebo upravit obsah v dll.refresh a správně napsat dll cestu
|