Oprettelse af et Windows-installationsprogram ved hjælp af C # Winforms i stedet for Installer-værktøj

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har brugt InstallAware og InstallShield før, og de er ret vanskelige at arbejde med, og når noget går galt, er det meget svært at finde og løse problemet.


Mit spørgsmål er, hvorfor kan vi ikke bruge et Windows-program skrevet med C # til at gøre dette.
Jeg forstår at. Net-rammerne ikke kan installeres på destinationscomputeren, så jeg undrer mig over, hvorfor ingen nogensinde har brugt denne arkitektur:
Jeg vil oprette et simpelt installationsprogram ved hjælp af IntallSiheld (eller et andet lignende værktøj) til bare at installere. Net Framework og derefter uddrag og kører mit eget Windows-program, som jeg har skrevet ved hjælp af C # i forhøjet tilstand. Min applikation vil køre en guiden med Tilbage og Næste-knappen, og jeg vil tage sig af alt i det (kopiering af filer, oprettelse og start af Windows Services, tilføjelse af registreringsværdier, oprettelse af firewalludvidelser osv.)
Har nogen nogensinde gjort det her, og er der noget der forhindrer folk i at gøre dette?

Bedste reference


I det væsentlige : Forsøg ikke at genopfinde hjulet. Brug et eksisterende implementeringsværktøj og bliv med dit daglige job :-). Der er mange sådanne værktøjer til rådighed. Se links nedenfor.


Og under, langvarig, gentagne muskler:





Velkommen : Beklager, at du ikke vælger nybegyndere, hvis du spørger mig - men hvem spørger mig ;-). Velkommen til stackoverflow - for hvad det er værd. Jeg tror, ​​hvad du spørger, er et gyldigt spørgsmål til mange udviklere . De får virkelig ikke, hvorfor implementering er sådan et besvær at håndtere. Hvor svært kan det være?


Redux : IMHO og med al respekt, hvis jeg kan sige det, gør det selv at installere software genopfinde hjulet for absolut ingen gevinst, hvad jeg er bange for. Jeg tror, ​​at du vil 'genopdage' de kompleksiteter, der findes af andre, der har gået den vej, der er involveret i implementering, mens du opretter din egen installationsprogramvare og finder, at software kan være hurtig at lave, men meget svært at perfekt . I den proces vil du bruge mange anstrengelser på at forsøge at pakke op - og ' den sidste meter er meget lang ' som du forbander dig selv at beskæftige sig med småblade, der tager din tid på bekostning af hvad ville ellers betale regningerne . Sortering af fejlene i ethvert værktøjssæt til den tekniske funktion kan tage år eller endog årtier. Og nej, jeg gør det ikke op. Det er, hvad alle distribution software leverandører handler med.


Mange eksisterende værktøjer : Der er mange eksisterende værktøjer, der implementerer en sådan implementeringsfunktionalitet allerede - som ikke er baseret på Windows Installer ( Inno Setup , NSIS , DeployMaster og masser af andre mindre kendte indsatser):



  • Der findes en liste over ikke-MSI installationsprogrammer her.

  • Der er en anden liste over MSI-kompatibel software her.



Mine 2 cent - hvis du ikke kan lide MSI, skal du vælge et af de gratis, ikke-MSI implementeringsværktøjer. Sådan opretter du Windows Installer . [7] [8]


Corporate Deployment : Det virkelig vigtige punkt (for mig) er, at virksomhedernes implementering er afhængig af standardiserede emballageformater - som MSI - for at tillade pålidelig, fjernstyring af din softwareudvikling. Hvis du laver dit eget installationsprogram, vil det ikke imponere systemadministratorer eller firmaudviklingsspecialister (i hvert fald indtil du sorterer år af fejl og mangler). De ønsker standardiseret format, som de ved, hvordan man håndterer (det betyder ikke, at de er imponerede over eksisterende implementeringsteknologi). Hvis du gennemfører implementering med standardiserede implementeringsformater, kan du få virksomhedens godkendelse til din software . Hvis du laver et mærkeligt implementeringsformat, der gør usædvanlige ting på installation, der ikke let kan fanges og implementeres i stor skala, er din software først og fremmest ud af et stort firma. Ingen barmhjertighed - for ægte. Disse er travle miljøer, og du får lidt forståelse for din usædvanlige løsning.


'File-Pushers' : De af os, der skubber filer rundt for at leve ved, at implementeringsområdet er gået i stykker med dumme problemer, der hurtigt dræb din produktivitet i andre bestræbelser - dem der får dig til at skille sig ud i dit felt - dit daglige job. Implementering er en høj profil, lav statusindsats - og vi klager ikke. Det er bare hvad det er: en nødvendighed, der er sværere at håndtere, end du måske tror. Bare brug din tid mere klogt er, hvad jeg ville konkludere.


Kompleksitet : Skim måske afsnittet ' Kompleksiteten af ​​implementering ' her: Windows Installer og oprettelsen af ​​WiX. Det er forbløffende at håndtere alle de fjollede fejl, der opstår under implementering. Det er ikke bare en filkopi, selv om det kan være let at tro, det er. Og hvis det sker bare at være en fil kopi, så er der eksisterende værktøjer, der gør jobbet. Gratis dem også. Se links ovenfor. Og hvis du mener, at implementering kun er fil-kopi generelt, skal du så skimme denne liste over opgaver, som en implementeringsopgave skal kunne understøtte: Hvad er fordel og det egentlige formål med programinstallation?


Vil din hjemmebrugte pakke håndtere følgende? (bare nogle tilfældige tanker)



  • En malware-inficeret terminalserver-pc i Korea med Unicode-tegn i stien?

  • Symboliske links og NTFS-kryds-punkter-stier?

  • En bærbar computer, der slukker sig i midten af ​​din filkopi, fordi den er ude af batteriet?

  • Uden diskpladsforhold? Hvad med diskfejl? Og kopiere timeouts?

  • Hvad med omstartskrav? Til in-use filer eller anden grund. Hvordan skal de håndteres? Hvad nu hvis systemet er i en genstart af afventende tilstand, og du skal registrere den, før du starter din installation?

  • Hvordan vil du pålideligt installere, konfigurere og starte og stoppe tjenester?

  • Hvordan hjælper du med at afinstallere og oprydning til din ansøgning?

  • Sikkerhedssoftware, der flagger din ukendte, uigenkendte, ikke-standardpakke en sikkerhedstrussel og karantæner den? Hvordan vil du begynde at håndtere dette? Hvem kontakter du for at komme ind i de gode gracer af en 'anerkendt binær' til elevation?

  • Ikke-standard NTFS-tilladelse (ACL) og NT-privilegier? Hvordan opdager du det og nedbryder yndefuldt, når du får tilladelse nægtet? (uanset årsag).

  • Implementering af nødvendige runtime for din ansøgning til arbejde? (har været gjort af mange andre før). Hentning af de seneste runtime, hvis dine indlejrede er forældede? Etc ...

  • Giv en standardiseret måde at udpakke filer fra din installation binære?

  • Giv hjælp og support til dine installationsbinarier til brugere, der forsøger at bruge dem?

  • Etc ... Dette var bare en tilfældig liste over hvad der kom til at tænke hurtigt. Der er naturligvis mange problemer.



Det var lidt over toppen for det du bad om, men lad dig ikke narre til at tænke implementering er noget, du kan finde ud af en løsning i løbet af få timer. Og helt sikkert tag jobbet lovende at gøre det - hvis det er hvad du bliver spurgt om. Bare mine to cent.


Ovennævnte problemer og mange andre er, hvad folk opdager, de skal håndtere, når de opretter installationsprogrammer - for alle, men de mest trivielle implementeringer. Spild ikke din tid - brug nogle etablerede værktøjer .


Transaktion : Hvis du arbejder i et firma og kun har brug for dine filer til dine testere, kan du distribuere ved hjælp af batch-filer for den sags skyld - hvis du vil. Men du skal støtte det, og jeg garanterer, at det vil tage meget tid. Hvad gør du, når batchfilen mislykkedes halvvejs på grund af en netværksfejl, og dine testere tester filer, der er inkonsekvente? Fremtidige implementeringsteknologier kan være bedre til sådanne lette opgaver. Måske er det største i et implementeringsværktøj at rapportere om implementeringen er gennemført med succes eller ej, og at logge fejlene og at rulle maskinen tilbage til en stabil tilstand, hvis noget mislykkes . Windows Installer gør meget af dette for dig.


Fordeling : Mange mennesker føler, at de kan bare replikere min build-mappe til brugerens computere . Der er mange involverede kompleksiteter: Der er netværk involveret, og netværk kan aldrig antages at være pålidelige, du har brug for mange fejlhåndtering her. Så er der spørgsmålet om transaktioner: hvornår ved du, hvornår computeren er i en stabil state og bør stoppe med at replikere. Hvor ofte replikerer du kun på forespørgsel? Hvordan håndterer du de få computere, der ikke replikerede. Hvordan fortæller du brugerne? Dette er distributionsproblemer . Virksomheder har store værktøjer som SCCM til at håndtere alle disse fejlbetingelser. Hvis du prøver at genudføre alle disse kontroller, vil logging og funktioner tage lang tid. Til sidst vil du have genoprett et eksisterende distributionssystem . Fuld cirkel. Og hvordan gør du opgørelse af dine computere, når der ikke er noget produktregistreret ed som installeret, da kun en batchfil eller script kørte? Og hvis du begynder at kopiere mange pakker, hvor mange gange scanner du hver fil for at afgøre, om de er opdaterede? Hvor meget netværkstrafik vil du oprette? Hvor slutter det? Svaret: Jeg tror, ​​at transaktioner skal implementeres med fuld logging og fejlsporing og rollback. Så er du fuld cirkel til et distributionssystem som jeg nævnte ovenfor og et understøttet pakkeformat også .


Denne bare replikere min build-mappe til mine brugere 'Idéer på en eller anden måde minder mig om denne liste: https://en.wikipedia.org/wiki/Fallacies\_of\_distributed\_computing . Ikke en 100\% match, men problemerne minder om. Når netværk er involveret, begynder tingene at blive meget uforudsigelige, og du har brug for logning, fejlkontrol, transaktioner, tilbagekaldelse, netværkskommunikation mv. Vi har genopdaget storskala implementering - dyret det er. [12]


Netværk : Lad os sige, at du vil replikere din byggemappe til 10000 stationære maskiner i din virksomhed. Hvordan afbryder du replikationen? Starter du alle replikeringer på en gang og nedlægger handelsgulvet i banken, da filreplikation overtager hele netværket som et DDOS-angreb ? Beklager - det går ud af hånden - vær venlig at undskylde flippancy - men det er virkelig foruroligende, at denne replikeringsmetode ses som levedygtig til stor udbredelse. Indbyggede Windows-funktioner kan hjælpe, men skal stadig testes korrekt. har brug for scheduling, queuing, caching, regional distribution shares, logging, reporting / inventory og Gud ved hvad ellers et emballage/implementeringssystem giver dig allerede. Og re-implementering det vil være et smertestog af helt nye bugs at håndtere.


Måske vi en dag vil se automatisk output mappe replikation baseret på automatisk pakke generation, der virkelig fungerer via et intelligent og transacted distribution system. Mange virksomhedshold forsøger, og ved at bruge eksisterende værktøjer kommer de tættere på de anvendte standardformater. Jeg tror, ​​at de nuværende cloud-implementeringssystemer bevæger sig i denne retning med online-lagre og let, interaktiv installation, men vi skal stadig pakke vores software intelligent. Det vil være interessant at se, hvad fremtiden rummer, og hvilke nye problemer der resulterer i emballering og distribution i skyens alder.


Da vi trækker filer direkte fra onlinebutikker på internettet, vil vi se en masse nye problemer? Malware, spoofing og injektion? (allerede problematisk, men kunne blive værre). Fjernfiler slettet uden varsel (for at slippe af med sårbare udgivelser, der ikke længere skal bruges - efterladt brugerne strandede)? Certifikat og signaturproblemer? Firewalls & proxy problemer? Auto-magiske opdateringer med uheldige fejl rammer alle med det samme og uventet? Og netværkets fejl og andre faktorer som knyttet til ovenstående. Slår mig. Vi vil se. [13]


OK, det blev en rant som normalt - og det sidste afsnit går over bord med spekulation (og nogle af problemerne gælder allerede for den nuværende implementering). Det er jeg ked af. Men prøv at få ledelsesgodkendelse til at bruge en eksisterende emballage & implementeringsløsning er mit eneste råd.


Stefan Kruger s Installsite.com twitter feed : https://twitter.com/installsite[14]


Nogle nylige højdepunkter:



  • https://twitter.com/SurjKhera/status/980531378692468737

  • https://twitter.com/TimothyMangan/status/947853348430143488






Valg af implementeringsværktøj: [15] [16]



  • Sådan opretter du Windows-installationsprogrammet

  • Hvilken installationsprodukt skal du bruge? InstallShield, WiX, Wise, Advanced Installer, osv.

  • Windows Installer og oprettelsen af ​​WiX

  • WiX hurtigstartspunkter

  • Mere om dark.exe (lidt ned på siden)