Jak rozpowszechniać biblioteki C-run-time (CRT)

Question

Buduję aplikację po konwersji przestrzeni roboczej VC++ 6 na Express Visual C++ 2008. Budowanie w sobie idzie pomyślnie, ale prawdziwym problemem mam jest z wygenerowanych manifestów, które wygląda następująco:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?> 
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> 
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
    <security> 
     <requestedPrivileges> 
     <requestedExecutionLevel level='asInvoker' uiAccess='false' /> 
     </requestedPrivileges> 
    </security> 
    </trustInfo> 
    <dependency> 
    <dependentAssembly> 
     <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> 
    </dependentAssembly> 
    </dependency> 
    <dependency> 
    <dependentAssembly> 
     <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> 
    </dependentAssembly> 
    </dependency> 
</assembly> 

Moje pytanie brzmi:

Jak mogę ograniczyć manifest do listy tylko jedna wersja, korzystnie 9,0. 21022.8. abym mógł połączyć niezbędne zależności czasu C-Run w mojej aplikacji?

Wiem, że potencjalną przyczyną tego problemu jest zależność od biblioteki, która używa 9.0.21022.8, a mój VC++ Express 2008 może używać 9.0.30729.1. dlatego oba są wymienione jako zależność.

Uwaga:

Obserwuję podejście b) http://www.codeproject.com/Tips/211756/How-to-Distribute-C-run-time-CRT-Libraries-with-Yo?display=Print który mówi o skopiowanie plików DLL CRT i Microsoft.VCXX.CRT.manifest pliku wewnątrz folderu aplikacji.

Answer 1

Ustawieniem domyślnym programu Visual Studio 2008 jest powiązanie z wersją 9.0.21022.8. Jest to niezależne od zainstalowanej wersji dodatku Service Pack lub poprawki, ponieważ aktualizacje programu Visual Studio nie muszą wymuszać aktualizacji aplikacji (zgodnie z opisem here).

Inne możliwe wersje to 9.0.30729.1 dla dodatku Service Pack 1 lub 9.0.30729.6161 dla dodatku SP1 z aktualizacją zabezpieczeń. Są inni.

Ze względu na domyślne zachowanie aplikacja prawdopodobnie używa 9.0.21022.8 i istnieje biblioteka, która została skompilowana do używania 9.0.30729.1. Można dowiedzieć się, jaka wersja każdej biblioteki jest uzależniona od stosując następujący wiersz polecenia (described here):

dumpbin /directives <name>.lib 

W celu control the version środowiska wykonawczego że aplikacja wiąże się można zdefiniować symbole preprocesora w ustawieniach projektu (musi być w ustawieniach projektu lub w wierszu poleceń) albo wiążą się z domyślną wersją (9.0.21022.8 - przez nie ich definiowania) lub wiązanie z samej wersji jako zainstalowanego Visual Studio:

_BIND_TO_CURRENT_VCLIBS_VERSION=1 

Wygląda na to, że można również podać wartość e xact wersja, którą chcesz powiązać za pomocą definicji z this answer (może powinienem był to znaleźć najpierw przed wpisaniem tego wszystkiego :).

Jeśli okaże się, że twoja aplikacja wiąże się z 9.0.30729.1, a biblioteka zależna jest powiązana z 9.0.21022.8, po prostu musisz usunąć definicję preprocesora.

Druga trudność polega na tym, że podczas uaktualniania Visual Studio, moduły runtime scalające w twoim redystrybuowalnym folderze są również uaktualniane do tych wersji. Jeśli więc masz projekt instalacyjny, który używa tych modułów scalających i próbujesz powiązać je z domyślną wersją, skończyłoby się instalowanie nowych wersji środowiska wykonawczego.

Rozwiązywanie wersji wykonania nie byłby problem, jeśli również dystrybucję modułów scalania polityki wykonawcze, jak ładowarki biblioteka będzie w wyglądzie wykonawczego w polityce swoim czasie rzeczywistym i automatycznie załadować najnowszą wersję nawet jeśli wiążą się z domyślnie wersja. Nawet w przypadku złożeń prywatnych program ładujący will first look in the WinSxS folder, więc jeśli istnieją zasady, zostanie powiązany z najnowszą wersją.Tak więc Twoje mieszane numery wersji w twoim manifeście przekierują się do najnowszej wersji.

Czasami nie jest to pożądane i można to kontrolować, aby wymusić załadowanie tylko wersji w określonym manifeście, co wyjaśniono w odpowiedzi na this similar SO question.