Creazione di DLL per assembly affiancati
Quando si creano assembly side-by-side personalizzati, seguire le Linee guida per la creazione di assembly side-by-side e creare eventuali DLL usate nell'assembly in base alle linee guida seguenti:
Le DLL devono essere progettate in modo che più versioni possano essere eseguite contemporaneamente e nello stesso processo senza interferire tra loro. Ad esempio, molte applicazioni ospitano più plug-in che richiedono una versione diversa di un componente. Lo sviluppatore dell'assembly side-by-side deve progettare e testare per garantire che più versioni del componente funzionino correttamente quando vengono eseguite contemporaneamente nello stesso processo.
Se si prevede di fornire il componente come componente condiviso nei sistemi precedenti a Windows XP, è necessario continuare a installare il componente in questi sistemi come componente condiviso a istanza singola. In questo caso, è necessario assicurarsi che il componente sia compatibile con le versioni precedenti.
Valutare l'uso di oggetti quando viene eseguita più di una versione dell'assembly nel sistema. Determinare se versioni diverse dell'assembly richiedono strutture di dati separate, ad esempio file mappati alla memoria, named pipe, messaggi e classi di Windows registrati, memoria condivisa, semafori, mutex e driver hardware. Tutte le strutture di dati usate nelle versioni degli assembly devono essere compatibili con le versioni precedenti. Decidere quali strutture di dati possono essere usate tra le versioni e quali strutture di dati devono essere private per una versione. Determinare se le strutture di dati condivise richiedono oggetti di sincronizzazione separati, ad esempio semafori e mutex.
Alcuni oggetti, ad esempio classi di finestre e atom, sono denominati in modo univoco per ogni processo. Gli oggetti come le classi di finestre dovrebbero essere versionati per ogni assembly usando il manifesto. Per oggetti come Atom, usare identificatori specifici della versione, a meno che non si prevede di condividere tra le versioni. Se si utilizzano identificatori specifici della versione, utilizzare il numero di versione composto da quattro parti.
Non includere codice con autoregistrazione in alcuna DLL. Una DLL in un assembly side-by-side non può autoregistrarsi.
Definire tutti i nomi specifici della versione nella DLL con istruzioni #define. In questo modo tutte le chiavi del Registro di sistema possono essere modificate da un'unica posizione. Quando si rilascia una nuova versione dell'assembly, è sufficiente modificare questa istruzione #define. Per esempio:
#define MyRegistryKey "MyAssembly1.0.0.0"Archiviare tutti i dati non permanenti nella directory Temp.
Non inserire i dati utente in posizioni globali. Mantenere i dati dell'applicazione separati dai dati utente.
Assegnare tutti i file condivisi una versione del file che dipende dal nome dell'applicazione.
Assegnare tutti i messaggi e le strutture di dati usati tra processi in una versione per impedire la condivisione accidentale tra processi.
La DLL non deve dipendere dalla condivisione tra versioni che potrebbero non esistere, ad esempio sezioni di memoria condivisa non condivise tra versioni diverse dell'assembly.
Se si aggiungono nuove funzionalità che non seguono il contratto di compatibilità dell'interfaccia binaria della DLL originale, è necessario assegnare un nuovo CLSID, ProgId e nome file. Le versioni future del tuo assembly affiancato dovranno quindi utilizzare questo CLSID, ProgId e nome file. Ciò impedisce un conflitto quando una versione della DLL che non è affiancata viene registrata su una versione affiancata.
Se riutilizzi lo stesso CLSID o ProgId, verifica che l'assembly sia compatibile all'indietro.
Inizializzare e configurare le impostazioni predefinite per l'assemblaggio nel codice dell'assemblaggio. Non salvare le impostazioni predefinite nel Registro di sistema.
Assegnare versioni a tutte le strutture di dati.
La DLL deve archiviare lo stato dell'assembly side-by-side come descritto in Authoring State Storage for Side-by-Side Assemblies.