Side by side follia - esecuzione di binari sullo stesso computer

Question

Ecco la mia configurazione:

• Computer A - Windows 7, MS Visual Studio 2005 patch per la compatibilità Win7 (8.0.50727.867)
• Computer B - Windows XP SP2, MS Visual Studio 2005 installato (8.0.50727.42)

Il mio progetto ha alcune dipendenze esterne (DLL predefiniti - sia generazione su A o scaricato da Internet), una coppia di DLL costruite da fonti ed un eseguibile. Sto per lo sviluppo su A e tutto è bene lì. Ad un certo punto cerco di costruire il mio progetto su computer B , la copia le DLL predefiniti nella cartella di output. Tutto costruisce bene, ma cercando di iniziare la mia domanda ho

L'applicazione non correttamente inizializzata (0xc0150002) ....

Il registro eventi contiene due di questi:

A seconda Assemblea Microsoft.VC80.CRT non si trovava e Ultimo errore era il riferimento di montaggio non è installato sul sistema.

più leggermente più divertente

Genera Contesto Attivazione non riuscito per some.dll. messaggio di errore di riferimento: La operazione è stata completata con successo.

A questo punto io sto cercando il mio Google-Fu, ma invano - praticamente tutti i colpi sono circa l'esecuzione di binari su macchine senza Visual Studio installata. Nel mio caso, però, gli eseguibili non riescono a eseguire sul computer sono costruiti.

Il passo successivo è stato quello di cercare di Dependency Walker e mi sconcertato ancora di più - i miei DLL costruite da fonti sulla stessa macchina non riesce a trovare MSVCR80.DLL e MSVCP80.DLL, tuttavia l'eseguibile sembra essere bene rispetto a quei due DLL cioè quando apro la eseguibile con Dependency Walker dimostra che le MSVC?80.DLLs possono essere trovati, ma quando ho aperto uno dei miei DLL si dice che non possono. Ecco dove io sono completamente fuori di idee che cosa fare in modo che non ti chiedo, caro StackOverflow:)

I ammettere che sono un po 'sfocata su tutta la faccenda side-by-side, in modo lettura generale sul tema sarà anche apprezzato.

Answer 1

La tua domanda è la risposta al vostro problema:. Computer A ha VC runtime di versione 8.0.50727.867 , e Computer B ha solo la versione 8.0.50727.42

Hai costruito le librerie sul Computer A, e da cui dipendono la versione 867 di VC runtime. (Questo può essere trovato nel manifesto incorporato nelle librerie.) Quando li si copia al computer B, queste librerie richiedono ancora la versione 867 del runtime, ma hai solo la versione 42.

Per risolvere le dipendenze di assemblaggio runtime VC, è necessario installare redistributables VC runtime della versione 867 sul computer B. Tuttavia, vi consiglio di aggiornare Visual Studio sul computer B in modo da avere la stessa versione su entrambi i computer. E ancora meglio, installare Visual Studio 2005 SP1 su entrambi i computer e quindi installare questo aggiornamento della protezione a SP1 . Dopo l'installazione di questi ultimi, le librerie dipenderà versione 8.0.50727.4053 .

Answer 2

è possibile che il problema è correlato con le diverse versioni di CRT runtime installato su entrambe le macchine. è possibile la costruzione di tutti i moduli da utilizzare runtime CRT collegata in modo statico per verificare questo?

Answer 3

prima mi piacerebbe controllare che le DLL predefiniti per la preparazione del progetto fittizio per caricarli

Answer 4

Di recente ho avuto lo stesso tipo di errore durante la creazione di progetti su una macchina e poi si spostano su un'altra macchina. Il più grande colpevole qui è probabile una configurazione di debug per uno dei componenti binari. Cioè, MSVC ha il requisito piuttosto rigida di tutte le DLL / EXE in fase di costruzione con la stessa libreria di runtime, eseguire il debug o rilascio, altrimenti non lavoreranno insieme.

Quando ho avuto questo accada tendono anche a compilare bene, ma quando si tenta di eseguire loro si ottiene quel messaggio di errore estremamente criptico.

È necessario assicurarsi che ogni modulo si costruisce insieme utilizza la stessa configurazione, quindi eseguire il debug o rilascio attraverso l'intera catena di creazione. Questo errore anche probabile esce con disallineamenti in altre librerie, in modo da assicurarsi che il proprio MSVC è l'esatto stessa versione sulle macchine in cui si stanno costruendo.