Anziehen der 32 oder 64 Bit DLL

Question

Hi,

ich entwickel ein Office AddIn, welches sowohl unter Office 2010 32-Bit als auch unter Office 2010 64-Bit betrieben wird.

Ich baue mit der Option "Platform target" = Any CPU.

Soweit ist alles klar.

Jetzt werde ich in Zukunft noch einen InProc-COM-Server verwenden. Die DLL liegt in einer 32-Bit als auch in einer 64-Bit Version vor. Wie wird beim Erzeugen des InProc-COM-Servers gesteuert, welche DLL angezogen wird?

Danke

Christian

Answer 1

Hallo Christian,

Mit "Any CPU" wirst Du da nicht wirklich weiterkommen (aber die Bitness würde ohnehin beim Erstellen der Setup-Pakete dazwischenfunken, da man keine MSI-Pakete erstellen kann, die sowohl für für x86 und x64 bestimmt sind). Das Problem besteht darin, dass Visual Studio keine gleichnamige Referenz innerhalb desselben Projektes zuläßt. Deshalb muss man die Projektdatei (*.csproj) manuell bearbeiten und manuell die Bedingungen und Pfad-Hints angeben. Wie das geht, kann man z.B. hier lesen:

Targeting both 32bit and 64bit with Visual Studio in same solution/project:
http://stackoverflow.com/questions/145803/targeting-both-32bit-and-64bit-with-visual-studio-in-same-solution-project

Ein Wort der Warnung: Obwohl das Projekt korrekt kompiliert wird, beschwert sich Visual Studio (auch 2010) zuweilen über eine angeblich falsche Zielplattform etc. Details dazu hier:

Assembly references with Condition display as warning in Visual Studio:
http://connect.microsoft.com/VisualStudio/feedback/details/534054/assembly-references-with-condition-display-as-warning-in-visual-studio

Siehe auch: MSBuild Conditions:
http://msdn.microsoft.com/en-us/library/7szfhaft.aspx


Wenn Du/Ihr continuous integration verwendest und z.B. über ein Tool wie TeamCity Deine Builds erstellst, können automatisch x86/x64-Konfigurationen getriggert werden. Dazu sind nur entspr. Konfigurationen und Triggerdefinitionen notwendig.

Gruß
Marcel

Answer 2

Hallo Christian,

wenn Du "Any CPU" nimmst (was für Dein Vorhaben IMHO auch empfehlenswert ist), ist es "keine" Sache, was Deine .NET Assembly da für eine COM-DLL "anzieht". Du bestimmst ja, was geladen wird, bzw. kannst das (bei Installation/Registrierung oder Quellcode).

Wichtig ist erstmal, dass im Normalfall in einem 64 Bit Prozess keine 32 Bit (COM) DLL geladen werden kann. (ok, es gibt Surrogat-Prozess-Techniken etc.) Bei einem COM-InProcServer musst Du ja auch in den Prozess marshallen. [Info] [Info2]
Es hängt ggf. davon ab, von wo man sie lädt. Wenn sich die DLL im %windir%\SysWOW64 Verzeichnis befindet, ist es (auf einem nativen 64 OS) eine 32 Bit DLL - wenn sie aus %windir%\System32 kommt ist es bspw. eine 64-bit DLL. Beim Registrieren der COM-DLL muss man also diesen Pfad beachten - je nach Wunsch der Bittigkeit und des Prozesses. Insofern macht das "Anziehen" nicht .NET, sondern sondern die COM-Infrastruktur, auf die von .NET auch nur delegiert wird (Activator.CreateInstance).

Es kann allerdings (gerade im COM Bereich) ggf. vorkommen, dass noch Abhängigkeiten auf 32 Bit DLLs da sind, und dann kann es Schwierigkeiten im 64 Bit Prozessen geben, deshalb sollte das geprüft werden.

________________________

Nebenbei könnte es vorteilhaft sein, die aktuelle Laufzeit zu benutzen, wenn benutzt:

[Detail Seite Visual Studio 2010-Tools für Office-Laufzeit]
http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=06c32242-2289-4471-93aa-ce96aa5cbc36

---

ciao Frank

Answer 3

Hi Marcel,

vielen Dank für die zahlreichen Infos und die Links.

Viele Grüße

Christian

Answer 4

Hi Frank,

vielen Dank für die Infos. Der Hinweis mit den Abhängigkeiten ist gut und wichtig.

Viele Grüße

Christian