Registrieren einer Klasse bei der Installation
Wenn eine Klasse für Clients jederzeit verfügbar sein soll, wie dies bei den meisten Anwendungen der Fall ist, registrieren Sie sie in der Regel über ein Installations- und Setupprogramm. Dies bedeutet, dass Informationen über die Anwendung in die Registrierung aufgenommen werden, einschließlich wie und wo die Objekte instanziiert werden sollen. Diese Informationen müssen für alle CLSIDs registriert werden. Weitere Informationen sind optional. Tools wie Regsvr32 erleichtern das Schreiben eines Setupprogramms, das Server bei der Installation registriert.
Wenn Sie sich nicht auf Die Systemstandardeinstellungen verlassen, gibt es zwei wichtige Schlüssel in der Registrierung: die CLSID und die AppID. Zu den wichtigen Informationen unter diesen Schlüsseln gehört, wie das Objekt instanziiert werden soll. Objekte können als in-process, out-of-process local oder out-of-process remote festgelegt werden.
Unter dem AppID-Schlüssel befinden sich mehrere Werte, die spezifische Informationen für diese Anwendung definieren. Darunter sind RemoteServerName und ActivateAtStorage, die beide verwendet werden können, um einem Client das Erstellen eines Objekts zu ermöglichen, wobei der Client keine integrierten Kenntnisse über den Standort des Servers hat. (Weitere Informationen zur Remoteinstanziierung finden Sie unter Suchen eines Remoteobjekts und Hilfsfunktionen zur Instanzerstellung.)
Ein Server kann auch als Dienst oder unter einem bestimmten Benutzerkonto installiert werden. Weitere Informationen finden Sie unter Installieren als Dienstanwendung.
Ein Server oder ROT-Objekt, das kein Dienst ist oder unter einem bestimmten Benutzerkonto ausgeführt wird, kann als "Activateor aktivieren"-Server bezeichnet werden. Für diese Server müssen der Sicherheitskontext und die Fensterstation/der Desktop des Clients mit dem des Servers übereinstimmen. Ein Client, der versucht, eine Verbindung mit einem Remoteserver herzustellen, wird als NULL-Fensterstation/Desktop betrachtet, sodass nur der Serversicherheitskontext in diesem instance verglichen wird. (Weitere Informationen zu SIDs finden Sie unter Sicherheit in COM.) COM speichert die Fensterstation/den Desktop eines Prozesses zwischen, wenn der Prozess zum ersten Mal eine Verbindung mit dem verteilten COM-Dienst herstellt. Daher sollten COM-Clients und -Server ihre Fensterstation oder Threaddesktops des Prozesses nach dem Aufruf von CoInitialize oder CoInitializeEx nicht ändern.
Wenn eine Klasse als prozessintern registriert wird, wird ein Aufruf von CoGetClassObject zum Erstellen ihres Klassenobjekts automatisch von COM an die DllGetClassObject-Funktion übergeben, die die Klasse implementieren muss, um dem aufrufenden Objekt einen Zeiger auf sein Klassenobjekt zu geben.
In ausführbaren Dateien implementierte Klassen können angeben, dass COM ihren Prozess ausführen und warten soll, bis der Prozess die IClassFactory-Schnittstelle ihres Klassenobjekts über einen Aufruf der CoRegisterClassObject-Funktion registriert.
Zugehörige Themen