Cos'è Reg-Free COM - Utilizzo di COM senza registrazione
· Aggiornato il: · Go Komura · 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
CoCreateInstanceoCLSIDFromProgID, 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.
- Reg-Free COM riguarda l’“attivazione”
- 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.
flowchart LR
APP["MyApp.exe"] --> AM["Application manifest"]
AM --> DEP["Dependent assembly"]
DEP --> CM["Component manifest"]
CM --> META["file / comClass / typelib"]
META --> DLL["VendorControl.dll/.ocx"]
APP --> ACTX["Activation context"]
ACTX --> COM["CLSIDFromProgID / CoCreateInstance"]
COM --> DLL
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:
comClassclsidprogidthreadingModeltypelib- 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:
- Cartella WinSxS
<appdir>\<assemblyname>.DLL<appdir>\<assemblyname>.manifest<appdir>\<assemblyname>\<assemblyname>.DLL<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 usatoCREATEPROCESS_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.
- Compila e raccogli tutti gli artefatti di distribuzione in una sola cartella. EXE, manifesti, COM DLL, dipendenze DLL, VC++ runtime, proxy / stub DLL inclusi
- 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
- Verifica preventivamente che il COM non sia registrato. Il comando seguente, se restituisce un errore di chiave non trovata, conferma che non è registrato
- Copia la cartella e avvia l’app. Senza installatore né
regsvr32 - 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
CoCreateInstanceviene effettivamente chiamato - 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
#importda 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.
12. Riepilogo
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:
- Accetta che si tratta di attivazione
- Separare i problemi di runtime e di progettazione
- Verifica in un ambiente pulito
- Riordinare prima il bitness e il DLLs dipendente
Guardandolo in questo ordine gli incidenti sono molto meno probabili.
13. Articoli correlati
- Cosa sono COM / ActiveX / OCX - Le differenze e le relazioni spiegate insieme
- Come gestire ActiveX / OCX oggi: una tabella decisionale per mantenere, avvolgere o sostituire
- Come utilizzare un .NET 8 DLL da VBA con i tipi - COM Esposizione + Generazione di un TLB con dscom
14. Riferimenti
- Microsoft Learn - Creazione di oggetti Registration-Free COM
- Microsoft Learn - Manifesti dell’applicazione
- Microsoft Learn - Manifesti di assieme
- Microsoft Learn - Schema del file manifesto
- Microsoft Learn - Registration-Free COM Interoperabilità (.NET Framework)
- Microsoft Learn - Esposizione dei componenti .NET Core a COM
- Microsoft Learn - sxstrace
Articoli correlati
Articoli recenti con gli stessi tag per approfondire argomenti vicini.
Fino a quando funzioneranno le applicazioni VB6? — Lo stato del supporto al runtime e un percorso pratico verso la migrazione a .NET
Fino a quando continueranno a funzionare le applicazioni VB6? Questo articolo chiarisce l'asimmetria tra la politica di supporto del runt...
Outsourcing e sviluppo su commissione di app Windows: cosa chiarire prima di affidare l'incarico
Prima di affidare in outsourcing o su commissione lo sviluppo di un'app Windows, ecco i punti da chiarire: revisione del software esisten...
Il curioso amore di uno sviluppatore, ovvero: come ho imparato a non preoccuparmi e ad amare Windows
Windows è complicato. Ma questa complicazione è anche quella di un sistema operativo che da decenni porta sulle spalle il lavoro reale.
Come costruire l'output di report Excel - COM / Open XML / Template
La progettazione dell'output di report Excel cambia considerevolmente a seconda che si automatizzi Excel stesso, si generino file xlsx di...
COM, ActiveX e OCX — Distinzioni pratiche per chi eredita sistemi Windows
COM è la tecnologia di base, ActiveX è il contesto in cui si usano i componenti COM embedded, OCX è un'estensione di file per le ActiveX ...
Argomenti correlati
Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.
Argomenti tecnici Windows
Portale su sviluppo Windows, analisi dei problemi e valorizzazione delle risorse esistenti.
Migrazione ActiveX
Scelte per mantenere, incapsulare o sostituire componenti COM / ActiveX / OCX.
Servizi collegati all’argomento
L’articolo è direttamente collegato ai servizi seguenti.
Sviluppo di applicazioni Windows
Questo argomento è direttamente collegato all'implementazione dell'app desktop Windows e copre la distribuzione di COM DLL / OCX, la configurazione del manifest, bitness e DLLs dipendente.
Consulenza tecnica e revisione del progetto
È inoltre particolarmente adatto per prendere decisioni, ad esempio se adottare Reg-Free COM o mantenere il funzionamento basato sulla registrazione e come separare le librerie dei tipi dai riferimenti in fase di progettazione.
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.