Come distribuire le librerie di runtime C (CRT)

Question

Sto costruendo un'applicazione dopo aver convertito l'area di lavoro VC++ 6 in Visual C++ 2008 Express. Costruire in sé va con successo ma vero problema che ho è con i manifesti generati che assomiglia a questo:

<?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> 

mia domanda è:

Come posso restringere il manifesto per elencare solo una versione, preferibilmente 9,0. 21022,8. in modo che io possa raggruppare le dipendenze del tempo C-Run necessarie all'interno della mia applicazione?

So che la causa principale possibile di questo problema dipende da alcune librerie che utilizzano 9.0.21022.8 e che il mio VC++ Express 2008 potrebbe utilizzare 9.0.30729.1. ecco perché entrambi sono elencati come dipendenza.

Nota:

Sto seguendo approccio b), della http://www.codeproject.com/Tips/211756/How-to-Distribute-C-run-time-CRT-Libraries-with-Yo?display=Print che parla di copia dei file DLL CRT e file di Microsoft.VCXX.CRT.manifest all'interno della cartella dell'applicazione.

Answer 1

Il valore predefinito per Visual Studio 2008 è il collegamento alla versione 9.0.21022.8. Ciò è indipendente dalla versione del Service Pack o dell'aggiornamento rapido installato, poiché gli aggiornamenti a Visual Studio non devono necessariamente forzare l'applicazione a dover eseguire l'aggiornamento (come descritto in here).

Altre versioni possibili sono 9.0.30729.1 per Service Pack 1 o 9.0.30729.6161 per SP1 con un aggiornamento di sicurezza. Ce ne sono altri

A causa del comportamento predefinito, è probabile che l'applicazione utilizzi 9.0.21022.8 e che sia stata compilata una libreria per utilizzare 9.0.30729.1. Si può scoprire quale versione di ogni libreria dipende utilizzando la seguente riga di comando (described here):

dumpbin /directives <name>.lib 

Per control the version del runtime che l'applicazione si lega a te possono definire i simboli del preprocessore nelle impostazioni del tuo progetto (deve essere nelle impostazioni del progetto o nella riga di comando) per entrambi si legano alla versione di default (9.0.21022.8 - non definendo loro) o legame con la stessa versione come installato Visual Studio:

_BIND_TO_CURRENT_VCLIBS_VERSION=1 

Apparentemente puoi anche specificare la e la versione xact che vuoi associare all'utilizzo di definisce da this answer (forse avrei dovuto trovarla prima di scrivere tutto questo :).

Se si trova che l'applicazione si associa a 9.0.30729.1 e la libreria dipendente è vincolante per 9.0.21022.8, è sufficiente rimuovere la definizione del preprocessore.

L'altra difficoltà è che quando si aggiorna Visual Studio, i moduli di unione runtime nella cartella ridistribuibile vengono aggiornati anche a tali versioni. Quindi, se si dispone di un progetto di installazione che utilizza quei moduli di unione e si sta tentando di collegarsi alla versione predefinita, si finirebbe con l'installazione delle nuove versioni dei runtime.

Risolvere la versione di runtime non sarebbe un problema se si distribuiscono anche i moduli di unione dei dati runtime, come la pala biblioteca sarà a guardare fase di esecuzione per la politica del tempo di esecuzione e di caricare automaticamente la versione più recente, anche se si associa al default versione. Anche con gli assembly privati ​​il ​​caricatore will first look in the WinSxS folder, quindi se le policy sono lì, ci si collegherà alla versione più recente.Quindi i tuoi numeri di versione mista nel tuo manifest reindirizzeranno entrambi alla versione più recente.

A volte ciò non è desiderato ed è possibile controllarlo per costringerlo a caricare solo la versione nel manifest specificata, che viene spiegata in una risposta a this similar SO question.