2011-12-06 11 views
5

PresentationCore.dll e WindowsBase.dll sono entrambi inclusi con il Microsoft .NET Framework 3.0, e due versioni di ogni dll sono installati su disco:Utilizzando PresentationCore e WindowsBase DLL in entrambi i x64 e x86 ambienti

  • An versione x64 in C: \ Program Files \ assembly di riferimento \ Microsoft \ Framework \ v3.0
  • una versione x 86 in C: \ Program Files (x86) \ Riferimento Assemblies \ Microsoft \ Framework \ v3.0

Fino all'aggiunta di riferimenti a queste DLL, la nostra app Web ASP.NET è stata in grado di essere compilato per "qualsiasi CPU" e funzionerebbe in modalità a 32 o 64 bit senza problemi. Dopo aver aggiunto un riferimento, per esempio, PresentationCore tramite lo standard "Add Reference" finestra di dialogo (Aggiungi riferimento -> NET -> PresentationCore), la web app non riesce quando è in modalità a 64 bit con il seguente errore:

Could not load file or assembly 'PresentationCore' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Chiaramente questo perché il pool di applicazioni a 64 bit sta tentando, e in mancanza, di caricare una versione a 32 bit della dll di PresentationCore.

Ora, io sono un po 'confuso da questo ...

  1. altre DLL .NET Framework sembrano passare tra loro x64 e la versione x86 senza soluzione di continuità (caricamento da Microsoft.NET/Framework64 o Microsoft.NET/Framework, rispettivamente). Perché PresentationCore e WindowsBase sono diversi?
  2. Perché Visual Studio sembra offrirmi solo la versione a 32 bit nella scheda ".NET" nella finestra di dialogo "Aggiungi riferimento"? Se voglio la versione a 64 bit, devo "Sfoglia" per questo.
  3. C'è un modo semplice per avere automaticamente la DLL corretta selezionata, come sembra accadere per altre librerie .NET Framework?

Possiamo sempre scrivere un po 'di MSBuild xml che scambiare automaticamente i riferimenti al tempo di costruzione in base al numero di bit dell'ambiente di destinazione, ma che sembra come qualcosa che non dovremmo avere a che fare per la DLL .NET Framework. Cosa dà?

Grazie!

+0

Sei sicuro di non aver aggiunto il riferimento utilizzando Sfoglia? Hai provato a rimuoverlo e quindi aggiungere di nuovo? – svick

+0

Sì, piuttosto sicuro. E sì, abbiamo provato a rimuoverlo e ri-aggiungerlo più volte. –

+1

Ho risolto questo problema abilitando "Abilita applicazioni a 32 bit" nelle impostazioni avanzate del pool di applicazioni. – Nippysaurus

risposta

3

È possibile fare riferimento in modo condizionale a ciascun file .dll che corrisponde alla configurazione di build attiva. Dovrai modificare manualmente il tuo file di progetto. Aggiungere un riferimento alla DLL a 32 bit. Quindi salva il progetto e modifica il file .csproj in un editor di testo.

Cercare il riferimento che è stato aggiunto e aggiungere Condizione = "$ (Piattaforma) == 'x86'" come attributo sull'elemento di riferimento. Quindi crea un'altra copia dell'elemento Reference e modificalo per la versione x64. Ecco un esempio con i driver Oracle ODP.NET:

<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64" Condition="$(Platform) == 'x64'"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>lib\x64\Oracle.DataAccess.dll</HintPath> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86" Condition="$(Platform) == 'x86'"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>lib\x86\Oracle.DataAccess.dll</HintPath> 
    <Private>True</Private> 
</Reference> 

Una cosa importante da notare è che non sarà più in grado di utilizzare la configurazione di 'AnyCPU'. Avrai bisogno di configurazioni di build esplicite per x86 o x64. Il .dll che stai tentando di utilizzare è probabile che effettui chiamate native in librerie OS in modo che il tuo progetto non possa più essere indipendente dalla piattaforma.

Se si desidera mantenere solo 1 configurazione di build, è possibile utilizzare x86 e utilizzare solo la versione x86/32-bit. Se si tratta di un'applicazione Web, sarà necessario inserire il pool di applicazioni in modalità a 32 bit.

A cura di rispondere alle vostre qeustions originali

  • Hai una manciata di opzioni di piattaforma quando si genera una DLL/eseguibile: Qualsiasi CPU, x86, x64 o Itanium. Il codice che è scritto al 100% nel codice gestito e non ha dipendenze sulle librerie native è generalmente compilato & distribuito come AnyCPU. Questo perché il codice di linguaggio intermedio (IL) risultante generato dal compilatore può essere eseguito sulle versioni x86, x64 e Itanium di .NET Framework. Librerie destinate a qualsiasi CPU possono essere referenziate in modo sicuro da applicazioni specifiche della piattaforma (x86, x64, IA64). La ragione per cui PresentationCore e WindowsBase sono diversi è perché hanno dipendenze sul codice nativo. A differenza del codice IL, che viene interpretato in fase di runtime, non esiste alcun concetto di CPU in codice nativo. A causa delle dipendenze del codice nativo, le librerie PresentationCore e WindowsBase .NET dovevano essere distribuite come x86 e x64, poiché AnyCPU non è possibile.
  • La finestra di dialogo Aggiungi riferimento dovrebbe mostrare solo le librerie compatibili con la piattaforma di destinazione. Se la tua piattaforma di destinazione è x86, dovrebbe mostrarti solo la CPU e le librerie x86.
  • Purtroppo no. Se non è possibile utilizzare alcuna CPU, ma è comunque necessario supportare x86 e x64, è necessario configurare più configurazioni di build (una per x86 e una per x64) e fare riferimento condizionalmente alle DLL a 32 e 64 bit necessarie. L'unico modo che conosco per farlo è quello di modificare il file di progetto come descritto sopra. Sarà necessario creare entrambe le configurazioni e distribuire anche versioni separate del codice a 32 e 64 bit. Se qualcuno dipende dal tuo codice, dovranno saltare gli stessi cerchi.
+0

Grazie per la risposta. Abbiamo già applicato una correzione al nostro progetto simile a quella che descrivi qui, ma quello a cui sono più interessato è * perché * dobbiamo farlo. Puoi rispondere a una delle domande che ho posto? –

Problemi correlati