Hallo Christian,
Obwohl hier noch einige wichtige Informationen fehlen (z.B. die von dir verwendete .NET- bzw. Visual Studio- und OS-Version bzw. Bitigkeit und starker Name-Status), kann ich schon jetzt sagen, dass dein Problem reichlich verkorkst ist.
Wegen eines Steuerelements eine 64bit-Version einer DLL anzulegen, macht nur dann Sinn, wenn diese Bibliothek Referenzen auf nichtgemanagte, native Bibliotheken enthält, die natürlich entweder 32bit oder 64bit aber nicht beides gleichzeitig sein können.
Wird tatsächlich der Zugriff auf den enormen Adressraum eines 64bit-Prozesses benötigt (was ich mir aber bei einem Steuerelement nur schwer vorstellen kann), könnte der .NET-bewußte Hersteller eine .NET Wrapper-Bibliothek
erstellen, die mit AnyCPU kompiliert ist und intern die Aufrufe eines Callers über P/Invoke in Abhängigkeit von SizeOf(IntPtr.Size) oder - ab .NET 4.0 - Environment.Is64BitProcess an die entspr. 32bit- oder 64-bit Funktion weiterleitet.
Das machen die wenigsten Hersteller (aus Kosten- sowie Performanzgründen), und so mußt Du jetzt lösen, was andere nicht gelöst haben.
In den meisten Fällen würde ich mir gar nicht erst die Mühe machen, eine 64bit-Variante zu erstellen. Ich würde beim Visual Studio 2010-Default für Anwendungen bleiben ("x86"), die 32bit-Drittherstellerbibliothek referenzieren und
nur meine weiteren Bibliotheken mit "AnyCPU" erstellen (Standard in Visual Studio 2010). Solange die native 32bit-Dependenz auf dem 64bit-OS installiert ist, wird die Anwendung im WOW64-Subsystem 32bittig ausgeführt und alles ist gut.
"AnyCPU" für ausführbare Dateien bringt
mehr Probleme mit sich als es löst. Freilich wäre das für uns Entwickler toll so ein
deus ex machina zu besitzen, einen "Mach mal"-Schalter den man einfach umlegt und gut ist. Vor einigen Tagen habe ich versehentlich diesen Schalter betätigt und eine Anwendung mit "AnyCPU" kompiliert, welche die 32bit-System.Date.SQLite.dll
referenziierte - eine gemischte Assembly. Bei der Ausführung auf einem 64bit OS kamen dann die "Überraschungen": inkompatible Plattform, Probleme mit der Manifestdatei, dem Konfigurationssystem und dem UAC etc.
Das Problem mit dem Standardbuildprozess in Visual Studio ist, dass Du eine Assembly mit sonst gleicher Identität (Name, Version etc.) aber verschiedener Bitigkeit nicht direkt einbinden und erstellen kannst. Du könntest
aber die 32/64bit-DLLs im GAC installieren (wenn sie einen starken Namen haben), verschiedene Build-Konfigurationen für x86 und x64 erstellen, CopyLocal für die betreffende DLL auf false setzen, und die Assembly-Resolution Visual
Studio überlassen. Oder: Du entfernst dich ganz vom VS-Buildprozess und verwendest MSBuild direkt.
Aber ich glaube nach wie vor, dass es ein x86-Build in den meisten Fällen auch tut.
s.a.: Anziehen der 32 oder 64 Bit DLL
http://social.msdn.microsoft.com/Forums/de/visualcsharpde/thread/ffaee98e-b8f2-4db9-86dc-0ae4c49a5906
32-Bit InProcCOM Server aus 64-Bit C# Anwendung verwenden:
http://social.msdn.microsoft.com/Forums/de-AT/visualcsharpde/thread/9da31721-c7a3-4cff-b54f-75fc90555fa1
Gruß
Marcel
