Come posso correggere l'errore di compilazione di Visual Studio, "mancata corrispondenza tra architettura del processore"?

Sono nuovo a progettare la configurazione in Visual Studio 2010, ma ho fatto alcune ricerche e non riesco ancora a capire questo problema. Ho una soluzione di Visual Studio con una DLL C ++ che fa riferimento alla DLL C #. La DLL C # fa riferimento ad alcune altre DLL, alcune all'interno del mio progetto e altre esterne. Quando provo a compilare la DLL C ++, ricevo questo avviso:

avviso MSB3270: si è verificata una discrepanza tra l'architettura del processore del progetto in fase di creazione "MSIL" e l'architettura del processore del riferimento "[dll C # interno]", "x86".

Mi dice di andare a Configuration Manager per allineare le mie architetture. La DLL C # è impostata con la piattaforma target x86. Se provo a cambiarlo in qualcos'altro, come Qualsiasi CPU, si lamenta perché una delle DLL esterne da cui dipende ha la piattaforma x86 di destinazione.

Quando guardo Configuration Manager mostra la piattaforma per la mia DLL C # come x86 e per il mio progetto C ++ come Win32. Sembra la giusta installazione; sicuramente non voglio che il progetto per il mio progetto C ++ abbia la piattaforma impostata su x64, che è l'unica altra opzione presentata.

Cosa sto facendo di sbagliato qui?

Questo avviso sembra essere stato introdotto con il nuovo Visual Studio 11 Beta e .NET 4.5, anche se suppongo che sarebbe stato possibile prima.

Innanzitutto, è davvero solo un avvertimento. Non dovrebbe danneggiare nulla se hai a che fare con dipendenze x86. Microsoft sta solo cercando di avvisarti quando dichiari che il tuo progetto è compatibile con "Any CPU" ma hai una dipendenza da un progetto o da un assembly DLL che è x86 o x64. Poiché hai una dipendenza x86, tecnicamente il tuo progetto non è quindi compatibile con "Qualsiasi CPU". Per far sparire l'avvertimento, dovresti effettivamente cambiare il tuo progetto da "Qualsiasi CPU" a "x86". È molto facile da fare, ecco i passaggi.

1. Vai alla voce di menu Build | Configuration Manager.
2. Trova il tuo progetto nell'elenco, sotto Piattaforma verrà visualizzato "Qualsiasi CPU"
3. Seleziona l'opzione "Qualsiasi CPU" dal menu a discesa, quindi seleziona <New..>
4. Da quella finestra di dialogo, selezionare x86 dal menu a discesa "Nuova piattaforma" e assicurarsi che "Qualsiasi CPU" sia selezionato nel menu a discesa "Copia impostazioni da".
5. Premi OK
6. Dovrai selezionare x86 per entrambe le configurazioni Debug e Release.

Questo farà scomparire l'avvertimento e affermerà anche che l'assembly o il progetto non sono più compatibili con "Qualsiasi CPU" ma ora specifici per x86. Questo è applicabile anche se stai costruendo un progetto a 64 bit che ha una dipendenza x64; dovresti semplicemente selezionare x64 invece.

Un'altra nota, i progetti possono essere compatibili con "Qualsiasi CPU" di solito se sono progetti .NET puri. Questo problema si presenta solo se si introduce una dipendenza (dll di terze parti o il proprio progetto gestito C ++) destinato a un'architettura di processore specifica.

Questo è un avvertimento molto testardo e mentre è un avvertimento valido ci sono alcuni casi in cui non può essere risolto a causa dell'uso di componenti di terze parti e altri motivi. Ho un problema simile, tranne per il fatto che l'avviso è dovuto al fatto che la mia piattaforma di progetti è AnyCPU e mi riferisco a una libreria MS creata per AMD64. Questo è in Visual Studio 2010 tra l'altro, e sembra essere stato introdotto installando VS2012 e .Net 4.5.

Dal momento che non riesco a modificare la libreria MS a cui faccio riferimento e poiché so che il mio ambiente di distribuzione di destinazione sarà sempre e solo a 64 bit, posso tranquillamente ignorare questo problema.

Che dire dell'avvertimento? Microsoft ha pubblicato in risposta a un rapporto Connect che un'opzione è disabilitare tale avviso. Dovresti farlo solo se sei molto consapevole dell'architettura della tua soluzione e capisci perfettamente il tuo obiettivo di distribuzione e sai che non è davvero un problema al di fuori dell'ambiente di sviluppo.

È possibile modificare il file di progetto e aggiungere questo gruppo di proprietà e le impostazioni per disabilitare l'avviso:

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

Una buona regola empirica è "DLL aperte, EXE chiusi", ovvero:

• EXE prende di mira il sistema operativo, specificando x86 o x64.
• Le DLL vengono lasciate aperte (ad es. AnyCPU) in modo da poter essere istanziate all'interno di un processo a 32 o 64 bit.

Quando si crea un EXE come AnyCPU, tutto ciò che si sta facendo è rinviare la decisione su quale processo Bitness utilizzare per il sistema operativo, che JIT verrà eseguito a suo piacimento. Cioè, un sistema operativo x64 creerà un processo a 64 bit, un sistema operativo x86 creerà un processo a 32 bit.

La creazione di DLL come AnyCPU li rende compatibili con entrambi i processi.

Per ulteriori informazioni sulle sottigliezze del caricamento degli assiemi, vedere qui . Il sommario esecutivo recita qualcosa del tipo:

• AnyCPU : carica come assembly x64 o x86, a seconda del processo di invocazione
• x86 - carica come assembly x86; non verrà caricato da un processo x64
• x64 - carica come assembly x64; non verrà caricato da un processo x86

La DLL C # è impostata con la piattaforma target x86

Qual è il tipo di problema, una DLL in realtà non riesce a scegliere quale sarà il testimone del processo. Questo è interamente determinato dal progetto EXE, è il primo assembly che viene caricato, quindi l'impostazione di destinazione della piattaforma è quella che conta e imposta il testimone per il processo.

Le DLL non hanno scelta, devono essere compatibili con il testimone del processo. In caso contrario, otterrai un grosso Kaboom con BadImageFormatException quando il tuo codice tenta di usarli.

Quindi una buona selezione per le DLL è AnyCPU, quindi funzionano in entrambi i modi. Che fa un sacco di senso per C # DLL, che fanno il lavoro in entrambi i modi. Ma certo, non la tua DLL in modalità mista C ++ / CLI, contiene codice non gestito che può funzionare bene solo quando il processo viene eseguito in modalità a 32 bit. È possibile ottenere il sistema di generazione per generare avvisi a tale proposito. È esattamente quello che hai. Solo avvertimenti, si costruisce ancora correttamente.

Basta punt il problema. Imposta il target della piattaforma del progetto EXE su x86, non funzionerà con nessun'altra impostazione. E mantieni tutti i progetti DLL su AnyCPU.

Stavo ricevendo lo stesso avvertimento che ho fatto questo:

1. scarica il progetto
2. modificare le proprietà del progetto, ad esempio .csproj

3. aggiungi il seguente tag:

   <PropertyGroup>
       <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
           None
       </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
   </PropertyGroup>

4. Ricarica il progetto

Ho avuto questo problema oggi e solo guardare le configurazioni degli edifici in Visual Studio non mi ha aiutato perché mostrava Qualsiasi CPU sia per il progetto che non stava costruendo sia per il progetto di riferimento.

Ho quindi cercato nel csproj del progetto di riferimento e ho trovato questo:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>

In qualche modo questo PlatformTarget è stato aggiunto nel mezzo di una modifica della configurazione e l'IDE non sembrava vederlo.

La rimozione di questa riga dal progetto di riferimento ha risolto il mio problema.

Se la tua DLL C # ha dipendenze basate su x86, allora la tua stessa DLL dovrà essere x86. Non vedo davvero un modo per aggirare questo. VS si lamenta di averlo cambiato in (ad esempio) x64 perché un eseguibile a 64 bit non può caricare librerie a 32 bit.

Sono un po 'confuso sulla configurazione del progetto C ++. Il messaggio di avviso fornito per la build suggerisce che è stato scelto come target per AnyCPU, in quanto ha segnalato che la piattaforma di destinazione era [MSIL], ma hai indicato che la configurazione per il progetto era effettivamente Win32. Un'app Win32 nativa non dovrebbe coinvolgere MSIL, anche se probabilmente avrebbe bisogno del supporto CLR abilitato se interagisce con una libreria C #. Quindi penso che ci siano alcune lacune sul lato delle informazioni.

Posso rispettosamente chiederti di rivedere e pubblicare un po 'più di dettaglio sull'esatta configurazione dei progetti e su come sono correlati? Sii felice di aiutare ulteriormente se possibile.

Oltre alla risposta di David Sacks, potresti anche dover accedere alla Buildscheda di Project Propertiese impostare Platform Targetsu x86per il progetto che ti sta dando questi avvisi. Sebbene ci si possa aspettare che sia, questa impostazione non sembra essere perfettamente sincronizzata con l'impostazione nel Configuration Manager.

Per i progetti C #, l'obiettivo di x86 fa quello che sembra. Dice che questo assembly supporta solo architetture x86. Allo stesso modo per x64. Qualsiasi CPU d'altra parte dice che non mi interessa quale architettura, io sostengo entrambi. Quindi, le prossime 2 domande sono (1) qual è la configurazione dell'eseguibile che usa queste dll? e (2) qual è il testimonedel tuo sistema operativo / computer? Il motivo per cui ti chiedo è perché se il tuo eseguibile è compilato per funzionare in 64-bit, allora HA BISOGNO di tutte le dipendenze per poter funzionare anche in modalità 64-bit. Il tuo gruppo Any CPU dovrebbe essere in grado di essere caricato, ma forse fa riferimento a qualche altra dipendenza che può essere eseguita solo nella configurazione x86. Controlla tutte le dipendenze e le dipendenze delle dipendenze per assicurarti che tutto sia "Any CPU" o "x64" se prevedi di eseguire l'eseguibile in modalità 64-bit. Altrimenti, avrai problemi.

In molti modi, Visual Studio non semplifica la compilazione di una combinazione di qualsiasi CPU e vari assiemi dipendenti dall'architettura. È fattibile, ma spesso richiede che un assembly che altrimenti sarebbe "Qualsiasi CPU" debba essere compilato separatamente per x86 e x64 perché alcune dipendenze di una dipendenza da qualche parte hanno due versioni.

Ho avuto un problema simile prima, in particolare quando ho aggiunto una soluzione di prova a una soluzione x64 esistente, come SharePoint. Nel mio caso, sembra avere a che fare con il fatto che determinati modelli di progetto vengono aggiunti come determinate piattaforme per impostazione predefinita.

Ecco la soluzione che spesso funziona per me: imposta tutto sulla piattaforma corretta in Configuration Manager (il menu a discesa della configurazione attiva, dice Debug normalmente, è un buon modo per arrivarci) e la piattaforma di progetto (nelle proprietà del progetto), quindi compilare, quindi reimpostare tutto su AnyCPU. A volte devo rimuovere e aggiungere nuovamente alcune dipendenze (DLL nelle proprietà di ciascun progetto) e talvolta "Esegui test nel processo a 32 bit o 64 bit" (fai doppio clic su Local.testsettings e vai a Host) deve essere modificato.

Mi sembra che si tratti solo di impostare qualcosa e poi di ripristinarlo, ma probabilmente c'è qualcosa in più dietro le quinte che non vedo. In passato ha funzionato abbastanza coerentemente per me.

Per il mio progetto, ho un requisito per essere in grado di costruire sia su x86 che x64. Il problema è che ogni volta che aggiungi riferimenti mentre ne usi uno, allora si lamenta quando costruisci l'altro.

La mia soluzione è modificare manualmente i file * .csproj in modo che linee come queste:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

essere cambiato in questo:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

Ho avuto un problema simile a quello causato da MS UNIT Test DLL. La mia applicazione WPF è stata compilata come x86 ma DLL test unità (file EXE di riferimento) come "Qualsiasi CPU". Ho cambiato la DLL di unit test per essere compilata per x86 (uguale a EXE) ed è stata rimossa.

Potresti anche ricevere questo avviso per gli assembly MS Fakes che non è così facile da risolvere poiché il comando f.csproj è basato sul comando. Fortunatamente il file XML Fakes ti consente di aggiungerlo lì .

Dovrebbe esserci un modo per creare un AnyCPU .NET / DLL EXE e qualsiasi DLL non gestita da cui dipende sia compilata con x86 che x64, entrambe in bundle forse con nomi di file diversi e quindi il modulo .NET carica dinamicamente quello corretto in base al suo runtime architettura del processore. Ciò renderebbe AnyCPU potente. Se la DLL C ++ supporta solo x86 o x64, AnyCPU è ovviamente inutile. Ma il bundling di entrambe le idee che devo ancora vedere implementate come gestore della configurazione non fornisce nemmeno un mezzo per costruire lo stesso progetto due volte con una diversa configurazione / piattaforma per il raggruppamento multiplo, consentendo AnyCPU o anche altri concetti come qualsiasi configurazione.

Ho avuto un avviso molto simile nella mia build. I miei progetti erano impostati su .NET 4.5, sul server di build è stato installato l'SDK di Windows 8.1 (per .NET 4.5.1). Dopo aver aggiornato i miei progetti su .NET 4.5.1 (non era un problema per me, era per un'applicazione completamente nuova), non ho più ricevuto l'avviso ...

Ho risolto questo avviso cambiando "Configuration Manager" in Release (Mixed Plataform).

Ho ricevuto questo avviso in Visual Studio 2012 durante la compilazione di un'attività di script della pipeline SSIS di SQL Server 2012 SP1, fino all'installazione di SQL Server 2012 SP2.

Ho avuto lo stesso problema con l'apertura della connessione SQLite e l'utilizzo del Nuget e l'installazione del componente utilizzato nel progetto (SQLite) lo hanno risolto! prova a installare il componente in questo modo e controlla il risultato

Usa https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example :

• aggiungere un file Directory.Build.props nella cartella della soluzione
• incollalo dentro:

<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>