Introduzione

Le applicazioni e i sistemi operativi moderni sono costituiti da molti componenti. Un componente non è altro che un'entità software autonoma che rende disponibili varie funzioni ampiamente utilizzabili da una vasta gamma di applicazioni. Poiché i singoli componenti vengono utilizzati da più di un'applicazione, la condivisione dei componenti risulta essenziale.

Per una corretta condivisione globale dei componenti è necessario che il funzionamento di ogni componente condiviso rimanga inalterato rispetto alle relative versioni precedenti. In realtà, tuttavia, una compatibilità totale con le versioni precedenti è difficile se non impossibile da ottenere a causa della difficoltà di testare tutte le configurazioni in cui il componente condiviso potrebbe essere utilizzato. Sia le applicazioni recenti che quelle meno recenti finiscono con l'utilizzare lo stesso componente e con il tempo la correzione dei difetti e il miglioramento del componente diventano sempre più difficili.

Anche la funzionalità pratica di un componente non è facile da definire. Le applicazioni potrebbero iniziare a dipendere da effetti collaterali indesiderati che non fanno parte della funzione principale del componente. Se in un'applicazione ad esempio esiste una dipendenza da un errore presente nel componente, nel momento in cui tale errore viene corretto, l'applicazione smette di funzionare. Questa situazione è nota come "incompatibilità delle DLL". Il numero di applicazioni che utilizzano ciascun componente non fa altro che accrescere il problema.

Questa mancanza di compatibilità con le versioni precedenti può rendere impossibile distribuire una nuova applicazione senza dover interferire con applicazioni già distribuite o compromettere le funzionalità della nuova applicazione. In qualsiasi nuova applicazione è necessario utilizzare una versione di un componente condiviso diversa da quella già distribuita. Per garantire una corretta condivisione e consentire nel contempo il miglioramento della stabilità delle applicazioni, Microsoft ha introdotto la condivisione affiancata in Windows 2000 e in Windows 98 Seconda Edizione, creando un modo nuovo di condividere i componenti mediante l'isolamento selettivo.

Informazioni di base

Prima di esaminare in modo dettagliato la condivisione affiancata, è opportuno rivolgere l'attenzione ad alcune questioni di fondo e ai problemi connessi all'incompatibilità delle DLL.

Condivisione di componenti

La strategia della condivisione è stata adottata da Windows sin dagli esordi. In tutti i sistemi operativi è necessario trovare un compromesso tra l'esigenza di fornire servizi completi e affidabili e i limiti delle risorse dell'hardware per cui il sistema operativo è stato progettato. Fino a poco tempo fa l'utilizzo della CPU e lo spazio su disco costituivano risorse molto vincolanti per la piattaforma PC. Un modo ovvio per ridurre al minimo lo spazio occupato dal codice del sistema operativo e da quello delle applicazioni consisteva nella massima condivisione possibile del codice. Tra i vari vantaggi, la condivisione del codice consente di ottimizzare lo sfruttamento delle risorse hardware e di ridurre al minimo la parte destinata ai test del controllo di qualità. La condivisione del codice pertanto ha contribuito al successo di Windows.

In Windows, la condivisione non si limita al solo codice. Lo stato delle applicazioni e dei componenti si trova in tutto il sistema operativo sotto forma di stato del Registro di sistema, archiviazione di dati specifici delle applicazioni nel file system e API Windows che consentono di esporre spazi dei nomi globali. Tale condivisione consente un alto livello di interoperabilità tra le applicazioni create da produttori diversi di programmi software, riducendo i costi e incrementando l'efficienza del software.

La condivisione tuttavia implica anche alcuni necessari svantaggi, in quanto comporta l'interdipendenza delle applicazioni e introduce, di conseguenza, un elemento di fragilità. Le modifiche di un componente possono produrre effetti inattesi in altri componenti. Un'applicazione, ad esempio, può diventare dipendente da una particolare versione di un componente condiviso. Quando viene installata un'altra applicazione con una versione aggiornata (o meno recente) di tale componente condiviso, la prima applicazione potrebbe risentire del cambiamento. In casi estremi, le applicazioni che prima funzionavano correttamente iniziano inspiegabilmente a presentare comportamenti anomali o addirittura non rispondono più. Questa situazione è nota come "incompatibilità delle DLL".

Isolamento

In un sistema, l'opposto della condivisione è l'isolamento. Le applicazioni possono essere isolate associando staticamente tutte le risorse e il codice dell'applicazione. Un completo isolamento tuttavia non è fattibile oggi per le applicazioni nelle quali vengono utilizzate risorse COM o altre risorse di sistema archiviate globalmente.

Una soluzione per ridurre la fragilità delle applicazioni consiste nell'isolare selettivamente le applicazioni e i componenti. In uno scenario di questo tipo, le applicazioni possono accedere tutte al medesimo componente, ma possono essere disponibili più versioni di tale componente. I produttori dei componenti sono così liberi di produrre nuove versioni di vecchi componenti, apportando migliorie e correggendo errori. I clienti, d'altro canto, possono scegliere la versione più adatta per una particolare applicazione. È un po' come andare in un negozio di ricambi per automobili e scegliere la pompa del carburante adatta alla propria utilitaria del 1984. Oltre alla pompa disponibile a magazzino, vi sono altre pompe adatte ad altri modelli di anni successivi. Nel caso dei componenti, l'importante è trovare la versione adatta a ciascuna applicazione e isolare le diverse versioni l'una dall'altra. Grazie al reindirizzamento, inoltre, le applicazioni possono essere configurate per l'utilizzo della versione adatta del componente, indipendentemente dalle altre versioni attualmente distribuite o che lo saranno in futuro.

Condivisione affiancata

Per promuovere l'isolamento, in Microsoft Windows 2000 e Windows 98 Seconda Edizione è stata introdotta una nuova modalità di condivisione dei componenti, denominata condivisione affiancata, che consente di utilizzare l'isolamento selettivo per ridurre al minimo il problema dell'incompatibilità delle DLL. La condivisione affiancata consente l'esecuzione contemporanea di più versioni dello stesso componente (COM o Win32®) in diversi processi. Le applicazioni potranno quindi utilizzare la versione specifica di un componente per il quale sono state progettate e testate, anche se in un'altra applicazione è richiesta una versione diversa dello stesso componente. Ciò consente agli sviluppatori di creare e distribuire applicazioni più affidabili in quanto è possibile specificare la versione del componente da utilizzare, indipendentemente dalle altre applicazioni presenti nel sistema.

Nuove strategie per la condivisione dei componenti



Per la condivisione affiancata in Windows 2000 e Windows 98 Seconda Edizione sono state adottate due strategie:
  • Creazione di componenti affiancati. Gli sviluppatori creano nuovi componenti in grado di supportare l'esecuzione simultanea di più versioni di tali componenti. I consumer di questi nuovi componenti sono quindi in grado di utilizzare la versione per cui questi ultimi sono stati generati e installati, indipendentemente dalle altre versioni installate nel computer.
  • Reindirizzamento DLL/COM. Gli sviluppatori e gli amministratori ricompilano le applicazioni e i componenti esistenti in modo che le versioni necessarie dei componenti condivisi siano di esclusiva pertinenza dell'applicazione che ne fa uso. In questo modo ogni versione viene eseguita a fianco delle altre versioni.


I componenti affiancati, sia che siano stati creati di recente sia che costituiscano parte di un'applicazione esistente riconfigurata, non sono supportati in tutti le situazioni.
  • La situazione ideale per la creazione di componenti affiancati si verifica quando i componenti sono ospitati, durante l'elaborazione, all'interno di un'altra applicazione contenitore. Se ad esempio vi sono controlli che devono essere utilizzati in un'applicazione desktop Windows scritta con Microsoft Visual Basic® o Visual C++®, essi potranno utilmente essere progettati come componenti affiancati. È sconsigliato l'impiego di componenti affiancati nel contesto di un server IIS o in un server MTS.
  • La situazione ideale per il reindirizzamento DLL/COM si verifica quando vengono distribuite nuove applicazioni client in computer che già supportano diverse applicazioni o quando è necessario rendere le nuove applicazioni client più elastiche alle modifiche dei componenti condivisi provocate dall'installazione di altre applicazioni. Si sconsiglia l'impiego del reindirizzamento DLL/COM nel contesto di un server IIS (applicazione Web) o in un server MTS/COM+1.0. Nuove soluzioni sono allo studio per consentire l'isolamento in questi scenari in futuro. I componenti non reindirizzati vengono supportati normalmente in questi ambienti.
    Nota Il reindirizzamento DLL/COM consente la soluzione di conflitti tra applicazioni quando vengono distribuiti componenti e applicazioni esistenti. Quando si sviluppano nuove applicazioni o nuovi componenti, la strategia migliore consiste nello sviluppo di componenti affiancati intrinsecamente isolati.
Confronto delle due strategie

Nella tabella che segue vengono confrontati i due approcci, il reindirizzamento DLL/COM e la creazione di componenti affiancati (SxS, side-by-side), e vengono fornite indicazioni per la scelta dell'approccio più adatto al proprio scenario.

Tabella 1. Confronto tra le strategie di affiancamento

AttributiComponenti affiancatiReindirizzamento DLL/COMQual è lo scopo principale?Generare nuovi componenti robusti che nelle versioni future siano immuni da modifiche che li potrebbero rendere incompatibili con le versioni precedenti.Isolare le applicazioni esistenti dai problemi causati da altre applicazioni con le quali vengono installate DLL condivise incompatibili.Le versioni isolate sono specifiche delle applicazioni che le utilizzano?Sì. I componenti affiancati devono sempre essere distribuiti in modo da essere isolati nelle applicazioni che li utilizzano.Sì. Le applicazioni che utilizzano il reindirizzamento DLL/COM utilizzano le versioni dei componenti condivisi installati nella directory dell'applicazione, indipendentemente dalle versioni installate in altri punti del sistema.È necessario creare codice nuovo o modificare quello esistente?Sì. La generazione di componenti affiancati o la trasformazione di quelli esistenti in componenti affiancati richiede almeno che il codice di registrazione COM venga modificato al fine di consentire l'accesso tramite il percorso relativo. Potrebbero essere necessarie ulteriori modifiche al codice per assicurare la corretta gestione dello stato globale tra le versioni dei componenti affiancati in esecuzione.No. Il reindirizzamento DLL/COM consente alle applicazioni di essere riconfigurate per installare ed eseguire i componenti affiancati senza la necessità di modificare o ricompilare il codice. Ciò consente agli amministratori che non hanno accesso al codice sorgente di un'applicazione di riconfigurarlo per risolvere i problemi causati dall'incompatibilità delle DLL.La strategia funziona in tutti gli scenari possibili?Sì. I componenti affiancati sono progettati e codificati per essere installati ed eseguiti in modalità SxS. I componenti affiancati, come anche le applicazioni che li utilizzano, se progettati, sviluppati e testati correttamente non presenteranno i problemi connessi all'incompatibilità delle DLL.No. Il reindirizzamento DLL/COM non richiede modifiche al codice. Le applicazioni e i componenti esistenti potrebbero non essere stati progettati prevedendo l'esecuzione contemporanea di più di una versione. L'esperienza ha dimostrato che nella maggior parte dei casi è possibile eseguire i componenti affiancati nelle applicazioni e nei componenti esistenti; è necessario tuttavia verificare questo dato nel caso specifico. Consultare Selezione dei componenti da isolare.


In generale valgono le seguenti considerazioni:
  • Se i problemi causati dall'incompatibilità delle DLL impediscono la distribuzione di un'applicazione esistente, utilizzare il reindirizzamento DLL/COM per isolare i componenti in conflitto. Per meglio comprendere questa opzione, vedere gli scenari presentati di seguito.
  • Se si crea una nuova applicazione e si desidera progettarla e svilupparla in modo da ovviare ai problemi relativi all'incompatibilità delle DLL, sviluppare componenti affiancati.
Creazione di nuovi componenti affiancati

Per implementare la condivisione affiancata è necessario che durante la creazione di nuove applicazioni vengano scritti componenti affiancati, i quali non sono altro che normali componenti COM o Win32 che tuttavia vengono installati nella directory, o in una sottodirectory, dell'applicazione anziché nella directory di sistema. Essi sono isolati in una determinata applicazione e pertanto non vengono condivisi globalmente da tutte le applicazioni.

Un componente quindi può essere installato senza problemi a fianco di una diversa versione dello stesso componente installata nella directory di un'altra applicazione. Se da un'altra applicazione del sistema viene richiesta e installata una versione diversa, questo non interferirà con la propria applicazione. Entrambe le applicazioni verranno eseguite con le rispettive versioni del componente.

Se nel sistema viene installata una nuova versione di un componente, la versione già presente rimarrà inalterata in quanto è stata installata nella directory dell'applicazione, e continuerà a essere utilizzata dall'applicazione con la quale è stata fornita, mentre la nuova applicazione utilizzerà la propria versione. Il sistema operativo infatti consente di caricare contemporaneamente entrambe le versioni.

Analogamente, poiché il componente affiancato è "privato" per l'applicazione con cui è stato installato, potrà essere rimosso in qualsiasi momento senza problemi tramite il programma di disinstallazione dell'applicazione. Per definizione, infatti, nessun'altra applicazione può dipendere da un componente privato.

Nota I componenti affiancati devono essere registrati in modo corretto nel sistema operativo, come indicato più avanti in questo articolo, affinché non insorgano conflitti con le altre versioni eventualmente esistenti.
Nota La condivisione affiancata è supportata da Windows 2000 e Windows 98 Seconda Edizione, ma non è supportata dai precedenti sistemi operativi Windows. In questi ultimi, tuttavia, è possibile installare nella directory di sistema una DLL affiancata, ovvero una DLL scritta secondo le indicazioni fornite nella sezione successiva. Tale DLL verrà condivisa globalmente e sarà quindi compatibile con le versioni precedenti. È necessario controllare dinamicamente la versione del sistema operativo per stabilire la tecnica di condivisione da utilizzare nelle applicazioni.
Indicazioni per la scrittura di componenti affiancati

Di seguito vengono evidenziate le problematiche proprie della creazione di componenti affiancati (COM o Win32). Quando questi componenti vengono inseriti nella directory dell'applicazione, il codice diventa disponibile esclusivamente nel contesto dell'applicazione. Quando i dati vengono inseriti nel Registro di sistema in base al nome dell'applicazione, essi vengono riservati esclusivamente a tale applicazione.

I consumer del componente affiancato non vengono interessati dalle modifiche che potrebbero essere richieste da altri consumer del componente. È inoltre possibile aggiornare i componenti senza timore di danneggiare le applicazioni esistenti. Le applicazioni sono in grado di installare il componente senza eseguire il riavvio del sistema, anche se in un'altra applicazione è in uso una diversa versione del componente.

Nota Queste indicazioni costituiscono un rafforzamento di quelle attualmente fornite con la certificazione Windows, nelle quali viene indicato di collocare le DLL Win32 nella directory dell'applicazione.
Indicazioni generali

  • Non tentare di sostituire i file protetti mediante la protezione dei file di sistema di Windows 2000, quali i file SYS, DLL, EXE e OCX.
  • Sottoporre a test tutti i componenti per accertarsi della validità dell'affiancamento, specialmente nelle aree in cui si verifica la condivisione, poiché i sistemi operativi attuali non sono in grado di imporre l'affiancamento.
  • Raccogliere tutti i nomi specifici delle versioni in #defines per attivare la migrazione semplificata del codice sorgente da una versione a un'altra. In questo modo è possibile modificare la versione in un solo punto. Tutte le chiavi del Registro di sistema verranno modificate automaticamente. Ad esempio: #define MyRegistryKey "MyAppv1.0.0.0"Quando si rilascia una nuova versione del componente, è sufficiente modificare la versione in un solo punto.
  • La correzione rapida degli errori dei componenti potrebbe non essere più possibile, poiché ora i componenti si trovano in directory di applicazioni dalla posizione arbitraria. Il produttore di un componente pertanto potrebbe non essere a conoscenza di tutti i punti in cui è necessario correggere il componente. I fornitori dell'applicazione devono distribuire gli aggiornamenti ai clienti.
  • Potrebbe verificarsi una condivisione involontaria tra processi. La condivisione di sezioni di memoria ad esempio può provocare problemi poiché la stessa sezione potrebbe non essere condivisa dalle diverse versioni del componente.
  • Progettare tutte le strutture di dati condivisi in modo che possano essere affiancate, ovvero diverse per ciascuna versione del componente, inclusi i file mappati in memoria, i mutex, le named pipe e i driver dell'hardware.
  • Archiviare i dati non persistenti nella directory TEMP.
  • Non collocare i dati dell'utente nei percorsi globali. I dati dell'applicazione devono essere chiaramente separati da quelli dell'utente.
Rafforzamento dei componenti

  • Durante le installazioni e le disinstallazioni di un componente fornito da produttori diversi, è necessario eseguire correttamente il conteggio dei riferimenti per i GUID presenti nel registro globale. Il modo più affidabile è mantenere un conteggio dei riferimenti nella chiave GUID. HKEY_CLASSES_ROOT\CLSID\{GUID}\InprocServer32 Default=foo.dll ThreadingModel=Apartment RefCount=1
    Nota Il conteggio dei riferimenti della DLL deve essere eseguito indipendentemente dal GUID.
  • Non registrare i nomi di percorso completi per le registrazioni COM. Per trovare il componente e le relative dipendenze potrebbe essere necessario effettuare una ricerca nella directory dell'applicazione.
  • Se nel GUID COM vengono modificati i metadati, come ad esempio il modello di threading, sarà necessario ridenominare il componente e assegnargli un nuovo GUID, poiché in realtà si tratta di una nuova versione del componente. Questa operazione è necessaria perché i dati presenti nel Registro di sistema non sarebbero validi nel contesto di un'altra applicazione, con la versione riservata del componente di tale applicazione.
  • La libreria dei tipi deve essere contenuta all'interno della DLL e non in un file separato.
  • Non utilizzare la funzione LoadRegTypeLib per caricare le librerie dei tipi nel Registro di sistema. La registrazione della libreria dei tipi nel Registro di sistema costituisce uno stato globale ed è contraria alle regole dell'utilizzo riservato. È invece necessario utilizzare LoadType Lib.
  • La capacità di OLEAUT di creare una nuova versione di librerie dei tipi esterne è limitata e soggetta ad errori. Si consiglia di non utilizzare librerie dei tipi esterne per i componenti affiancati.
  • Quando si modifica un componente esistente per renderlo affiancato, viene modificato anche il modo in cui esso viene attivato per utilizzare un percorso relativo e isolare lo stato globale. È importante assegnargli un nuovo CLSID, un nuovo ProgId e rinominare il file, quindi utilizzare il CLSID, il ProgId e il nuovo nome file per le versioni affiancate future. In questo modo si evitano i conflitti che altrimenti si verificherebbero qualora una versione non affiancata di un componente venisse registrata al posto di una versione affiancata. I componenti affiancati non sono compatibili con le versioni precedenti non affiancate.
Archiviazione dello stato

  • Le impostazioni relative allo stato memorizzate nel Registro di sistema devono essere "privatizzate" per il contesto dell'applicazione eseguita. È possibile utilizzare la funzione GetModuleFileName() per impostare una directory principale virtuale. Questa operazione deve essere eseguita per le diramazioni HKLM e HKCU.
  • Le impostazioni del Registro di sistema vanno effettuate versione per versione al fine di ottenerne l'isolamento. I componenti in genere memorizzano il proprio stato nelle chiavi del Registro di sistema. Poiché sul computer possono esistere versioni diverse del componente, è importante semplificare il più possibile il controllo delle versioni presenti nelle chiavi durante la ricompilazione. A tale scopo possono risultare utili i file di intestazione e API di supporto.
  • Archiviare lo stato del Registro di sistema in chiavi conformi alla seguente convenzione di denominazione: HKCU\MyCompany\MyComponent\VersionXXXX\

    Si supponga, ad esempio, che esista un'impostazione di configurazione denominata EnableSuperCoolFeature con il valore true o false. Di solito, queste informazioni vengono archiviate nel Registro di sistema nel modo seguente: HKEY_CurrentUser\Software\MyCompany\MyComponent\ EnableSuperCoolFeature = TRUE

    Se si utilizza la condivisione affiancata, è necessario archiviarle come segue: HKEY_CurrentUser\Software\MyCompany\MyComponent\Ve rsion01.01 EnableSuperCoolFeature = TRUE
  • In alternativa, se si stabilisce la necessità dell'isolamento per ciascuna applicazione, è possibile utilizzare la seguente istruzione: HKCU\MyCompany\MyComponent\VersionXXYY\SomeApplica tion\\dove "SomeApplication" è il valore restituito da GetModuleFileName. In tal modo è possibile isolare le impostazioni di un componente solo per l'applicazione in cui viene eseguito.
  • L'ideale è implementare un modello di persistenza affinché venga conservato lo stato e il Registro di sistema non venga alterato dall'applicazione. Le voci del Registro di sistema relative al componente non dovrebbero essere modificate direttamente dall'applicazione; le impostazioni compatibili con la modalità affiancata dovrebbero invece essere salvate e ripristinate dalle API del componente.
  • Per consentire l'interazione con uno stato globale, le impostazioni archiviate in punti diversi dal Registro di sistema dovrebbero essere memorizzate in modalità affiancata in una delle seguenti posizioni:
    • Un archivio protetto (pstore)
    • Una cache WinInet
    • Un database Microsoft SQL Server o Microsoft Jet
Installazione di componenti affiancati

Operazioni preliminari

Prima di installare i componenti affiancati è necessario controllare se sono supportati o meno dal sistema operativo. Il codice seguente consente di rilevare se la condivisione affiancata è disponibile. Qualora non lo sia, è necessario installare i componenti nella directory di sistema.

BOOL bPlatformSupportsSideBySide(void){ OSVERSIONINFOEX osviex ; osviex.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); // If platform does not support OSVERSIONINFOEX structure, it does not // have side by side support // In the kernel we have made these modifications hand-in-hand... // if (!GetVersionEx((OSVERSIONINFO *)&osviex)) { return FALSE ; // no DLL redirection } // For the other platform Ids, assume has side-by-side support return TRUE ;}Installazione e disinstallazione

È estremamente importante installare e disinstallare correttamente il componente. In teoria le procedure di installazione e disinstallazione del componente dovrebbero coincidere con la semplice copia o eliminazione di tale componente nella directory dell'applicazione. Se tuttavia è necessario eseguire la registrazione COM o una qualsiasi configurazione iniziale del componente, è necessario che ciò avvenga in modo compatibile con la modalità affiancata.

Windows Installer versione 1.1 incluso in Windows 2000 consente di eseguire l'installazione e la disinstallazione dei componenti affiancati. Windows Installer sarà disponibile anche in linea dopo il rilascio di Windows 2000. Al momento della registrazione del componente COM affiancato, è necessario accertarsi che nella colonna Attributes della tabella Class sia impostato il bit msidbClassAttributesRelativePath. In tal modo il componente verrà registrato con un nome di percorso relativo, consentendo l'esistenza di più copie dello stesso componente.

È importante ricordare che sebbene il componente sia privato nella directory dell'applicazione, una versione diversa del componente potrebbe essere stata installata da un'altra applicazione nello stesso computer. Poiché durante l'installazione o la disinstallazione del componente non si intende in alcun modo danneggiare le altre applicazioni, è importante che l'installazione dell'applicazione che utilizza il componente venga eseguita correttamente utilizzando i punti di ingresso di registrazione automatica DLLRegisterServer, DLLUnregisterServer, per i componenti COM, o DllInstall, per i componenti Win32 o COM. Per ulteriori informazioni su queste funzioni, consultare "Register Server" nella documentazione di Platform SDK.



Per installare correttamente il componente nella directory dell'applicazione, procedere come per l'installazione dei normali componenti, con l'aggiunta delle seguenti operazioni:
  1. Quando si registrano i GUID, assicurarsi che dispongano di nomi di percorso relativi.
  2. Accertarsi di disporre di un conteggio dei riferimenti relativo al GUID.
    Ciò consentirà di tenere traccia del numero di volte in cui il GUID è stato installato o disinstallato.
  3. Se il GUID esiste, incrementare il conteggio dei riferimenti.
    Oppure
    Se non esiste, è necessario aggiungere il GUID e inserire un valore di uno come conteggio dei riferimenti. Ad esempio: {00000109-0000-0010-8000-00AA006D2EA4}\InprocServer32Default = "mycomponent.dll"ReferenceCount=1
    Nota Le librerie dei tipi devono essere contenute all'interno della DLL e non è necessario registrarle nel Registro di sistema.


Per disinstallare correttamente il componentenella directory dell'applicazione, procedere come per i normali componenti, con l'aggiunta della seguente operazione:
  • Diminuire il conteggio dei riferimenti. Se si raggiunge 0, è possibile eliminare il GUID in quanto non esistono più utenti. Se il numero è superiore a 0, significa che nel sistema è installata un'altra applicazione che dipende dallo stato indicato nel Registro di sistema.
Reindirizzamento DLL/COM

Con il reindirizzamento DLL/COM, al momento della distribuzione dell'applicazione, il relativo eseguibile e tutti i componenti isolati vengono installati nella directory dell'applicazione invece che nella directory di sistema. Nella directory dell'applicazione inoltre viene distribuito un file LOCAL per modificare la modalità di associazione di Windows, in modo che l'applicazione venga associata ai componenti isolati invece che alla versione condivisa globalmente.

Dall'applicazione pertanto verrà utilizzato un componente che può essere eseguito senza problemi a fianco di una diversa versione dello stesso componente installata nella directory di un'altra applicazione o nella directory di sistema. Se per un'altra applicazione del sistema è richiesta una versione diversa, la propria applicazione non ne verrà influenzata ed entrambe le applicazioni verranno eseguite con le rispettive versioni del componente.

Se nel sistema viene installata una nuova versione di un componente da un'altra applicazione, la versione del componente già presente nell'applicazione rimarrà inalterata in quanto è stata installata nella directory dell'applicazione, e continuerà a essere utilizzata dall'applicazione con la quale è stata fornita, mentre la nuova applicazione utilizzerà la propria versione. Il sistema operativo infatti consente di caricare contemporaneamente entrambe le versioni.

Nota I componenti COM isolati devono essere registrati in modo corretto nel sistema operativo affinché ciascuna versione del componente non entri in conflitto con le altre versioni eventualmente esistenti. Tale registrazione implica che, sebbene l'implementazione del componente possa cambiare da una versione all'altra, i metadati COM registrati come CLSID, ProgID, la libreria dei tipi e il modello di threading rimangano invariati da una versione all'altra.
Nota Il reindirizzamento DLL/COM è supportato da Windows 2000 e Windows 98 Seconda Edizione, ma non è supportato dai precedenti sistemi operativi Windows.
Utilizzo del reindirizzamento DLL/COM

Il reindirizzamento DLL/COM consente allo sviluppatore o all'amministratore di isolare selettivamente i componenti esistenti in modo da riservarli all'applicazione in fase di creazione o di distribuzione. In questa sezione viene illustrato come attivare il reindirizzamento DLL/COM e come selezionare i componenti da isolare.

Attivazione del reindirizzamento DLL/COM

Il reindirizzamento DLL/COM viene attivato per ogni singola applicazione mediante la presenza di un file LOCAL, un file vuoto situato nella stessa directory in cui si trova il file EXE dell'applicazione e dotato dello stesso nome del file EXE dell'applicazione, con l'aggiunta dell'estensione LOCAL.

Per attivare il reindirizzamento DLL/COM per un'applicazione chiamata "miaappl.exe", ad esempio, è necessario creare un file vuoto denominato "miaappl.exe.local" nella stessa directory in cui è installato il file miaappl.exe.

Una volta attivato il reindirizzamento DLL/COM, al caricamento di un file DLL o OCX, questi file vengono cercati dapprima nella directory in cui è installato il file EXE dell'applicazione. Se nella directory in cui è installato il file EXE dell'applicazione è presente una versione del file DLL o OCX, questa verrà utilizzata indipendentemente dall'eventuale percorso di directory specificato nell'applicazione o nel Registro di sistema. Se invece non è presente, verrà utilizzato il normale percorso di ricerca o di server.

Selezione dei componenti da isolare

Il reindirizzamento DLL/COM consente di isolare i componenti esistenti nel caso in cui le applicazioni installate in un computer richiedano versioni diverse dello stesso componente. Non è necessario modificare il codice del componente in quanto, una volta attivato, il reindirizzamento DLL/COM modifica la modalità di associazione di Windows.

Finora, tuttavia, l'esecuzione affiancata di versioni diverse dei componenti in genere non è stata tenuta in considerazione in fase di progettazione. Sebbene i componenti possano essere facilmente installati uno accanto all'altro in un percorso condiviso e isolati in una o più applicazioni, non sempre possono essere eseguiti in modalità affiancata, in quanto alcuni componenti utilizzano lo stato globale, come le impostazioni memorizzate nel Registro di sistema, presumendo che vi sarà una sola versione del componente alla volta in esecuzione sul computer. È possibile inoltre che le altre risorse necessarie vengano ricercate automaticamente nella directory specifica in cui è installato il componente.

Per questi motivi è indispensabile testare le applicazioni nelle quali vengono utilizzati componenti isolati installati sia in modo indipendente che nel contesto di altre applicazioni da cui i componenti sono isolati. L'esperienza mostra che nella maggior parte degli scenari i componenti comunemente condivisi possono essere eseguiti in modalità affiancata, ma che in alcuni casi potrebbe essere necessario chiudere un'applicazione prima di poter eseguire quella successiva.



Quando si selezionano i componenti da isolare è buona norma attenersi alle indicazioni seguenti:
  • Non tentare di isolare i file protetti mediante la protezione dei file di sistema di Windows 2000, quali i file SYS, DLL, EXE e OCX.
  • Sottoporre a test tutte le applicazioni per accertarsi della validità dell'affiancamento, specialmente nelle aree in cui si verifica la condivisione, poiché i sistemi operativi attuali non sono in grado di imporre l'affiancamento.
  • La correzione rapida degli errori dei componenti potrebbe non essere più possibile, poiché ora i componenti si trovano in directory di applicazioni dalla posizione arbitraria. L'amministratore dovrà essere a conoscenza di tutti i punti in cui è necessario correggere il componente.
Scenario I: controlli ActiveX riservati a un'applicazione

In questo scenario si suppone che un amministratore non sia in grado di distribuire una nuova applicazione poiché essa utilizza una versione di un controllo ActiveX creato con Visual Basic che risulta diversa da quella richiesta dalle applicazioni attualmente distribuite.

Le correzioni degli errori e tutte le altre modifiche apportate al controllo ActiveX nel tempo hanno introdotto differenze semantiche tali da determinare il blocco delle applicazioni se non viene utilizzata la versione con cui sono state testate. L'amministratore deve perciò poter eseguire versioni diverse del controllo ActiveX con le diverse applicazioni che lo utilizzano, evitando di dover correggere gli errori e di testare di nuovo ogni applicazione che potrebbe essere influenzata dalla sostituzione del controllo ActiveX.

Nota In Visual Basic non esiste attualmente un modo semplice per scrivere controlli ActiveX affiancati in modo intrinseco, poiché al momento della registrazione dei controlli ActiveX creati con Visual Basic, nel Registro di sistema viene inserito il percorso completo del file OCX.

L'amministratore può imporre alla nuova applicazione l'utilizzo della versione corretta del controllo ActiveX e assicurarsi che la configurazione delle applicazioni esistenti rimanga invariata modificando l'impostazione della nuova applicazione come segue:
  • Installare la nuova versione del controllo ActiveX nella directory in cui si trova il file EXE dell'applicazione.
  • Nella directory in cui si trova il file EXE dell'applicazione installare un file LOCAL con il quale si specifica che, ogni volta che l'applicazione viene eseguita, il controllo ActiveX deve essere caricato dalla directory in cui è situato il file EXE dell'applicazione.
Scenario II: DLL Win32 riservate a un'applicazione

In questo scenario si suppone che l'amministratore scopra che un'applicazione esistente si blocca dopo la distribuzione di una nuova applicazione. L'amministratore riesce a stabilire che la causa del problema sono le modifiche apportate a un componente condiviso, che hanno fatto sì che la una nuova versione di tale componente sia incompatibile con le versioni precedenti.



L'amministratore può correggere l'applicazione attenendosi alla seguente procedura:
  • Installare la versione precedente della DLL condivisa nella directory in cui si trova il file EXE dell'applicazione esistente.
  • Creare un file LOCAL nella directory in cui si trova il file EXE dell'applicazione esistente. Con il file LOCAL si specifica che al momento dell'esecuzione dell'applicazione dovranno essere caricate le DLL che si trovano nella directory in cui è presente il file EXE dell'applicazione.
Considerazioni sull'installazione di server COM isolati

Il reindirizzamento DLL/COM si ottiene installando il file DLL od OCX in un nuovo percorso riservato all'applicazione. Un altro stato di sistema associato ai server COM tuttavia non verrà isolato e questo comporta delle conseguenze per l'isolamento dei server COM.



Quando si installa un server COM isolato, si deve prestare estrema attenzione affinché il percorso del file InprocServer non venga sovrascritto dal nuovo percorso del componente isolato qualora una versione di quest'ultimo sia già stata installata nel computer, ad esempio, da un'altra applicazione. Per i server COM isolati, il percorso del file InprocServer viene ignorato in fase di esecuzione. Per le applicazioni esistenti che non utilizzano il reindirizzamento DLL/COM, tuttavia, è necessario che nel percorso del file InprocServer continui ad essere specificato il percorso del server COM installato in precedenza. Di conseguenza:
  • Quando si installa un server COM isolato, qualora nel computer sia già installata una qualsiasi versione del server COM, non registrare il server COM isolato al momento dell'installazione.


Se invece nel computer non è ancora installata alcuna versione del server COM isolato, è necessario registrarlo. Il problema si verifica quando un server COM viene isolato in un'applicazione, viene installato nella directory dell'eseguibile dell'applicazione e in seguito vengono installate applicazioni non isolate per le quali è richiesto tale componente. In questo caso è improbabile che i componenti COM isolati vengano considerati come file condivisi dal programma di disinstallazione dell'applicazione isolata e pertanto la disinstallazione determinerà il blocco di altre applicazioni. Di conseguenza:
  • Quando si installa un server COM isolato, qualora nel computer non sia già installata alcuna versione del server COM, copiare il file DLL o OCX sia nella directory in cui si trova il file EXE dell'applicazione che nella directory di sistema, o in un altro percorso condiviso, e registrare la copia nella directory di sistema o in un altro percorso condiviso.
Per quanto riguarda i componenti esistenti, se vi sono versioni che potrebbero essere condivise da alcune applicazioni e altre riservate ad altre applicazioni, applicare la seguente regola generale: dopo aver installato le applicazioni che utilizzano versioni isolate di componenti potenzialmente condivisi, assicurarsi che siano installate sia una versione condivisa che una versione isolata del componente e che la versione condivisa sia registrata. In questo modo le versioni isolate potranno essere rimosse dai programmi di disinstallazione senza causare blocchi alle altre applicazioni.