Clickonce-Bereitstellung in mehreren Umgebungen

Question

Ich habe eine WPF-Anwendung, die ich über ClickOnce für unsere Benutzer bereitstellen möchte. Wir haben vier Umgebungen, System Testing, User Testing, Parallele Produktion und Produktion. Jede benötigt eine andere Konfigurationsdatei mit Servernamen und anderen für die Umgebung spezifischen Dingen, so dass sie nicht alle die gleiche Codebasis verwenden können. Der größte Teil des Codes ist derselbe, aber das endgültige Paket wird aufgrund der verschiedenen .config-Dateien leicht abweichen.

Was ich finde, ist, dass wir eine Version im Benutzertest installieren, sagen Version 05, dann testen sie, und wenn es Zeit wird, ihnen die nächste Version zu geben, sollten wir nur ein aktualisiertes Paket bereitstellen können Auf dem Benutzertest-Webserver können sie ihre Version aktualisieren, indem sie auf die Bereitstellungs-URL klicken. Aber wenn sie dies tun, sagt es "Anwendung mit der gleichen Identität existiert bereits" und wir müssen über Systemsteuerung deinstallieren, um Version 06 zu installieren. Das scheint falsch zu sein und nicht der Klickpunkt.

Wie empfehlen Sie, diese Anwendung in den vier verschiedenen Umgebungen zu erstellen und bereitzustellen, sodass in jeder Umgebung nur eine neue Version auf den Server gestellt werden kann und die Benutzer, die diese Umgebung testen oder verwenden das Update herunter und muss nichts deinstallieren?

Answer 1

Erstens können Sie eine Anwendung mit demselben Implementierungsnamen nicht aus zwei verschiedenen URLs installieren, ohne zuerst eine zu deinstallieren. ClickOnce verwendet dies zur Sicherheit, um sicherzustellen, dass niemand versucht, Ihre Bereitstellung zu übernehmen.

Zweitens, um verschiedene Builds zu erstellen, können Sie vier Ordner unter dem Projekt einrichten, eines mit jedem Namen. Richten Sie dann vier Buildkonfigurationen ein (nennen Sie sie dasselbe). Richten Sie anschließend einen Post-Build-Befehl ein, der die Dateien in den Ordner \ bin kopiert. Wenn Sie die Ordnernamen so einrichten, dass die Build-Konfiguration darin enthalten ist, werden die entsprechenden Konfigurationen kopiert.

COPY/Y "$(TargetDir)myfile_$(ConfigurationName)\*.*" "$(TargetDir)" 

Drittens müssen Sie die Dateien in dem Projekt sind selbst so werden sie markiert werden, in der Bereitstellung einbezogen werden, auch wenn man sie mit einem Kopierbefehl ersetzen, nachdem die Build erfolgt. UND die vier Verzeichnisse müssen ebenfalls enthalten sein, obwohl sie letztendlich nicht verwendet werden.

Answer 2

Ich habe versucht, das gleiche in den letzten zwei Tagen ohne Glück zu tun. Meine aktuelle Methode macht folgendes:

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj 
del c:\Product\app.config 
ren C:\Product\systest.config C:\Product\app.config 
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="System Test Product";InstallUrl="http://systest.product.temp-uri.org/install/" 
ren C:\Product\bin\Release\app.publish systest.app.publish 

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj 
del c:\Product\app.config 
ren C:\Product\usertest.config C:\Product\app.config 
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="User Test Product";InstallUrl="http://usertest.product.temp-uri.org/install/" 
ren C:\Product\bin\Release\app.publish usertest.app.publish 

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj 
del c:\Product\app.config 
ren C:\Product\parallelprod.config C:\Product\app.config 
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="Parallel Prod Product";InstallUrl="http://parallelprod.product.temp-uri.org/install/" 
ren C:\Product\bin\Release\app.publish parallelprod.app.publish 

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj 
del c:\Product\app.config 
ren C:\Product\prod.config C:\Product\app.config 
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="Prod Product";InstallUrl="http://prod.product.temp-uri.org/install/" 
ren C:\Product\bin\Release\app.publish prod.app.publish 

Das erste Hindernis, das ich getroffen wurde zu realisieren, dass Sie die Anwendung neu kompilieren müssen, wenn Sie die Konfigurationsdatei, die Version oder den Produktnamen ändern möchten. Wenn Sie eine Veröffentlichung nach einem regulären Build ausführen, wird diese Aufgabe nicht ausgeführt. An dieser Stelle dachte ich, dass dies funktionieren würde, da jeder eine andere Installations-URL und einen anderen Produktnamen im Anwendungsmanifest hat, jedoch immer noch Konflikte mit der gleichen Nachricht haben, die Sie sehen. Wenn ich es funktioniere, werde ich zurückkommen und dies mit dem Update aktualisieren.

Answer 3

Nachdem nach einer Lösung selbst für einige Zeit suchen, fiel mir auf, dass die letzte, die ich mit, da dies tatsächlich so einfach kam ist:

• Slow Cheetah für die Konfigurationsdateien Umwandlung basierend auf dem ausgewählten Build Konfiguration (zB Debug/Release)
• Eine Property-Gruppe pro Build-Konfiguration mit den spezifischen Click-Once-Projekteigenschaften (z. B. ProductName und AssemblyName (für parallele Installation der Test- und Prod-Version), InstallUrl) in der Projektdatei.
• Angeben zusätzliche Eigenschaften (wie Programmversion, MinimumRequiredVersion) über msbuild, wenn das/Ziel Ausführung:

Es veröffentlichen muß keine Konfigurationsdateien manuell so langsam Geparde dies handhaben kopieren. Das Click-Once-Paket wird im Ausgabeordner der jeweiligen Build-Konfiguration erstellt (z. B. bin/Debug oder was auch immer Sie haben).

Der größte Vorteil ist, dass der Build für die Verwendung von Visual Studio oder automatische Builds mit msbuild identisch ist (mit Ausnahme der wenigen zusätzlichen Eigenschaften, die vollständig optional sind). Alles was Sie tun müssen, um Ihrem Build zusätzliche Umgebungen hinzuzufügen, ist, neue Build-Konfigurationen und die entsprechenden langsamen Cheetah-Transformationen und eine Eigenschaftsgruppe in der Projektdatei zu erstellen.

Das ganze Setup funktioniert zumindest mit .NET 3.5 (kann nicht über frühere Versionen sprechen) und später.

Vielleicht hilft das jeder. Fühlen Sie sich frei, nach Details zu fragen.

PS: Die Eigenschaftsgruppen wie folgt aussehen (sie nach der ersten Eigenschaftsgruppe setzen, die die Standardeinstellungen definiert Clickonce):

<PropertyGroup Condition=" '$(Configuration)' == 'Demo' "> 
    <AssemblyName>Com.MyApplication.Main.Demo</AssemblyName> 
    <InstallUrl>http://demoserver/myapp/</InstallUrl> 
    <ProductName>My Application %28Demo%29</ProductName> 
    </PropertyGroup> 
    <PropertyGroup Condition=" '$(Configuration)' == 'Test' "> 
    <AssemblyName>Com.MyApplication.Main.Test</AssemblyName> 
    <InstallUrl>http://testserver/myapp/</InstallUrl> 
    <ProductName>My Application %28Test%29</ProductName> 
    </PropertyGroup> 
    <PropertyGroup Condition=" '$(Configuration)' == 'Prod' "> 
    <AssemblyName>Com.MyApplication.Main</AssemblyName> 
    <InstallUrl>http://prodserver/myapp/</InstallUrl> 
    <ProductName>My Application</ProductName> 
    </PropertyGroup>