Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   .NET-Framework (managed code) (https://www.delphipraxis.net/79-net-framework-managed-code/)
-   -   32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt (https://www.delphipraxis.net/155232-32bit-und-64bit-dll-version-namenskonvention-fuer-com-objekt.html)

Zend 14. Okt 2010 08:51

32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Hallo,

ich hoffe ich poste das hier im richtigen Forum:

Ich soll eine DLL schreiben die ein COM-Objekt exportiert. Das COM-Objekt hat einen Namen in der Form "Productname.Enviroment". Diese DLL soll es in einer 32 Bit und einer 64 Bit-Version geben (da Mischbetrieb von 32 Bit Anwendung und 64Bit Anwendung und vica versa anscheinend nicht möglich).

Auf einem 64 Bit Betriebssystem ist es also Möglich das je nach dem welches Programm meine DLL verwendet die 32 Bit oder die 64 Bit Variante benötigt wird. Da das COM-Objekt allerdings nur über den Namen angesprochen wird ergibt sich hier eine Mehrdeutigkeit.

Wie würde man in diesem Fall am besten vorgehen? Vergebe ich jeweils einen angepassten Namen für die DLLs ("Productname32.Environment" und "Productname64.Environment") oder (Productname.Environment32 und "Productname.Environment64") oder gibt es da eine andere Möglichkeit?

CrossPosting:
http://www.c-sharp-forum.de/viewtopi...&postorder=asc

Grüße
4000

Bernhard Geyer 14. Okt 2010 22:53

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Du brauchst keine unterschiedlichen Namen.

Die nötigen Verweise von "Productname.Environment" auf die 32-Bit oder 64-Bit DLL erfolgt über den Unter-Registry-Zweig LocalServer32/InprocServer32/InprocHandler32 bzw. den 64-Bit Gegenstücken.

Das Problem ist evtl. eher einen Installer zu finden der auch beide Einträge korrekt installiert ohne das sie sich gegenseitig kaputt machen.

Zend 18. Okt 2010 15:12

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Hallo,

vielen Dank. Das Verhalten ist in meinem Interesse und meine Frage damit beantwortet.

Grüße
Zend

Zend 8. Nov 2010 13:41

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Ich hab nochmal eine Frage:

Brauchen die Interfaces der 64 Bit Variante denn eine andere GUID als die Interfaces der 32 Bit DLL?

Bernhard Geyer 8. Nov 2010 13:46

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Zitat:

Zitat von Zend (Beitrag 1060377)
Ich hab nochmal eine Frage:

Brauchen die Interfaces der 64 Bit Variante denn eine andere GUID als die Interfaces der 32 Bit DLL?

AFAIK nein.

Dezipaitor 8. Nov 2010 14:07

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Die Parameter werden automatisch konvertiert, solange es sich um die bekannten COM Typen handelt. Bei Streams oder eigenen Kreationen muss man es selber machen.

Assarbad 9. Nov 2010 21:52

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Zitat:

Zitat von Dezipaitor (Beitrag 1060383)
Die Parameter werden automatisch konvertiert, solange es sich um die bekannten COM Typen handelt. Bei Streams oder eigenen Kreationen muss man es selber machen.

Das wäre doch aber ohnehin nur bei Marshaling wichtig, oder? Wenn jeweils eine 32bit und eine 64bit Variante eines InProc-Servers existieren, ist's doch egal, denn es wird ja die "Muttersprache" (eigene Bittigkeit) gesprochen. Oder irre ich?

Dezipaitor 9. Nov 2010 22:53

AW: 32Bit und 64Bit DLL-Version: Namenskonvention für COM-Objekt
 
Kann ich dir leider nicht beantworten. Durch Registry Redirection, Reflection, Sharing, sowie Kombinationen und Änderungen seit Win7 bin ich da durcheinander geraten.

Ich sag einfach mal...Guckst du hier:

http://msdn.microsoft.com/en-us/libr...53(VS.85).aspx
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:57 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz