Sto cercando di costruire una comprensione generale di ciò che è comune in questa situazione, in modo che io possa decidere se è opportuno proseguire ulteriormente.
- Gli installatori sono benvenuti in un tipico ambiente aziendale con quanto segue?
- Cambia processo di controllo
- Dev / QA / Ambienti di produzione
- Distribuire team designati per varie aree (firewall, database, finestre, ecc.)
- Esiste un "test del nove" che potrebbe essere applicato a un'applicazione per vedere se è un buon candidato per la creazione di un programma di installazione? *
- Gli installer sono abbastanza semplici da consentire ad ogni applicazione di avere uno?
- Gli installatori hanno lo strumento giusto?
- È ragionevole aspettarsi che gli sviluppatori imparino qualcosa come WiX per supportare gli installatori?
- La manutenzione in generale è un problema, ovvero la creazione di un programma di installazione è un'abilità di nicchia?
*
For example, I have a set of winform applications that are in a shared directory on a production server. Specific groups can run the applications from this directory but only system admins can modify the executables. The current deploy process involves having an admin copy/paste the executables and libraries to the shared directory.
Since the applications are not installed on the individual users' machine, does it make sense to create an installer for deploying new versions of these applications to the shared directory?
Modifica -
Ho sentito che le risposte qui davano alcuni consigli solidi, quindi volevo condividere ciò che mi è venuto in mente per il mio progetto attuale, in cui avevo bisogno di creare un gran numero di applicazioni e distribuirle in singole cartelle.
Ho trovato un pacchetto NuGet chiamato _PublishedApplications che simula il comportamento di _PublishedWebsites per i progetti web. L'idea è di installare il pacchetto NuGet nei tuoi progetti e aggiunge una destinazione che copierà le risorse di costruzione in una directory _PublishedApplications nel percorso di output. Questo comportamento si attiva eseguendo MSBuild dalla riga di comando e specificando una proprietà outdir :
msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln
Questo ti darà una struttura di directory simile alla seguente:
- C: \ percorso \ a \ outdir
- _PublishedApplications \
- Project1 \
-
dlls, exes, etc.
-
- Project2 \
-
...
-
- Project1 \
- _PublishedApplications \
Da lì, creare uno zip che può essere estratto nei vari ambienti è abbastanza indolore.