Ich verwende ein MSBUILD-Skript, um eine Veröffentlichung zu erstellen, sieht etwa so aus:
%Vor%Bisher funktioniert das richtig.
Ist es möglich, MSBUILD zu verwenden, um mehrere Veröffentlichungen an verschiedenen Orten zu erstellen, die zusammen installiert werden können? Ich weiß, dass ClickOnce standardmäßig keine Anwendung von einem anderen Ort aus installieren kann, wenn die Anwendung dieselbe ist (ich glaube, sie bestimmt dies durch Verwendung des Assemblynamens).
Ich habe diesen Thread hier besprochen:
Und deshalb habe ich mein Skript geändert, um dies zu tun:
%Vor%Allerdings bekomme ich eine Menge Fehler (wie 1300+), aber ich bin mir nicht sicher, was passiert. Aber wenn ich den Assemblynamen in Visual Studios ändere und es erstelle, ist alles in Ordnung.
Irgendwelche Gedanken?
Was passiert, ist, dass die Eigenschaft AssemblyName in allen Projekten, die msbuild in der Kette der Abhängigkeit Ihres Hauptprojekts erstellt, überschrieben wird. Das verursacht viele Kompilierungsfehler. Wenn Sie den AssemblyName über Visual Studio ändern, ändern Sie nur das Hauptprojekt, wodurch es korrekt erstellt werden kann. In einem meiner Projekte habe ich eine Eigenschaft in der Hauptdatei .vbproj namens OverridenAssemblyName hinzugefügt und AssemblyName = OverridenAssemblyName festgelegt, wenn OverridenAssemblyName nicht null ist. Auf diese Weise können Sie den AssemblyName nur für das Projekt festlegen, um die anderen intakt zu halten.
BEARBEITEN:
Stellen wir uns ein Szenario vor, in dem Sie zwei Projekte haben. Projekt A, das zu veröffentlichende Projekt, und Projekt B, auf das von Projekt A verwiesen wird. Innerhalb der .vbproj-Dateien haben Sie Tags wie dieses <AssemblyName>YourProjectName</AssemblyName> . In der Datei Projekt A hätten Sie <AssemblyName>Project A</AssemblyName> und <AssemblyName>Project B</AssemblyName> in Projekt B.
Dieses Tag definiert den Namen der Assembly, die während des Builds für das Projekt erstellt wird.
Wenn Sie /p:AssemblyName="<Application Name>_<Region Name>" in Ihrer msbuild-Befehlszeile übergeben, überschreiben Sie das Tag AssemblyName für jedes Projekt im Build-Prozess. Und da diese Eigenschaft den Assemblynamen des Projekts definiert, wird für alle Projekte die Assemblierung mit demselben Namen generiert. Das ist wahrscheinlich die Ursache Ihres Problems.
Eine mögliche Lösung besteht darin, Folgendes zu tun:
Fügen Sie dies Ihrem Hauptprojekt hinzu (Projekt wird veröffentlicht)
<PropertyGroup Condition="$(PublishAssemblyName) != ''">
<AssemblyName>$(PublishAssemblyName)</AssemblyName>
</PropertyGroup>
Ändern Sie Ihre Befehlszeile wie folgt:
msbuild "<Project>.vbproj"
/t:Publish
/p:Configuration=Release
/p:ProductName="<Application Name> - <Region Name>"
/p:PublishDir="<Region Specific Unc>"
/p:PublishAssemblyName="<Application Name>_<Region Name>"
Ich hoffe, dass dir das hilft.
Ich konnte nur erfolgreich sein, indem ich die msbuild / publish-Funktion einmal ausführte und dann ein separates "deploy" -Programm schrieb, um die Manifeste zu ändern und neu zu signieren, wenn sie in jede Umgebung verschoben wurden. Es wird in der Qualitätssicherung bereitgestellt und erhält einen neuen Namen und eine neue Konfigurationsdatei. Dann später "deploy" wieder in die Produktion und gibt ihm zu diesem Zeitpunkt einen neuen Namen und eine neue Konfigurationsdatei.
Der Prozess erfordert das Umbenennen, um die Erweiterung .deploy zu entfernen, die Konfigurationsdatei zu ersetzen, das App-Manifest zu ändern, das Bereitstellungsmanifest zu ändern (auch in meinem Fall die .xlsx-Datei zu aktualisieren, weil ich ein vsto-Excel-Add-In ausführte) ), geben Sie das App-Manifest zurück, stellen Sie die Erweiterung .deploy wieder her, beenden Sie das Bereitstellungsmanifest und kopieren Sie schließlich die Ergebnisse in den Deploy-Speicherort.
Dies führt zu einer Bereitstellung für QA, die bei "einmaliges Klicken" eine "Anwendungs-QS" in Add / Remove-Programmen erstellt und eine Produktionsbereitstellung, die bei "einmaliges Klicken" eine "Anwendungs- PROD ". Die beiden können gleichzeitig ausgeführt werden, da der Assemblyname und die GUID "solutionId" in jeder Umgebung aktualisiert wurden.
Im Folgenden finden Sie einen Code zum Ändern der App- und Bereitstellungsmanifeste, um ihnen in jeder Umgebung eindeutige Namen zu geben. Wenn Sie sich für diesen Ansatz entscheiden und Code zum Rücktritt wünschen, kann ich Ihnen helfen.
%Vor%Tags und Links visual-studio-2010 msbuild clickonce msbuild-4.0