COM Komponente RICHTIG de/installieren

Hallo,

ich habe eine einfache Klassenbibliothek erstellt und wollte diese dann installieren und registrieren. Leider klappt das bei mir immer nue genau einmal.

Vorgehen:

1. Klasse schrieben
2. Strong Name mittels sn.exe erstellen und dem Projekt (AssemblyKey)
   hinzufügen
3. compilieren
4. gacutil.exe /if dateiname.dll
5. regasm dateiname.dll /tlb:com.dateiname.tlb

Das funktioniert auch!

Aber leider nur einmal! X(
Wenn ich also etwas verändere dann nochmals kompiliere und Punkt 5 und 6 nochmals ausführe funktioniert das alles nicht mehr richtig. Dann versuche ich
mittels
regasm /unregister dateiname.dll
gacutil /uf dateiname
alles rückgängig zu machen und er sagt auch alles hat super geklappt.
Aber ich finde immer wieder Reste in der Registry?!?!
Wenn ich nun wieder neu von vorn anfage nachdem ich den registryeintrag manuell gelöscht habe klappt es nie wieder. Auch hier sagt er dann alles ok installiert und registriert aber ich finde das COM Objekt nicht mehr. Es taucht halt nicht mehr in der Liste auf.

Deshalb:

WIE GEHT MAN RICHTIG MIT DIESEN TOOLS WÄHREND DER ENTWICKLUNG UM?

WIE MACHT IHR DAS?

WOZU DIENEN DIE EXE-FILES GENAU?

Danke, Marcel

Das ganze hängt an der Versionsnummer. Assemblies mit einem starken Namen sind unterschiedlich, wenn sie verschiedene Versionsnummern haben. Standardmäßig ist von Visual Studio jedes projekt so eingestellt, dass die Versionsnummer automatisch erhöht wird. Diese Einstellung ist ein Attribut in der AssemblyInfo.cs bzw. in den Projekteigenschaften bei VS 2005.

Ist eine Assembly für COMInterop registriert und die Versionsnummer ändert sich, werden auch neue COM-IDs (CLSIDs und IIDs) vergeben. Damit sind es im Sinne von COM zwei getrennte unabhängige Komponenten. Du kannst nicht die COM-Registrierung einer älteren Version (z.B. 1.0.0.0) mit einer neu übersetzten Version (die eine neue Versionsnummer erhalten hat wie z.B. 1.0.2.23) aufheben.

Am besten legst Du die Versionsnummern von Hand fest, vergibst auch die diversen Guids selber, schreibst Schnittstellen für jede COMInterop Klasse und schaltest die Standardklassenschnittstelle ab. Destails dazu findest Du hier:

ein in .NET erstelltes Assembly für COM zur Verfügung stellen

Wenn Du Probleme mit verhunzten COM-Registrierungen hast, dann lösch die entsprechenden Einträge in der Registry (Suche mit regedit.exe im Schlüssel HKEY_CLASSES_ROOT nach dem Dateinamen.).

Noch ein paar Worte zum GAC. Du solltest Assemblies nur dann in den GAC legen, wenn dies unbedingt erforderlich ist. Assemblies, die im GAC liegen sind zwar von überall zentral aufrufbar, erschweren aber das Deployment. Außerdem muss man auf eine ordentliche Versionsverwaltung achten, da Assemblies im GAC von vielen Programmen gleichzeitig verwendet werden können. Lokale Assemblies stehen pro Anwendung im Ausführungsverzeichnis und beeinflussen andere Anwendungen, die auch diese Assembly verwenden nicht (Jede Anwendung hat ihre persönliche Kopie in der benötigten Version).

Ich arbeite jeden Tag mit COMInterop und ohne Probleme. Wir haben in der Firma noch viele COM-Anwendungen, die mit den .NET Komponenten reden müssen. Es gibt ein paar einfache Regeln:
*Automatische Versionierung abstellen (Versionsnummer manuell festlegen) *Standard-Klassenschnittstelle abschalten ([ClassInterface[ClassInterfaceType.None]) *Jeder Klasse eine Schnittstelle geben *Jeder Schnittstelle ein [Guid] Attribut mit einem Eindeutigen Schlüssel geben *Bei Remote-Komponenten Schnittstellen in separaten Assemblies definieren *COM sichtbaren Klassen ein [Guid]-Attribut mit eindeutigem Schlüssel geben *Grundsätzlich allen Assemblies einen starken Namen geben (Alle verwenden die selbe SNK-Datei die auf einem Netzlaufwerk liegt. Es gibt nur EINE EINZIGE im ganzen Unternehmen. Man braucht die Schlüsseltoken zum Definieren von CodeGruppen in CAS-Richtlinien. Je mehr Schlüsseldateien, desto mehr arbeit für den Admin) *Assemblies kommen nur in GAC, wenn es sich um ServicedComponents (COM+) handelt *COM-Clients verwenden die definierten Schnittstellen und nicht späte Bindung per Dispatch

Über EXE-Dateien
============

EXE Dateien sind sog. "ausführbare" Dateien. Man kann sie direkt vom Betriebssystem aufrufen. Wenn man das tut, erzeugt Windows einen neuen Prozess. Dieser Prozess hat seinen eigenen Sicherheitskontext, seinen eigenen Speicherbereich und lebt sozusagen in seiner eigenen kleinen Welt. DLL-Dateien sind Bibliotheken, die keinen eigenen Prozess zu leben haben. Sie brauchen sozusagen einen Wirt, um leben zu können. Diesen Wirt nennt man auch Host. Man sagt: Objekte aus Bibliotheken leben im Prozess des Aufrufers. Da am Anfang immer ein Prozess (also eine EXE-Datei) steht, leben die Objekte aus DLLs also in den Prozessen der EXE-Dateien. Deshalb muss man auch bei .NET Remoting immer einen Host schreiben, damit die vom Client konsumierten Objekte auch einen Platz zum leben haben. Da Objekte aus DLLs im prozess des Aufrufers leben, nutzen sie auch dessen Speicherberich usw. Deshalb ist es sehr einfach, zwischen Objekten im selben Prozess Daten auszutauschen bzw. Methoden aufzurufen. Die Objekte lassen sich einfach durch Speicheradressen ansprechen. Bei Objekten, die in einem anderen Prozess leben, geht das nicht, da jeder Prozess seinen eigenen Speicherbereich hat. Dafür gibt es IPC (Interprozesskomminikation) Technologieen wie .NET Remoting, DCOM, MSMQ usw.. Da man auf Daten in anderen Prozessen nicht direkt zugreifen kann ist es also ein großer Sicherheitsbounus, wenn eine Anwendung in verschiedenen Prozessen läuft. Allerdings sind IPC Zugriffe viel langsamer und aufwendiger als direkte Speicherzugriffe.

Danke soweit,

hast du oder jemand anderes vielleicht
ein gutes Tutorial mit Visual Studio 2003
diesbezüglich empfehlen.

Das würde die gute ausführliche Antwort von Rainbird
noch gut ergänzen, da einige Sachen in der Beschreibung
ohne Beipiel für mich - und anderes Anfänger in diesem Bereich -
recht schwer zu verstehen sind.

Danke

Hallo Rainbird,

der erste Satz aus deiner Erläuterung ist der wichtigste.
Die Versionsnummern scheint Kriegs-entscheidend zu sein.

Ich habe VS nun die registrierung überlassen "Register for COM Interop"
und mache bei jeder neu Kompilierung manuell eine neue Versionsnummer
rein.
So bekomme ich es hin das immer genau ein automation server und zwar der
zuletzt aktive in der COM Liste steht.

Habe mal gesehen, dass die Registrierung auch per setup-Projekt funktioniert.
Weiß jemand wie das funktioniert?

Thx

In den Eigenschaften der einzelnen Elemente in einem Setup-Projekt gibt es eine Eigenschaft Namens "Register". Die muss für die für COM zu registrierenden Elemente auf "vdprCOM" gesetzt werden. Fertig.