.net - Replikere Visual Studio COM-registrering med en WiX Installer

Indlæg af Hanne Mølgaard Plasc

Problem



Engang troede en ung, naiv ingeniør, at det ville være en god ide at adskille nogle af funktionaliteten til sin app til en COM-komponent, skrevet i C #. Visual studio havde alle de værktøjer til at gøre det, right? .NET blev praktisk taget lavet til dette, ikke? HA! Han sagde, det vil være nemt. Jeg vil have anstændig adskillelse af komponenter, holde forretningslogik væk fra frontenden, og med COM kan jeg bruge det fra hvor som helst! Han kontrollerede med glæde register for COM interop afkrydsningsfeltet i projektegenskaberne, udsatte de klasser, han ønskede, og gik på vej.


Åh, prøvelserne sådan et valg lavet. Den unge ingeniør nu mere erfarne ville ikke nu ønske dette på nogen. Men byrden var blevet lagt på hans skuldre, og byrden forblev tung. Han så på at lette belastningen.


Samtidig kom WiX, et værktøj til generering af Windows Installer-filer fra XML. Dette fascinerede ham - det kunne ganske enkelt replikere det meste af den kode, der var nødvendig for en ordentlig Windows-installationsfil blot fra en håndfuld konfigurationsfiler. Hans seværdigheder kiggede op.


Med WiX 2.0 kunne han ganske enkelt generere de filer, der var nødvendige for at registrere et C # COM objekt. Dette involverede brug af værktøjet talg. Han gør noget som følger:


tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs


som derefter ville blive rettet op (i første omgang blev det gjort manuelt, men i sidste ende tog jeg skridtene ind i et lille værktøj, der angav det endelige katalogref id, komponent ID, fileID, GUID og codebase).


Derefter installerede den efterfølgende installatør, og der ville være glædelig fest, hvis appen fungerede.


Som det ikke gjorde.


I dag hældte den unge ingeniør forskellene på hans udviklings-pc og den af ​​testinstallations-pc'en. 'Alle registreringsnøgler er de samme!' Han ville udbryde. 'Alt for MyComExposedLibrary er registreret, jeg sværger!'


Bortset fra det var det ikke.


Ved daggry af tredje dag, efter mange bjergdugg, indså han, at der var endnu et objekt, at Visual Studio registrerede at hans installatør ikke var: MyComExposedLibrary.tlb filen.


Visuelt Studio har tilsyneladende registreret denne fil hele tiden og skaber yderligere undernøgler i registryternøglen HKLMSoftwareClassesInterface og registrerer typelibet i HKLMSOFTWAREClassesTypeLib.


Tallow gav ingen hjælp og klagede over, at en .tlb ikke var en fil, der groked. Ikke WiX 3.0 beta - det syntes at have endnu flere problemer at få tingene til at fungere.


Jeg gav også Heat et forsøg. Dette genererede registreringselementer og klassementer. Jeg rydde op på varmens udgang, og gik derefter sammen for at kompilere det, men fik en anden fejl: error LGHT0130 : The primary key <uuid here> is duplicated in table 'Registry'. Problemet er så vidt jeg kan fortælle, at uuid ikke eksisterer i nogen af ​​mine wxs kilde filer. Hvis jeg ændrer komponentrefleksordren i mit funktionselement, giver en anden dll-komponent den fejl. Da jeg ikke har haft succes med at få en WiX 3.0-version af projektet til at kompilere, har jeg ikke kunnet bekræfte, hvorvidt varme giver den rigtige output.


Jeg fjernede alt fra installatøren bortset fra en af ​​forsamlingen, der forårsager denne fejl vises og forsøgte at kompilere igen. Jeg fik samme fejl. Arrugh!


Så mine gode venner, Windows entusiaster og WiX brugere, der falder to spørgsmål:



  • Er en typelib noget, som WiX kan registrere indfødt? Hvis ja, hvordan?

  • Hvis ikke, hvad er den rigtige måde at registrere en typelib på med en Windows installer?



Jeg gætter også som en anden del af dette, hvordan bestemmer Visual Studio, hvordan man registrerer typelib? (Rediger: ser MSDN-bibliotekets artikel om typelib-registrering har navnene på de nøgler, der er nødvendige, men jeg skal stadig finde ud af, hvordan man får uuid'erne. (Dette er fra dette blogindlæg på typelib og COM-registrering af Larry Osterman. )) Læser lidt mere, det kan falde for mig at registrere disse bits manuelt, men jeg håber ikke ... [13] [14]


Jeg vurderede output fra regasm /regfile:MyDll.dll MyDll.dll. Det ser ud til at disse er de samme nøgler, som wix genererer til dll. Regasms anden tilstand, regasm /tlb:<filename> genererer og registrerer typelib for samlingen, men,



  /regfile [[: FileName]] Generer en reg fil med det angivne navn
                       i stedet for at registrere typerne. Denne mulighed
                       kan ikke bruges med/u eller/tlb mulighederne



synes/regfile switch er uforenelig med/tlb switchen. Khaaaaaaaan!


Yderligere opdatering: Det ser ud til at du ikke har brug for for at inkludere .tlb filen. Ifølge dette indlæg på wixs typelib-element kan en MSI oprette/registrere dette som en del af installationsprocessen. Det hele kommer ned til at konfigurere WiX-dokumentet til faktisk at installere det ved at få de rigtige attributter. [15]


Jeg fandt ud af senere at du kan få de rigtige attributter ved hjælp af varme på .tlb direkte! Se dette spørgsmål for mere information.

Bedste reference


Du skal bruge Heat (WIX 3.0) i bin-mappen i den version, du bruger.
Kig på dette blogindlæg, vi bruger det her til at registrere alle vores COM objekter, ved at oprette et wix-fragment ... [17]


noget som


heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs


Efter at have læst din redigering, ville jeg oprette en grundlæggende msi med wix, der kun installerer com-objektet, se om det virker ... så vil du vide hvilken slagmark at angribe ...

Andre referencer 1


Jeg har for nylig kørt ind på dette problem, og den enkleste løsning, jeg kunne finde, følger disse trin på udviklingsmaskinen:



  1. Kør: Regasm MyDLL.dll/tlb:MyDLL.tlb

  2. Kør: Varmefil MyDLL.dll -out MyDll-1.wxs

  3. Kør: Varmefil MyDll.tlb -out MyDll-2.wxs



MyDll-2.wxs indeholder et <Typelib> element, som du vil kopiere og genoprette inden for elementet <File>, der blev genereret i MyDll-1.wxs. Dette vil give dig et komplet <Component> element, som du kan bruge i installationsprojektet.

Andre referencer 2


For at udtrække COM-oplysningerne vil talg bruge regasm.exe-værktøjet, der følger med .NET-rammen. Det er sandsynligt, at den visuelle studio bruger det samme værktøj til at registrere enheder, når du aktiverer 'register for COM interop'. [18]


Forskellen er, at talg vil bruge regasm/regfile switchen til at sende informationen til en .reg fil i stedet for faktisk at registrere samlingen. Desværre er .reg filen genereret af regasm.exe ikke fuldstændig. Den hopper over de typelib-poster, som den skriver til registret under en reel registrering. Dette kan være en fejl i regasm.


For at få dit installationsprogram til at fungere har du tre muligheder:



  1. Tilføj de manglende registernøgler til
    tallow output manuelt. Talg
    output er beregnet til at blive redigeret
    manuelt og gemt sammen med din
    andre wxs filer alligevel. Du synes at
    Forsøg at generere helt automatisk
    en fungerende wxs-fil, men jeg tror det var
    aldrig et designmål for talg.

  2. Brug en tilpasset handling for at påberåbe regasm fra din installatør. Dette er lidt ondt, fordi du kan miste nogle af de stærke transaktionsgarantier, der leveres af Windows Installer Engine. Jeg tænker på rollbacks udløst af en fejl halvvejs under installationen her. [19]

  3. Undgå registrering helt af
    benytter sig af registreringsfri COM.
    Dette vil kræve oprettelsen af
    manifest filer for både
    ansøgning og COM biblioteket. [20]


Andre referencer 3


Jeg ved, at dette er et ældre spørgsmål, men andre kan finde dette nyttigt ...


Efter at have kæmpet for det selv fandt jeg ud af, at du kan fange typebibliotekets information ved at bruge tlbexp.exe og derefter opvarme både dll og tlb filen. Medtag output fra begge dem i dit wix-projekt, og du bør være god at gå. [21]


tlbexp.exe dllFile.dll /out:dllFile.tlb
heat.exe dllFile.dll ...
heat.exe dllFile.tlb ...