Freigeben über

Bereitstellen von ClickOnce-Anwendungen für Tests und Produktionsserver ohne erneutes Signieren

  • Artikel

In diesem Artikel wird ein Feature von ClickOnce beschrieben, das in .NET Framework 3.5 eingeführt wurde und das die Bereitstellung von ClickOnce-Anwendungen von mehreren Netzwerkstandorten aus ermöglicht, ohne die ClickOnce-Manifeste erneut zu signieren oder zu ändern.

Hinweis

Das erneute Signieren ist nach wie vor die bevorzugte Methode für die Bereitstellung neuer Versionen von Anwendungen. Verwenden Sie daher nach Möglichkeit die Methode des erneuten Signierens. Weitere Informationen finden Sie unter Mage.exe (Manifest Generation and Editing Tool).

Entwickler*innen von Drittanbietern und ISVs können sich für dieses Feature entscheiden, um ihrer Kundschaft die Aktualisierung ihrer Anwendungen zu erleichtern. Dieses Feature kann in folgenden Situationen verwendet werden:

  • Beim Aktualisieren einer Anwendung, nicht für die erste Installation einer Anwendung.

  • Wenn nur eine Konfiguration der Anwendung auf einem Computer vorhanden ist. Wenn beispielsweise eine Anwendung so konfiguriert ist, dass sie auf zwei verschiedene Datenbanken verweist, können Sie dieses Feature nicht verwenden.

Ausschließen von „deploymentProvider“ aus Bereitstellungsmanifesten

In .NET Framework 2.0 und .NET Framework 3.0 muss im Bereitstellungsmanifest aller ClickOnce-Anwendungen, die auf dem System für die Offlineverfügbarkeit installiert werden, deploymentProvider enthalten sein. deploymentProvider wird häufig als Aktualisierungsspeicherort bezeichnet. Hierbei handelt es sich um den Speicherort, an dem ClickOnce nach Anwendungsupdates sucht. Diese Anforderung sowie die Notwendigkeit, dass Anwendungsherausgeber ihre Bereitstellungen signieren müssen, erschwerte es einem Unternehmen, eine ClickOnce-Anwendung von einem Anbieter oder einem anderen Drittanbieter zu aktualisieren. Außerdem war es dadurch schwieriger, eine Anwendung von mehreren Standorten aus im selben Netzwerk bereitzustellen.

Dank den Änderungen, die an ClickOnce in .NET Framework 3.5 vorgenommen wurden, ist es möglich, dass ein Drittanbieter eine ClickOnce-Anwendung für eine andere Organisation bereitstellt, die dann die Anwendung in einem eigenen Netzwerk bereitstellen kann.

Entwickler*innen von ClickOnce-Anwendungen können dieses Feature nur nutzen, wenn sie deploymentProvider aus ihren Bereitstellungsmanifesten ausschließen. Diese Anforderung bedeutet, dass Sie das Argument -providerUrl ausschließen müssen, wenn Sie Bereitstellungsmanifeste mit „Mage.exe“ erstellen. Oder wenn Sie Bereitstellungsmanifeste mit „MageUI.exe“ generieren, müssen Sie darauf achten, dass das Textfeld Startspeicherort auf der Registerkarte Anwendungsmanifest leer bleibt.

Hinweis

Verwenden Sie in ClickOnce für .NET Core 3.1 und .NET 5 oder höher dotnet-mage.exe anstelle von Mage.exe. Weitere Informationen finden Sie unter ClickOnce für .NET.

deploymentProvider und Anwendungsupdates

Ab .NET Framework 3.5 müssen Sie deploymentProvider in Ihrem Bereitstellungsmanifest nicht mehr angeben, um eine ClickOnce-Anwendung sowohl für die Online- als auch für die Offlineverwendung bereitzustellen. Diese Änderung unterstützt das Szenario, in dem Sie die Bereitstellung selbst packen und signieren müssen, es anderen Unternehmen jedoch ermöglichen, die Anwendung über ihre Netzwerke bereitzustellen.

Sie müssen daran denken, dass Anwendungen, die deploymentProvider ausschließen, das Installationsverzeichnis während eines Updates erst ändern können, nachdem sie ein Update versandt haben, in dem das deploymentProvider-Tag enthalten ist.

Hier sind zwei Beispiele, um diesen Punkt zu verdeutlichen. Im ersten Beispiel veröffentlichen Sie eine ClickOnce-Anwendung ohne deploymentProvider-Tag, und Sie bitten Benutzer*innen, sie über http://www.adatum.com/MyApplication/ zu installieren. Wenn Sie das nächste Update der Anwendung über http://subdomain.adatum.com/MyApplication/ veröffentlichen möchten, haben Sie keine Möglichkeit, dieses im Bereitstellungsmanifest zu signieren, das sich in http://www.adatum.com/MyApplication/ befindet. Sie haben zwei Möglichkeiten:

  • Bitten Sie die Benutzer*innen, die vorherige Version zu deinstallieren, und installieren Sie die neue Version vom neuen Speicherort aus.

  • Schließen Sie ein Update zu http://www.adatum.com/MyApplication/ ein, das ein deploymentProvider-Tag enthält, das auf http://www.adatum.com/MyApplication/ verweist. Veröffentlichen Sie anschließend ein weiteres Update, wobei deploymentProvider auf http://subdomain.adatum.com/MyApplication/ verweist.

    Im zweiten Beispiel veröffentlichen Sie eine ClickOnce-Anwendung, die deploymentProvider angibt, und Sie beschließen, das Tag zu entfernen. Nachdem die neue Version ohne deploymentProvider auf Clients heruntergeladen wurde, können Sie den Pfad, der für Updates verwendet wird, erst umleiten, wenn Sie eine Version Ihrer Anwendung freigeben, bei der deploymentProvider wiederhergestellt wurde. Wie im ersten Beispiel muss deploymentProvider zunächst auf den aktuellen Aktualisierungspfad und darf nicht auf den neuen Speicherort verweisen. Wenn Sie in diesem Fall versuchen, ein deploymentProvider-Tag einzufügen, das auf http://subdomain.adatum.com/MyApplication/ verweist, schlägt das nächste Update fehl.

Erstellen einer Bereitstellung

Eine Schritt-für-Schritt-Anleitung zum Erstellen von Bereitstellungen, die von verschiedenen Netzwerkstandorten aus bereitgestellt werden können, finden Sie unter Exemplarische Vorgehensweise: Manuelles Bereitstellen einer ClickOnce-Anwendung, die keine erneute Signatur erfordert und Brandinginformationen beibehalten.

Zugehöriger Inhalt