Erstellen von DLLs für side-by-side-Assemblys
Befolgen Sie beim Erstellen ihrer eigenen parallelen Assemblys die Richtlinien zum Erstellen paralleler Assemblys , und erstellen Sie alle dlls, die in der Assembly verwendet werden, gemäß den folgenden Richtlinien:
Ihre DLLs sollten so entworfen werden, dass mehrere Versionen gleichzeitig und im selben Prozess ausgeführt werden können, ohne sich gegenseitig zu beeinträchtigen. Viele Anwendungen hosten beispielsweise mehrere Plug-Ins, für die jeweils eine andere Version einer Komponente erforderlich ist. Der Entwickler der parallelen Assembly muss entwerfen und testen, um sicherzustellen, dass mehrere Versionen der Komponente ordnungsgemäß funktionieren, wenn sie gleichzeitig im selben Prozess ausgeführt werden.
Wenn Sie ihre Komponente als freigegebene Komponente auf Systemen vor Windows XP bereitstellen möchten, müssen Sie die Komponente auf diesen Systemen weiterhin als freigegebene Einzelinstanzkomponente installieren. In diesem Fall müssen Sie sicherstellen, dass Ihre Komponente abwärtskompatibel ist.
Werten Sie die Verwendung von -Objekten aus, wenn mehr als eine Version der Assembly auf dem System ausgeführt wird. Bestimmen Sie, ob verschiedene Versionen der Assembly separate Datenstrukturen erfordern, z. B. speicherzuordnungsbasierte Dateien, Named Pipes, registrierte Windows Nachrichten und Klassen, freigegebener Arbeitsspeicher, Semaphore, Mutexe und Hardwaretreiber. Alle Datenstrukturen, die über Assemblyversionen hinweg verwendet werden, müssen abwärtskompatibel sein. Entscheiden Sie, welche Datenstrukturen versionsübergreifend verwendet werden können und welche Datenstrukturen für eine Version privat sein müssen. Bestimmen Sie, ob freigegebene Datenstrukturen separate Synchronisierungsobjekte wie Semaphore und Mutexe erfordern.
Einige Objekte, z. B. Fensterklassen und Atome, werden für jeden Prozess eindeutig benannt. Objekte wie Fensterklassen sollten für jede Assembly mithilfe des Manifests versioniert werden. Verwenden Sie für Objekte wie Atoms versionsspezifische Bezeichner, es sei denn, Sie planen die Versionsfreigabe. Wenn Sie versionsspezifische Bezeichner verwenden, verwenden Sie die vierteilige Versionsnummer.
Fügen Sie keinen selbst registrierenden Code in eine DLL ein. Eine DLL in einer parallelen Assembly kann nicht selbst registriert werden.
Definieren Sie alle versionsspezifischen Namen in Ihrer DLL mit #define-Anweisungen. Dadurch können alle Registrierungsschlüssel von einem Speicherort geändert werden. Wenn Sie eine neue Version der Assembly freigeben, müssen Sie nur diese define-Anweisung #ändern. Beispiel:
#define MyRegistryKey "MyAssembly1.0.0.0"Store alle nicht beständigen Daten im Verzeichnis Temp.
Legen Sie Benutzerdaten nicht an globalen Speicherorten ab. Trennen Sie Anwendungsdaten von Benutzerdaten.
Weisen Sie allen freigegebenen Dateien eine Dateiversion zu, die vom Namen der Anwendung abhängt.
Weisen Sie alle Nachrichten und Datenstrukturen, die prozessübergreifend verwendet werden, einer Version zu, um unbeabsichtigte prozessübergreifende Freigaben zu verhindern.
Ihre DLL sollte nicht von der Freigabe zwischen Versionen abhängen, die möglicherweise nicht vorhanden sind, z. B. Freigegebene Speicherabschnitte, die nicht für verschiedene Versionen der Assembly freigegeben sind.
Wenn Sie neue Funktionen hinzufügen, die nicht dem Binärschnittstellen-Kompatibilitätsvertrag der ursprünglichen DLL entsprechen, müssen Sie eine neue CLSID, ProgId und einen Dateinamen zuweisen. Zukünftige Versionen Ihrer side-by-side-Assembly sind dann erforderlich, um diese CLSID, ProgId und den Dateinamen zu verwenden. Dadurch wird ein Konflikt verhindert, wenn eine version der DLL, die nicht nebeneinander ist, über eine nebensätzliche Version registriert wird.
Wenn Sie dieselbe CLSID oder ProgId wiederverwenden, testen Sie, ob die Assembly abwärtskompatibel ist.
Initialisieren und festlegen Sie die Standardeinstellungen für die Assembly im Assemblycode. Speichern Sie die Standardeinstellungen nicht in der Registrierung.
Weisen Sie allen Datenstrukturen Versionen zu.
Die DLL sollte den Zustand der parallelen Assembly speichern, wie unter Erstellungsstatus Storage für parallele Assemblys beschrieben.