Cos'è Reg-Free COM - Utilizzo di COM senza registrazione

· Aggiornato il: · · COM, Reg-Free COM, Registration-Free COM, Sviluppo Windows, Tecnologia legacy

Nei progetti COM / ActiveX / OCX, lo stesso fango viene fuori con ogni distribuzione e aggiornamento.

  • regsvr32 è obbligatorio
  • I privilegi di amministratore tendono a diventare necessari
  • Ti scontri con una versione diversa installata da un’altra app
  • Una disinstallazione trascina con sé altri prodotti
  • Funziona sulla macchina di sviluppo ma fallisce in un ambiente pulito

Ciò che può ridurre significativamente questa palude è Reg-Free COM. Detto questo, nonostante il nome, non è “la magia che fa sparire tutti i mal di testa di COM”. Ciò che rimuove principalmente sono i mal di testa trascinati dalla registrazione globale. Non elimina le difficoltà legate ai bit, al DLLs dipendente, alle librerie di tipi o ai modelli di threading.

In questo articolo organizziamo Reg-Free COM principalmente attorno al contesto di mantenere COM DLLs / OCXs locale dell’applicazione nelle app desktop Windows.

1. Prima la conclusione (in un soffio)

Cominciamo con un modo approssimativo ma utile di dirlo.

  • Reg-Free COM è un modo per conservare le informazioni di registrazione COM in un manifest anziché nel registro
  • In fase di esecuzione, quando si risolve CoCreateInstance o CLSIDFromProgID, viene consultato per primo il contesto di attivazione
  • Di conseguenza, COM DLLs / OCXs può essere mantenuto privato per applicazione
  • I vantaggi principali sono facile implementazione di XCOPY, più facile evitare conflitti di versione e disinstallazioni più difficili da violare
  • Tuttavia, il problema 32-bit / 64-bit non scompare. Nessuna quantità di forza di volontà ti farà superare questo
  • Inoltre, DLLs dipendente, librerie di tipi, riferimenti in fase di progettazione e dipendenze di registrazione non standard devono essere considerati separatamente
  • In pratica, è un’ottima soluzione quando desideri spedire componenti COM specifici dell’app insieme all’app

In breve, Reg-Free COM è un meccanismo che riporta l’attivazione di COM al livello per applicazione.

2. Cosa significa questo articolo per Reg-Free COM

Reg-Free COM è l’abbreviazione di Senza registrazione COM. In giapponese a volte viene scritto come “registrazione non richiesta COM”.

“Senza registrazione” qui significa non completamente dipendente dalla registrazione del registro globale come HKCR / CLSID / InprocServer32 per poter utilizzare COM. Ciò non significa che COM itself disappears, né che GUIDs become unnecessary.

Gli argomenti principali di questo articolo sono cose come le seguenti.

  • Nativo COM DLLs
  • Server COM basati su ATL
  • ActiveX / OCX
  • Interoperabilità COM basata su .NET Framework
  • Esposizione COM utilizzando l’host .NET 5+ / .NET 8 COM

Viceversa, ci sono due punti che questo articolo vuole sottolineare.

  1. Reg-Free COM riguarda l’“attivazione”
  2. La distribuzione delle informazioni sul tipo e la configurazione dei riferimenti in fase di progettazione possono rimanere questioni separate

Mescolare questi elementi confonde notevolmente la discussione.

3. L’intera immagine in una pagina

È più veloce guardare prima il quadro generale su una singola pagina.

MyApp.exeApplication manifestDependent assemblyComponent manifestfile / comClass / typelibVendorControl.dll/.ocxActivation contextCLSIDFromProgID / CoCreateInstance

Nell’ordinario COM, la chiamata a CoCreateInstance percorre il registro per decidere which DLL to load. In Reg-Free COM, prima che ciò accada, viene consultato il contesto di attivazione attualmente attivo e la risoluzione viene effettuata dalle informazioni manifest scritte lì.

Per questo motivo, l’app A e l’app B sullo stesso computer possono essere eseguite più facilmente trasportando versioni diverse della stessa famiglia di componenti COM. Spinge leggermente la cultura di condivisione di COM verso l’essere locale dell’applicazione.

4. Perché l’implementazione ordinaria COM tende a diventare pesante

La distribuzione ordinaria di COM è pesante non tanto perché COM in sé non è valido, ma a causa del presupposto della registrazione globale.

Per utilizzare una classe COM, sono necessarie più o meno questo tipo di informazioni.

Informazioni Ruolo
CLSID GUID che identifica univocamente la classe
ProgID Nome adatto all’uomo
InprocServer32 Quale DLL caricare
ThreadingModel Presupposti come Apartment / Both
TypeLib Digitare informazioni

Una volta inseriti nel registro, sono convenienti a livello di macchina, perché sono facili da condividere tra più app.

In pratica, tuttavia, questa condivisione si ritorce contro.

  • La configurazione di un prodotto sovrascrive la registrazione COM di un altro prodotto
  • Un programma di disinstallazione “pensa di aver rimosso solo i propri contenuti” e interrompe la condivisione COM
  • Una registrazione esistente sulla macchina di sviluppo non esiste sulla macchina di produzione
  • Le registrazioni 32-bit e 64-bit non riescono a integrarsi e solo i sintomi vagano stranamente

In altre parole, il modello di distribuzione crea problemi alle persone molto più spesso di quanto non faccia lo stesso COM. Reg-Free COM è un meccanismo per ridurre le difficoltà di questo modello di distribuzione.

5. Come funziona Reg-Free COM

5.1 Dichiarare le dipendenze nel manifest dell’applicazione

Innanzitutto, il lato dell’app scrive da quali assembly affiancati dipende nel manifesto dell’applicazione.

Questo manifest può essere gestito in entrambi i modi:

  • posizionato accanto al EXE, come MyApp.exe.manifest
  • incorporato nel EXE come risorsa

In pratica, una divisione comune è: utilizzare un file esterno se si desidera che la distribuzione e la sostituzione rimangano visibili, oppure incorporarlo se si dà priorità alla robustezza e alla distribuzione semplice.

Tieni presente che quando esistono sia una versione di file esterno che una versione incorporata, il manifest sul file system ha la precedenza.

5.2 Descrivere le informazioni COM nel manifest del componente

Successivamente, il lato COM trasporta le informazioni che altrimenti rimarrebbero nel registro in un manifest del componente.

Le informazioni che entrano qui includono, ad esempio:

  • comClass
  • clsid
  • progid
  • threadingModel
  • typelib
  • se necessario, proxy / stub, classi di finestre e così via

In altre parole, l’idea è di descrivere l’aspetto del componente COM in XML invece che nel registro.

Questo manifest può essere configurato in entrambi i modi:

  • inserito come file separato accanto a DLL
  • incorporato nel DLL come risorsa

In pratica, incorporarlo nel DLL come assemblaggio privato tende a causare meno incidenti. Operare con un file separato è più semplice da comprendere, ma è facile inciampare nella mappatura tra il nome del file e assemblyIdentity, la posizione di posizionamento e le copie mancate.

5.3 In fase di runtime viene consultato per primo il contesto di attivazione

Questo è il cuore di Reg-Free COM.

Quando l’app chiama CLSIDFromProgID o CoCreateInstance, il runtime COM esamina il contesto di attivazione attivo. Se sono presenti le informazioni necessarie su ProgID → CLSID e CLSID → DLL, la risoluzione riesce senza toccare il registro.

Viceversa, se il manifest è privo delle informazioni necessarie, si ricorre alla consueta risoluzione basata sulla registrazione. Questo comportamento è ciò che crea la trappola di sembra che funzioni sulla macchina di sviluppo. Pensi di essere diventato Reg-Free, ma in realtà sei stato salvato da una registrazione locale.

Questa è la trappola più brutta di Reg-Free COM.

6. Cosa guadagni

In pratica, i vantaggi di Reg-Free COM sono abbastanza chiari.

6.1 Distribuzione XCOPY semplice

Puoi posizionare tutti i file richiesti insieme nella cartella dell’app, il che alleggerisce i passaggi di installazione e registrazione. Naturalmente, se scrivi sotto Program Files, le autorizzazioni sono una questione separata, ma come minimo puoi ridurre il lavoro di amministratore necessario per la registrazione COM.

6.2 È più semplice ridurre i conflitti di versione

Anche quando esistono più versioni di un componente COM sullo stesso computer, diventa più semplice separare la versione utilizzata da ciascuna app. Puoi in gran parte evitare l’incidente di behavior suddenly changing because of another product's setup.

6.3 Spesso richiede poche modifiche al codice esistente

Reg-Free COM è un meccanismo che cambia come avviene la risoluzione, invece di cambiare radicalmente il modo in cui il codice esistente effettua le sue chiamate. Quindi, quando si adatta bene, puoi adottarlo quasi senza modifiche al lato CoCreateInstance del codice.

6.4 La rimozione e il rollback diventano più facili

Poiché tutto è contenuto per app, gli aggiornamenti e i rollback diventano molto più semplici. In parole povere, diventa più facile adottare la mentalità di scambiare l’intera cartella.

7. Dove si adatta e dove no

7.1 Situazioni in cui è adatto

In casi come questi, Reg-Free COM è un’opzione molto forte.

Situazione Vestibilità
Desideri raggruppare un COM DLL / OCX specifico per l’app Molto buono
Vuoi che più versioni coesistano sullo stesso PC Molto buono
Vuoi evitare incidenti di registrazione con i componenti del fornitore Buono
Desideri utilizzare un ActiveX / OCX privatamente in un’app desktop esistente Buono
Desideri un’implementazione più leggera senza modifiche importanti alle chiamate esistenti Buono

In genere si adatta bene alle app desktop line-of-business, agli strumenti di integrazione delle apparecchiature e alle risorse VB6 / MFC / WinForms esistenti.

7.2 Situazioni in cui non è adatto o merita attenzione

D’altro canto ci sono casi che meritano uno sguardo attento.

Situazione Commento
Desideri condividere COM a livello di macchina I vantaggi di Reg-Free sono scarsi
Bitness non corrisponde a Reg-Free non risolve questo problema
Forte dipendenza da informazioni di registrazione non standard o da una configurazione personalizzata Difficile da esprimere in un manifest
La distribuzione del runtime dipendente DLLs o del runtime VC++ non è stata risolta In ogni caso viaggerai da qualche altra parte
Gli strumenti in fase di progettazione o le impostazioni di riferimento IDE presuppongono il registro È necessaria una progettazione operativa separata

L’ultimo punto è particolarmente importante. Reg-Free COM aiuta con l’attivazione in fase di esecuzione, ma non modifica istantaneamente ciò che presuppone l’UI di riferimento in fase di progettazione.

8. Idee sbagliate comuni

8.1 “Con Reg-Free COM il problema del Bitness scompare”

Non è così. Un processo 32-bit può caricare solo 32-bit in-process COM DLLs e un processo 64-bit può accettare solo 64-bit DLLs. Questo è esattamente lo stesso con Reg-Free di prima.

8.2 “Con Reg-Free COM l’Anagrafe non viene mai consultata”

Anche sbagliato. Se nel manifest mancano le informazioni necessarie, la risoluzione ricorre al consueto percorso basato sulla registrazione. Pertanto, il successo su una macchina di sviluppo non garantisce che la configurazione Reg-Free sia corretta.

8.3 “Con Reg-Free COM, la storia della libreria dei tipi si sistema da sola”

Questo è vero solo a metà. Un manifest può contenere anche informazioni typelib, ma è del tutto normale che la gestione delle informazioni sul tipo (VBA impostazioni di riferimento, C++ #import, generazione di riferimenti in fase di progettazione sul lato .NET e così via) richieda una progettazione separata.

Reg-Free COM riguarda, prima di tutto, il lancio delle cose. Come sviluppare con i tipi è il prossimo numero.

8.4 “Con Reg-Free COM, qualsiasi ActiveX / OCX funziona”

Anche questo è pericoloso. Se il componente si basa sulle informazioni di registrazione standard COM, puoi andare avanti senza problemi, ma quando dipende in larga misura da impostazioni di registro personalizzate, configurazioni aggiuntive, logica di licenza o un cluster di altri moduli, passare a Reg-Free diventa improvvisamente difficile.

8.5 “Reg-Free COM su .NET Framework e .NET 8 è più o meno lo stesso”

Ci sono somiglianze, ma le toolchain differiscono notevolmente. Il contesto .NET Framework + RegAsm e il contesto .NET 5+ / .NET 8 + comhost si trovano su basi diverse anche se entrambi sono COM.

9. Differenze tra nativo / .NET Framework / .NET 5+ / .NET 8

È facile confonderli, quindi separiamoli una volta.

Famiglia Riepilogo approssimativo
Nativo COM DLL / OCX Fondamentalmente si tratta di un manifesto dell’applicazione più un manifesto del componente
COM interoperabilità basata su .NET Framework Oltre al manifesto dell’applicazione in stile Win32, è necessario anche un manifesto sul lato del componente gestito
COM esposizione su .NET 5+ / .NET 8 EnableComHosting crea un host COM e EnableRegFreeCom può generare un manifest Reg-Free

9.1 .NET Basato su framework COM

Con COM basato su .NET Framework, ti ​​ritroverai con una configurazione a due livelli: un manifesto dell’applicazione in stile Win32 sul lato dell’app COM e un manifesto del componente sul lato dei componenti gestiti.

Quest’area è leggermente più complicata di quella nativa COM. Al punto di “Ho capito Reg-Free COM, ma una volta che un componente gestito viene coinvolto, improvvisamente appare un altro manifest”, il terreno della conversazione diventa di nuovo un po’ fangoso.

9.2 COM Esposizione su .NET 5+ / .NET 8

Su .NET 5+ / .NET 8, il punto di ingresso per l’esposizione COM diventa *.comhost.dll. Inoltre, l’impostazione di EnableRegFreeCom=true genera un manifest affiancato per Reg-Free COM.

Ma anche in questo caso, il punto importante è che le strategie Reg-Free COM e TLB sono separate. .NET Core / .NET 5+ non è il mondo dei .NET Framework giorni in cui a TLB naturally falls out of the assembly. Se hai bisogno dell’utilizzo digitato, è più sicuro risolvere la generazione, l’incorporamento e la registrazione di TLB come una discussione separata.

10. Uno schizzo di configurazione minima

Qui mostriamo uno schizzo minimo in cui MyApp.exe utilizza Vendor.CameraControl.dll tramite Reg-Free COM.

10.1 Schizzo del layout del file

MyApp.exe
MyApp.exe.manifest
Vendor.CameraControl.Asm.manifest
Vendor.CameraControl.dll
Vendor.Helper.dll

Nell’esempio precedente, si presuppone che il manifesto del componente sia un file separato. Si può anche incorporare nel DLL, ma in tal caso sono necessari un nome di assembly e un ID risorsa specifici (vedi 10.4).

10.2 Schizzo del manifesto dell’applicazione

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    type="win32"
    name="KomuraSoft.MyApp"
    version="1.0.0.0"
    processorArchitecture="amd64" />

  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Vendor.CameraControl.Asm"
        version="1.0.0.0"
        processorArchitecture="amd64" />
    </dependentAssembly>
  </dependency>
</assembly>

10.3 Schizzo manifesto del componente

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    type="win32"
    name="Vendor.CameraControl.Asm"
    version="1.0.0.0"
    processorArchitecture="amd64" />

  <file name="Vendor.CameraControl.dll">
    <comClass
      clsid="{01234567-89AB-CDEF-0123-456789ABCDEF}"
      progid="Vendor.CameraControl.1"
      threadingModel="Apartment"
      tlbid="{89ABCDEF-0123-4567-89AB-CDEF01234567}" />

    <typelib
      tlbid="{89ABCDEF-0123-4567-89AB-CDEF01234567}"
      version="1.0"
      helpdir="" />
  </file>
</assembly>

Ciò che conta veramente in questo esempio non sono i dettagli XML ma che dependentAssembly lato app e assemblyIdentity lato componente corrispondano. Se si allontanano, soffri piuttosto silenziosamente.

Tieni presente che GUIDs e i nomi sopra sono esempi di spiegazione. In realtà, è necessario scriverli correttamente in modo che corrispondano al modello di threading CLSID / TLBID / ProgID / che il componente effettivamente espone.

10.4. Dove mettere il manifesto e come incorporarlo

Questo è il passaggio che, come procedura, fa inciampare di più. A seconda che si tratti di file separato o incorporato in un binario, cambiano i nomi ammessi.

Per i private assembly, side-by-side cerca nell’ordine:

  1. Cartella WinSxS
  2. <appdir>\<assemblyname>.DLL
  3. <appdir>\<assemblyname>.manifest
  4. <appdir>\<assemblyname>\<assemblyname>.DLL
  5. <appdir>\<assemblyname>\<assemblyname>.manifest

Se trova prima una DLL con lo stesso nome dell’assembly, la ricerca si ferma lì. Da questo deriva che ci sono solo due configurazioni valide.

Modalità Nome dell’assembly File ID risorsa di destinazione
File separato Diverso dal nome del DLL. Esempio: Vendor.CameraControl.Asm Vendor.CameraControl.Asm.manifest affianco al DLL Non incorporato
Incorporato nel DLL Uguale al nome del DLL. Esempio: Vendor.CameraControl Solo Vendor.CameraControl.dll 1

Quindi, se come negli esempi di 10.2 e 10.3 usi Vendor.CameraControl.Asm, stai usando la modalità file separato. Se vuoi passare alla modalità incorporata, cambia il name in assemblyIdentity a Vendor.CameraControl e allinea anche dependentAssembly.

Un altro vincolo facile da trascurare: il component manifest non può essere incorporato nell’EXE come risorsa. Nell’EXE si incorpora solo l’application manifest.

Per incorporare si usa mt.exe del Windows SDK (Manifest Tool). Esegui dal Prompt dei comandi per gli sviluppatori di Visual Studio.

rem 1. Prima dell'incorporazione, validare la sintassi
mt.exe -manifest MyApp.exe.manifest -validate_manifest
mt.exe -manifest Vendor.CameraControl.manifest -validate_manifest

rem 2. Incorpora l'application manifest nell'EXE
mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;#1

rem 3. Incorpora il component manifest nel DLL (resource ID 1)
mt.exe -manifest Vendor.CameraControl.manifest -outputresource:Vendor.CameraControl.dll;#1

rem 4. Verifica che sia stato incorporato estraendolo
mt.exe -inputresource:Vendor.CameraControl.dll;#1 -out:extracted.manifest

Confrontando extracted.manifest con l’XML originale, puoi eliminare il problema “credevo di averlo incorporato ma non lo era”.

Ci sono 2 avvertenze su mt.exe.

  • I file a cui il manifesto fa riferimento devono trovarsi nella stessa directory del manifesto quando si esegue il comando. Se scrivi <file name="Vendor.CameraControl.dll">, posiziona quel DLL accanto al manifesto prima di eseguire. Se la directory di output della build e quella del manifesto sono separate, qui si blocca
  • Se ometti l’ID risorsa con -outputresource, viene usato CREATEPROCESS_MANIFEST_RESOURCE (= 1). Per evitare ambiguità, meglio specificare esplicitamente ;#1

Se devi solo sostituire un manifesto già incorporato, puoi usare -updateresource:<file>;#1, che equivale a -inputresource e -outputresource sullo stesso file.

10.5. Verifica in ambiente pulito

Reg-Free COM ha poco valore se “funziona sulla macchina di sviluppo”. Spesso in realtà è aiutata da una registrazione locale rimasta nel registro. Verifica secondo questi passaggi.

  1. Compila e raccogli tutti gli artefatti di distribuzione in una sola cartella. EXE, manifesti, COM DLL, dipendenze DLL, VC++ runtime, proxy / stub DLL inclusi
  2. Prepara un ambiente di verifica. L’ideale è un ambiente in cui il COM in questione non è mai stato registrato. Windows Sandbox permette di ripartire da uno stato pulito ogni volta
  3. Verifica preventivamente che il COM non sia registrato. Il comando seguente, se restituisce un errore di chiave non trovata, conferma che non è registrato
  4. Copia la cartella e avvia l’app. Senza installatore né regsvr32
  5. Verifica fino alla creazione effettiva dell’oggetto COM. L’avvio dell’app non basta; per i componenti a creazione ritardata devi arrivare al punto in cui CoCreateInstance viene effettivamente chiamato
  6. In caso di fallimento, raccogli i log come descritto in 11.2

Il comando usato al passo 3 è:

reg query "HKCR\CLSID\{01234567-89AB-CDEF-0123-456789ABCDEF}" /reg:64
reg query "HKCR\CLSID\{01234567-89AB-CDEF-0123-456789ABCDEF}" /reg:32
reg query "HKCR\Vendor.CameraControl.1"

Le viste registro a 32 bit e 64 bit sono separate, quindi controlla sempre il lato corrispondente alla bittness dell’app. Guardare entrambe con /reg:64 e /reg:32 è più sicuro.

Se vuoi provare sulla macchina di sviluppo, deregistra prima con regsvr32 /u Vendor.CameraControl.dll e poi verifica. Attenzione: in ambienti in cui altri prodotti usano lo stesso COM, la deregistrazione può influire su di essi, quindi un ambiente pulito è più sicuro.

11. Insidie

11.1 Funziona sulla macchina di sviluppo ma non sul target

Il primo sospetto è la modalità di essere effettivamente salvati mediante una registrazione nel registro. È più sicuro verificare Reg-Free COM in un ambiente pulito quando possibile.

11.2 Non si avvia con “la configurazione affiancata non è corretta”

Questa famiglia di errori deriva da incoerenze manifeste, DLLs dipendente mancante, runtime VC++ mancante, mancate corrispondenze dell’architettura e così via. Il testo dell’errore superficiale da solo è abbastanza inutile, quindi l’approccio standard è cercarlo con il registro eventi e sxstrace.

Il registro eventi si trova in Visualizzatore eventi > Registri di Windows > Applicazione, cercando errori con origine SideBySide. Qui appare quale assembly ha fallito la risoluzione.

sxstrace va catturato mentre si riproduce il fallimento. Aprire il prompt dei comandi come amministratore è più sicuro.

rem 1. Avvia il tracciamento. Tieni questa finestra aperta
sxstrace trace -logfile:sxstrace.etl

rem 2. In un'altra finestra avvia l'app e riproduci il fallimento

rem 3. Ferma il tracciamento. Nella finestra del passaggio 1 premi Invio, oppure esegui da un'altra finestra
sxstrace stoptrace

rem 4. Converti l'.etl grezzo in un formato leggibile
sxstrace parse -logfile:sxstrace.etl -outfile:sxstrace.txt

Se non vuoi il prompt di arresto, aggiungi -nostop al passo 1. Se l’output è troppo lungo, nel passo 4 puoi aggiungere -filter:MyApp.exe per restringere all’app di interesse.

Nel sxstrace.txt convertito vedrai in ordine quali manifest ha cercato e dove non hanno corrisponduto. Anche se sbagli il modo di denominare in 10.4, qui vedrai il “nome del file che stava cercando” e capirai l’errore.

11.3 Il manifest del componente e il manifest dell’applicazione non sono sincronizzati

  • Il nome è diverso
  • La versione è diversa
  • L’architettura del processore è diversa
  • Il manifest che pensavi di aver copiato è obsoleto

Queste differenze sembrano minime in superficie, ma all’avvio colpiscono piuttosto duramente.

11.4 Dimenticare di collocare il dipendente DLLs

Se ti fermi a Vendor.CameraControl.dll e ti senti soddisfatto, ti perdi il Vendor.Helper.dll caricato a valle, il runtime VC++ e il proxy / stub DLLs. Reg-Free COM riduce i COM problemi di registrazione, ma non cancella anche i problemi di risoluzione delle dipendenze native.

11.5 Rinvio delle operazioni di libreria dei tipi e impostazione dei riferimenti

Anche dopo che l’attivazione del runtime è stata completata, quando necessario

  • rilegatura anticipata dal VBA
  • usa #import da C++
  • generare l’interoperabilità in fase di progettazione sul lato .NET

hai bisogno di un modo per distribuire le informazioni sul tipo. Reg-Free COM non organizza tutto questo automaticamente, quindi è importante pensare separatamente al runtime e al design-time.

Se dovessimo descrivere Reg-Free COM in una frase, si tratterebbe di un meccanismo che sposta le informazioni di registrazione di COM dall’intera macchina al livello per applicazione.

Ciò ti offre i seguenti vantaggi:

  • È più semplice mantenere l’applicazione COM DLLs / OCXs locale
  • È più facile ridurre i conflitti di versione
  • Più facile semplificare la distribuzione e il rollback

D’altra parte,

  • 32-bit / 64-bit
  • dipendente DLLs
  • TLBs / impostazioni di riferimento
  • dipendenze di registrazione non standard
  • verifica in ambiente pulito

rimangono altrettanto importanti.

Quindi la postura di base quando si adotta Reg-Free COM è questa:

  1. Accetta che si tratta di attivazione
  2. Separare i problemi di runtime e di progettazione
  3. Verifica in un ambiente pulito
  4. Riordinare prima il bitness e il DLLs dipendente

Guardandolo in questo ordine gli incidenti sono molto meno probabili.

13. Articoli correlati

14. Riferimenti

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Cos'è Reg-Free COM e come funziona?
Reg-Free COM (Registration-Free COM) è un modo per conservare le informazioni di registrazione COM nei manifest anziché nel registro. Il manifesto dell'applicazione dichiara da quali assembly affiancati dipende l'app e un manifesto del componente contiene le informazioni comClass, clsid, progid, threadingModel e typelib che altrimenti rimarrebbero nel registro. In fase di esecuzione, quando l'app chiama CoCreateInstance o CLSIDFromProgID, viene consultato per primo il contesto di attivazione, quindi COM DLLs e OCXs possono essere mantenuti privati ​​per applicazione senza regsvr32 o registrazione dell'amministratore.
Reg-Free COM risolve il problema 32-bit vs 64-bit?
No. Un processo 32-bit può caricare solo 32-bit in-process COM DLLs e un processo 64-bit può caricare solo 64-bit DLLs; questo è esattamente lo stesso sotto Reg-Free COM di prima. Reg-Free COM inoltre non cancella i problemi di risoluzione delle dipendenze native: il DLLs dipendente, il runtime VC++ e il proxy / stub DLLs devono ancora essere posizionati correttamente. Ciò che rimuove sono i grattacapi trascinati dalla registrazione globale, come conflitti di versione e disinstallazioni che interrompono i componenti condivisi.
Perché la mia app Reg-Free COM funziona sul computer di sviluppo ma non funziona sul PC di destinazione?
Il primo sospetto è che sulla macchina di sviluppo sei stato effettivamente salvato da una registrazione di registro esistente. Se nel manifest mancano le informazioni necessarie, COM torna alla consueta risoluzione basata sulla registrazione, quindi il successo su una macchina di sviluppo non garantisce che la configurazione Reg-Free sia corretta. Verificare in un ambiente pulito quando possibile. Per gli errori di avvio "configurazione affiancata non corretta", individuare la causa con il registro eventi e sxstrace e verificare che il dependentAssembly lato app e l'assemblyIdentity lato componente corrispondano esattamente in termini di nome, versione e processorArchitecture.
Reg-Free COM gestisce anche librerie di tipi e riferimenti in fase di progettazione?
Solo parzialmente. Un manifest può contenere informazioni sulla libreria dei tipi, ma Reg-Free COM riguarda principalmente l'attivazione del runtime, ovvero l'avvio delle cose. Il modo in cui sviluppi con i tipi è un problema separato: le impostazioni di riferimento VBA, C++ #import e la generazione di riferimenti di interoperabilità in fase di progettazione sul lato .NET in genere richiedono una progettazione specifica per la distribuzione delle informazioni sui tipi. Su .NET 5+/.NET 8, EnableRegFreeCom può generare un manifest Reg-Free per l'host COM, ma la generazione e la registrazione di TLB devono comunque essere risolte separatamente.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Torna al blog