Come possono C# utilizzare una DLL legacy semplicemente senza registrazione (regsvr32)

Question

Situazione
Ho eseguito un sistema di compilazione che esegue molti costruisce per molti progetti. Per evitare che una build abbia un impatto su un'altra, l'utente di build viene bloccato solo sulla sua area di lavoro. Le build vengono eseguite come utenti non privilegiati con capacità di scrittura sull'area di lavoro.

Sfida
Durante la nostra nuova build abbiamo bisogno di usare un lascito 3rdparty DLL che espone la sua interfaccia attraverso COM. Il team di sviluppo desidera registrare la build (regsrv32.exe) ma il nostro regime di sicurezza di build blocca questa attività. Se rilassiamo il regime, la DLL di terze parti inciderà su altre build e se ho due build che hanno bisogno di due versioni diverse potrei avere la build compilata sbagliata rispetto alla versione sbagliata (una possibilità molto reale).

Domanda
Ci sono altre opzioni oltre registrazione per gestire DLL legacy che espongono la loro interfaccia tramite COM?

Grazie per l'aiuto

Peter

Answer 1

C'è una guida on-free registrazione COM qui:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

E straziante dettaglio in questa sede: http://msdn.microsoft.com/en-us/library/aa376414 (la radice di tale documento è in realtà qui: http://msdn.microsoft.com/en-us/library/dd408052)

Inoltre, per in generale, dovresti essere in grado di usare Tlbimp o tlbexp per creare un file TLB che puoi usare per costruire, assumendo che il punto di registrazione sia solo per essere in grado di compilare correttamente, e non per eseguire test specifici S.

Answer 2

• Se si ha accesso alla 3a parte DLL di poterli GAC, e farvi riferimento nel progetto
• è possibile aggiungere un utilizzando al vostro l'intestazione del file .cs e aggiungi il riferimento al progetto facendo clic con il tasto destro sul riferimento -> aggiungi riferimento ...
• puoi anche eseguire il passaggio precedente e impostare la copia local = true nelle proprietà per quello .dll .. Spero che questo ti dia qualche idea .. tenere a mente che sono assembly .NET Managed codice in modo ci sono diversi modi di consumare quelli 3rd party che utilizzano altri metodi di DLL all'interno di C# come LoadFromAssembly ect ..

Answer 3

strumenti di installazione come ad esempio InstallShield può estrarre le interfacce COM dal DLL e aggiungerli al registro. Può anche utilizzare il processo di autoregistrazione della DLL (che credo sia ciò che fa regsvr), ma questo non è un Microsoft installer best practice.

Answer 4

Grazie per tutto l'aiuto. Siamo passati da early-binding a late-binding perché non abbiamo mai realmente avuto bisogno della DLL in fase di compilazione. Ciò ha spinto i requisiti di registrazione dal server di build al server di test di integrazione (dove eseguiamo il programma di installazione che gestisce la registrazione). Cerchiamo di mantenere intatto il sistema di costruzione e di avere sistemi di integrazione facili da ripristinare.

Grazie ancora Peter

Answer 5

Per la mia risposta originale a una domanda simile vedi: TFS Build server and COM references - does this work?

Un buon modo per compilare il codice .NET che fa riferimento a componenti COM senza che i componenti COM essere registrati sul server di build è per utilizzare l'elemento di riferimento COMFileReference nei file di progetto/generazione anziché COMReference. Un elemento COMFileReference assomiglia a questo:

<ItemGroup> 
    <COMFileReference Include="MyComLibrary.dll"> 
    <EmbedInteropTypes>True</EmbedInteropTypes> 
    </COMFileReference> 
</ItemGroup> 

Poiché Visual Studio fornisce alcun supporto di design per COMFileReference, è necessario modificare il progetto/costruzione di file a mano.

Durante una compilazione, MSBuild estrae le informazioni sulla libreria dei tipi dalla DLL COM e crea un assembly di interoperabilità che può essere autonomo o incorporato nell'assembly .NET chiamante.

Ogni elemento COMFileReference può anche avere un attributo WrapperTool ma il valore predefinito sembra funzionare correttamente. L'attributo EmbedInteropTypes non è documentato come applicabile a COMFileReference, ma sembra funzionare come previsto.

Vedere http://msdn.microsoft.com/en-us/library/bb629388.aspx per ulteriori dettagli. Questo articolo MSBuild è disponibile da. NET 3.5.

È un peccato che nessuno sembra sapere nulla di questa tecnica, che per me sembra più semplice delle alternative. In realtà non è sorprendente dato che ho potuto trovare solo quello sopra di riferimento in linea. Io stesso ho scoperto questa tecnica scavando nel file Microsoft.Common.targets di MSBuild.