konfiguration - Generering af MSI installationsprogrammer til Windows-tjenester med konfigurerbare servicenavne med MSBuild

Indlæg af Hanne Mølgaard Plasc

Problem



Vær hilset,
Jeg forsøger at finde ud af, hvordan man trækker det følgende scenario med MSBuild og Visual Studio 2010.



  1. Jeg har et sæt af tre tjenester, som jeg gerne vil installere. Standardinstallationsmappen skal variere med build (qa, uat og production).

  2. For at tilføje en anden sjov rynke til hele denne ting, kan uat miljøet i nogle tilfælde blive presset i brug, når vi er i toppbelastning, så hver bygning af tjenesten skal have et andet navn. Det sker ikke ofte, men det er på listen. Hvordan kan jeg konfigurere serviceinstallatørerne til at ændre servicenavnet dynamisk?

  3. Jeg vil gerne være i stand til at oprette MSI-installatører for tjenesterne (uanset hvad den nuværende bygning er). Jeg har et eksisterende og omfattende MSBuild script til de forskellige hjemmesider, jeg arbejder med allerede, men jeg er lidt usikker på, hvordan man fortsætter med at gøre tjenesteydelserne arbejde.

  4. Konfigurationsfilerne for hver tjenesteydelse vil naturligvis være forskellige.

  5. Jeg har tilføjet installatørklasser for hver af de tjenester.



Jeg tror, ​​at jeg 'er lidt forvirret med, hvordan man starter dette, så enhver hjælp, jeg kan få, ville være fantastisk. Jeg havde overvejet blot at kode de forskellige servicenavn hardcoding og bruge betingede samlingsopgørelser til at indstille dem, men det synes jeg ikke er en særlig klar måde at gå om det hele. nogen tanker?

Bedste reference


Det kan være enklere at bare pakke op servicebiterne under opbygningen og implementeringen med MSBuild ved hjælp af eller MSBuild Extension-opgaver. Du vil sætte dit miljøspecifikke konfigurationsdata i en msbuild .properties-fil (mylocal.service.properites, qp.service.properties, uat.service.properties osv.). Sådan implementerer jeg tjenester.


Bemærk: Ejendomsfilen vil indeholde ting som din db-forbindelsestreng, TargetDir, ServiceName osv.


Servicenavne er angivet på installeringstidspunktet se 'sc', 'installutil' eller WindowsService msbuild extensions-pakningsopdragssnit nedenfor. Dette betyder at du kan kopiere de samme servicebits everal-mapper og installere hver med et unikt navn (fx QAService, UATService, PRODService). [2]


Bemærk: Jeg vil gerne forstærke, at servicenavnet er en deploy-time overvejelse, ikke en build-time overvejelse.


<WindowsService TaskAction="Install"
                ServiceName="$(ServiceName)"
                MachineName="$(TargetServer)"
                ServicePath="$(FullServicePath)" 
                User="$(User)" />


Tilgangen er ens for MSI-installatører. Jeg antager dine installatører omgående for alle nødvendige miljøspecifikke konfigurationsdata ... Alle [[anstændige]] installatører har mulighed for at give svar fra en fil versus at bruge installationsprogrammet interaktivt. Så som ovenfor opretter du en svarfil pr. Miljø og føder det til installationsprogrammet på kommandolinjen.


Du ønsker ikke at gøre dette på byggetid ... og dermed have en separat installatør pr platform. Var tvunget til at gøre dette med en gammel version af den vise installatør. Gør mig trist. Du vil have et enkelt MSI-installationsprogram, der kan køres i hvert miljø (givet miljøspecifik svarfil).


Oplysninger om MSI kommandolinjen og svarfilformatet varierer efter produkt. Hvilken installationspakke bruger du?


Skål,
/JHD