Jak mogę silnie podpisać zewnętrzną bibliotekę DLL, zachowując jednocześnie metadane zespołu?

Question

Mam kilka bibliotek, których używam w moim projekcie, które są niepodpisane. Ponieważ moja aplikacja jest mocno podpisana, biblioteki też muszą być.

podpisuję tych bibliotek przy użyciu:

"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.1\Bin\ildasm.exe" /nobar /all /out=library.il library.dll 
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyKey.snk library.il 

Problem polega na tym, że wszelkie metadane, takie jak numery wersji, zgubić się w obecnie podpisane DLL. Jest to problem, ponieważ teraz niektóre zależności między bibliotekami są zepsute. Jak zachować numery wersji bez konieczności kompilowania kodu źródłowego tych bibliotek?

UPDATE

To rzeczywiście szczególności DLL, który pokazuje ten problem, a ja dowiedziałem się, że jest zbudowany przy użyciu ILMerge. Być może to powoduje problem. Żeby było jasne: biblioteka DLL, która jest produkowana przez ILMerge, ma odpowiednie metadane, dopiero po demontażu i ponownym zmontowaniu metadane znikają.

UPDATE 2

Otworzyłem DLL w reflektor i wydaje się, że przynajmniej numer wersji jest nadal. Przez cały czas sprawdzałem przy użyciu okna dialogowego właściwości/okna właściwości pliku w Eksploratorze Windows. Więc myślę, że to jest manifest, którego brakuje.

Answer 1

Zastanawiam się, dlaczego tak się dzieje. Mam dość dobre doświadczenie w kompilacji w obie strony, używając iluminy i ildazu na niepodpisanych i podpisanych złożeniach. Można sprawdzić wyjście metadanych przez ILasm nadal zawiera informacje o wersji (na dole z zakresu montażu):

.assembly ConsoleApplication1 
{ 
    //... 
    .hash algorithm 0x00008004 
    .ver 1:0:0:0 
} 

Tylko sprawdzone ponownie, że „działa na moim komputerze” (za pomocą dokładnych przełączniki samo wiersza poleceń jak ty) .

Jakie będą faktycznie utracone jest FileVersion atrybut (ten widać w Eksploratorze Windows po najechaniu zespole. Na AssemblyVersion atrybutem jest nadal obecne i prawidłowe. Czyżby pan myli dwa? Tylko AssemblyVersion jest ważne dla informacji wiążące. Zobacz to SO post aby uzyskać więcej informacji.

Nadzieja mogłem pomóc, inaczej trzeba by dostarczyć więcej kontekstu.

Answer 2

Jeśli masz kod źródłowy , po prostu przekompiluj biblioteki z silnymi nazwami - demontaż i ponowne składanie zwykle działa całkiem nieźle, ale to wciąż hack.

Aby zachować zależności między działającymi bibliotekami, należy zaktualizować odwołania w kodzie .il, aby użyć klucza publicznego zespołu, do którego się odwołują, w przeciwnym razie spróbują odwołać się do niepodpisanej wersji złożenia, a tym samym nie można załadować go w czasie wykonywania.

Możesz to zrobić ręcznie, ale staje się bardzo uciążliwe po 2 lub 3 złożeniach. Szybką poprawką jest tutaj signer, która dotyczy wielu trudności, z jakimi masz do czynienia i wykonuje świetną robotę - zazwyczaj jest to szybkie i czyste.

(Należy pamiętać, że obecnie został zbudowany na podstawie starej wersji .NET. Jeśli używasz złożeń C# 4/.NET 4, musisz pobrać źródło, zmienić je na docelowe.NET 4 i przebuduj go, aby uzyskać plik signer.exe, który poprawnie obsłuży zestawy .NET 4).