Erstellen von ClickOnce-Anwendungen für die Bereitstellung durch Dritte

2025-06-12

Nicht alle Entwickler, die ClickOnce-Bereitstellungen erstellen, planen, die Anwendungen selbst bereitzustellen. Viele von ihnen erstellen einfach Anwendungspakete mithilfe von ClickOnce und übergeben die Dateien dann an einen Kunden, z. B. an ein großes Unternehmen. Der Kunde ist für das Hosten der Anwendung in seinem Netzwerk verantwortlich. In diesem Thema werden einige der Probleme erläutert, die mit solchen Bereitstellungen in Versionen von .NET Framework vor Version 3.5 verbunden sind. Anschließend wird eine neue Lösung beschrieben, die mithilfe des neuen Features „Manifest für Vertrauensstellung verwenden“ in .NET Framework 3.5 bereitgestellt wird. Abschließend finden Sie empfohlene Strategien zum Erstellen von ClickOnce-Bereitstellungen für Kunden, die noch ältere Versionen von .NET Framework verwenden.

Probleme beim Erstellen von Bereitstellungen für Kunden

Wenn Sie eine Bereitstellung für einen Kunden planen, treten mehrere Probleme auf. Das erste Problem betrifft die Codesignatur. Um in einem Netzwerk bereitgestellt zu werden, müssen das Bereitstellungsmanifest und das Anwendungsmanifest einer ClickOnce-Bereitstellung mit einem digitalen Zertifikat signiert werden. Dies wirft die Frage auf, ob beim Signieren der Manifeste das Zertifikat des Entwicklers oder das Zertifikat des Kunden verwendet werden soll.

Die Frage, welches Zertifikat verwendet werden soll, ist entscheidend, da die Identität einer ClickOnce-Anwendung auf der digitalen Signatur des Bereitstellungsmanifests basiert. Wenn der Entwickler das Bereitstellungsmanifest signiert, kann dies zu Konflikten führen, wenn der Kunde ein großes Unternehmen ist und mehrere Abteilungen des Unternehmens eine angepasste Version der Anwendung bereitstellen.

Angenommen, Adventure Works verfügt über eine Finanzabteilung und eine Personalabteilung. Beide Abteilungen lizenzieren eine ClickOnce-Anwendung von Microsoft Corporation, die Berichte aus Daten generiert, die in einer SQL-Datenbank gespeichert sind. Microsoft stellt jeder Abteilung eine Version der Anwendung zur Verfügung, die für ihre Daten angepasst ist. Wenn die Anwendungen mit demselben Authenticode-Zertifikat signiert sind, tritt bei einem Benutzer, der versucht, beide Anwendungen zu verwenden, ein Fehler auf, da ClickOnce die zweite Anwendung als identisch mit der ersten betrachtet. In diesem Fall kann der Kunde unvorhersehbare und unerwünschte Nebenwirkungen bemerken, die den Verlust von Daten umfassen, die lokal von der Anwendung gespeichert werden.

Ein weiteres Problem im Zusammenhang mit der Codesignatur ist das deploymentProvider-Element im Bereitstellungsmanifest, das ClickOnce informiert, wo nach Anwendungsupdates gesucht werden soll. Dieses Element muss dem Bereitstellungsmanifest vor dem Signieren hinzugefügt werden. Wenn dieses Element erst im Anschluss hinzugefügt wird, muss das Bereitstellungsmanifest erneut signiert werden.

Der Kunde muss das Bereitstellungsmanifest signieren

Eine Lösung für dieses Problem nicht eindeutiger Bereitstellungen besteht darin, dass der Entwickler das Anwendungsmanifest signiert und der Kunde das Bereitstellungsmanifest. Dieser Ansatz funktioniert zwar, führt aber zu anderen Problemen. Da ein Authenticode-Zertifikat eine geschützte Ressource bleiben muss, kann der Kunde das Zertifikat nicht einfach an den Entwickler übergeben, um die Bereitstellung zu signieren. Der Kunde kann das Bereitstellungsmanifest zwar selbst signieren, indem er Tools verwendet, die mit dem .NET Framework SDK kostenlos zur Verfügung stehen, doch kann dies mehr technisches Wissen erfordern, als der Kunde bereit oder in der Lage ist, bereitzustellen. In solchen Fällen erstellt der Entwickler in der Regel eine Anwendung, eine Website oder einen anderen Mechanismus, über den der Kunde seine Version der Anwendung zum Signieren übermitteln kann.

Auswirkungen der Kundensignatur auf die ClickOnce-Anwendungssicherheit

Selbst wenn der Entwickler und der Kunde sich einig sind, dass der Kunde das Anwendungsmanifest signieren sollte, wirft dies weitere Fragen zur Identität der Anwendung auf, insbesondere im Hinblick auf die vertrauenswürdige Bereitstellung der Anwendung. (Weitere Informationen zu dieser Funktion finden Sie unter Übersicht über vertrauenswürdige Anwendungsbereitstellung). Angenommen, Adventure Works möchte die Clientcomputer so konfigurieren, dass jede Anwendung, die von Microsoft Corporation bereitgestellt wird, mit voller Vertrauenswürdigkeit ausgeführt wird. Wenn Adventure Works das Bereitstellungsmanifest signiert, verwendet ClickOnce die Sicherheitssignatur von Adventure Works, um die Vertrauensstufe der Anwendung zu bestimmen.

Erstellen von Kundenbereitstellungen mithilfe des Anwendungsmanifests für die Vertrauensstellung

ClickOnce in .NET Framework 3.5 enthält ein neues Feature, das Entwicklern und Kunden eine neue Lösung für das Szenario bietet, wie die Manifeste signiert werden sollen. Das ClickOnce-Anwendungsmanifest unterstützt ein neues Element namens <useManifestForTrust>, das es einem Entwickler ermöglicht, anzugeben, dass die digitale Signatur des Anwendungsmanifests zum Treffen von Vertrauensentscheidungen verwendet werden sollte. Der Entwickler verwendet ClickOnce-Pakettools (z. B. Mage.exe, MageUI.exe und Visual Studio), um dieses Element in das Anwendungsmanifest einzubinden und sowohl den Namen des Herausgebers als auch den Namen der Anwendung in das Manifest einzubetten.

Bei Verwendung von <useManifestForTrust> muss das Bereitstellungsmanifest nicht mit einem Authenticode-Zertifikat signiert werden, das von einer Zertifizierungsstelle ausgestellt wurde. Stattdessen kann es mit einem so genannten selbstsignierten Zertifikat signiert werden. Ein selbstsigniertes Zertifikat wird entweder vom Kunden oder vom Entwickler mithilfe der standardbasierten .NET Framework SDK-Tools generiert und dann mithilfe der ClickOnce-Standardbereitstellungstools auf das Bereitstellungsmanifest angewendet. Weitere Informationen finden Sie in unter MakeCert.

Die Verwendung eines selbstsignierten Zertifikats für das Bereitstellungsmanifest bietet mehrere Vorteile. Da der Kunde kein eigenes Authenticode-Zertifikat erwerben oder erstellen muss, vereinfacht <useManifestForTrust> die Bereitstellung für den Kunden, während der Entwickler seine eigene Markenidentität für die Anwendung beibehalten kann. Das Ergebnis ist eine Reihe signierter Bereitstellungen, die sicherer sind und über eindeutige Anwendungsidentitäten verfügen. Dadurch wird der potenzielle Konflikt beseitigt, der bei der Bereitstellung derselben Anwendung für mehrere Kunden auftreten kann.

Schritt-für-Schritt-Informationen zum Erstellen einer ClickOnce-Bereitstellung mit aktivierter <useManifestForTrust>-Funktion finden Sie unter Exemplarische Vorgehensweise: Manuelles Bereitstellen einer ClickOnce-Anwendung, die keine erneute Signatur erfordert und die Brandinginformationen beibehält.

Funktionsweise des Anwendungsmanifests für die Vertrauensstellung zur Laufzeit

Um besser zu verstehen, wie die Verwendung des Anwendungsmanifests für die Vertrauensstellung zur Laufzeit funktioniert, sehen Sie sich das folgende Beispiel an. Eine ClickOnce-Anwendung, die .NET Framework 3.5 als Ziel verwendet, wird von Microsoft erstellt. Das Anwendungsmanifest verwendet das <useManifestForTrust>-Element und wird von Microsoft signiert. Adventure Works signiert das Bereitstellungsmanifest mithilfe eines selbstsignierten Zertifikats. Adventure Works-Clients sind so konfiguriert, dass sie jeder von Microsoft signierten Anwendung vertrauen.

Wenn ein Benutzer auf einen Link zum Bereitstellungsmanifest klickt, installiert ClickOnce die Anwendung auf dem Computer des Benutzers. Das Zertifikat und die Bereitstellungsinformationen identifizieren die Anwendung eindeutig für ClickOnce auf dem Clientcomputer. Wenn der Benutzer versucht, dieselbe Anwendung erneut von einem anderen Speicherort aus zu installieren, kann ClickOnce diese Identität verwenden, um festzustellen, dass die Anwendung bereits auf dem Client vorhanden ist.

Dann untersucht ClickOnce das Authenticode-Zertifikat, das zum Signieren des Anwendungsmanifests verwendet wird und die Vertrauensebene bestimmt, die ClickOnce gewährt. Da Adventure Works die Clients so konfiguriert hat, dass sie jeder von Microsoft signierten Anwendung vertrauen, wird dieser ClickOnce-Anwendung volle Vertrauenswürdigkeit gewährt. Weitere Informationen finden Sie unter Überblick über die Bereitstellung vertrauenswürdiger Anwendungen.

Erstellen von Kundenbereitstellungen für frühere Versionen

Was geschieht, wenn ein Entwickler ClickOnce-Anwendungen für Kunden bereitstellt, die ältere Versionen von .NET Framework verwenden? In den folgenden Abschnitten werden mehrere empfohlene Lösungen zusammen mit den jeweiligen Vor- und Nachteilen zusammengefasst.

Signieren von Bereitstellungen im Auftrag des Kunden

Eine mögliche Bereitstellungsstrategie besteht darin, dass der Entwickler einen Mechanismus zum Signieren von Bereitstellungen im Auftrag seiner Kunden erstellt, indem er den eigenen privaten Schlüssel des Kunden verwendet. Dadurch wird verhindert, dass der Entwickler private Schlüssel oder mehrere Bereitstellungspakete verwalten muss. Der Entwickler stellt nur die gleiche Bereitstellung für jeden Kunden bereit. Es liegt am Kunden, diese mithilfe des Signaturdiensts für seine Umgebung anzupassen.

Ein Nachteil dieser Methode ist der Zeit- und Kostenaufwand, der für die Implementierung erforderlich ist. Ein solcher Dienst kann zwar mithilfe der Tools erstellt werden, die im .NET Framework SDK bereitgestellt werden, fügt aber dem Produktlebenszyklus mehr Entwicklungszeit hinzu.

Wie weiter oben in diesem Thema erwähnt, besteht ein weiterer Nachteil darin, dass die Version der Anwendung jedes Kunden die gleiche Anwendungsidentität aufweist, was zu Konflikten führen kann. Wenn dies ein Problem ist, kann der Entwickler das Feld „Name“ ändern, das beim Generieren des Bereitstellungsmanifests verwendet wird, um jeder Anwendung einen eindeutigen Namen zu geben. Dadurch wird eine separate Identität für jede Version der Anwendung erstellt, und potenzielle Identitätskonflikte werden beseitigt. Dieses Feld entspricht dem -Name-Argument für „Mage.exe“ und dem Feld Name auf der Registerkarte Name in „MageUI.exe“.

Angenommen, der Entwickler hat eine Anwendung mit dem Namen „Application1“ erstellt. Anstatt eine einzelne Bereitstellung zu erstellen, in der das Feld „Name“ auf „Application1“ festgelegt ist, kann der Entwickler mehrere Bereitstellungen mit einer kundenspezifischen Variante dieses Namens erstellen, z. B. „Application1-CustomerA“, „Application1-CustomerB“ usw.

Bereitstellen mithilfe eines Setuppakets

Eine zweite mögliche Bereitstellungsstrategie besteht darin, ein Microsoft Setup-Projekt zu generieren, um die anfängliche Bereitstellung der ClickOnce-Anwendung durchzuführen. Diese kann in einem von mehreren verschiedenen Formaten bereitgestellt werden: als MSI-Bereitstellung, als ausführbare Setupdatei (EXE-Datei) oder als Kabinettdatei (CAB-Datei) zusammen mit einem Batchskript.

Mit dieser Technik würde der Entwickler dem Kunden eine Bereitstellung überlassen, die die Anwendungsdateien, das Anwendungsmanifest und ein Bereitstellungsmanifest enthält, das als Vorlage dient. Der Kunde führt das Setupprogramm aus, wodurch er zur Eingabe einer Bereitstellungs-URL (dem Server- oder Dateifreigabespeicherort, von dem aus Benutzer die ClickOnce-Anwendung installieren) sowie eines digitalen Zertifikats aufgefordert wird. Die Setupanwendung kann auch zur Eingabe zusätzlicher ClickOnce-Konfigurationsoptionen auffordern, z. B. zur Eingabe des Updateüberprüfungsintervalls. Sobald diese Informationen erfasst wurden, generiert das Setupprogramm das echte Bereitstellungsmanifest, signiert es und veröffentlicht die ClickOnce-Anwendung am angegebenen Serverspeicherort.

Es gibt drei Möglichkeiten, wie der Kunde das Bereitstellungsmanifest unter diesen Umständen signieren kann:

Der Kunde kann ein gültiges Zertifikat verwenden, das von einer Zertifizierungsstelle (ZS) ausgestellt wurde.
Als Variante dieses Ansatzes kann der Kunde sein Bereitstellungsmanifest mit einem selbstsignierten Zertifikat signieren. Der Nachteil ist, dass die Anwendung die Angabe „Unbekannter Herausgeber“ anzeigt, wenn der Benutzer gefragt wird, ob sie installiert werden soll. Der Vorteil ist jedoch, dass kleinere Kunden nicht die Zeit und das Geld aufwenden müssen, die für ein von einer Zertifizierungsstelle ausgestelltes Zertifikat erforderlich sind.
Schließlich kann der Entwickler sein eigenes selbstsigniertes Zertifikat in das Setuppaket aufnehmen. Dies führt zu den möglichen Problemen mit der Anwendungsidentität, die bereits weiter oben in diesem Thema angesprochen wurden.

Der Nachteil der Methode des Setupbereitstellungsprojekts ist der Zeit- und Kostenaufwand, der zum Erstellen einer benutzerdefinierten Bereitstellungsanwendung erforderlich ist.

Kunde muss das Bereitstellungsmanifest generieren

Eine dritte mögliche Bereitstellungsstrategie besteht darin, nur die Anwendungsdateien und das Anwendungsmanifest an den Kunden zu übergeben. In diesem Szenario ist der Kunde dafür verantwortlich, das .NET Framework SDK zum Generieren und Signieren des Bereitstellungsmanifests zu verwenden.

Der Nachteil dieser Methode besteht darin, dass der Kunde die .NET Framework SDK-Tools installieren muss und einen Entwickler oder Systemadministrator benötigt, der in der Verwendung dieser Tools erfahren ist. Einige Kunden verlangen möglicherweise eine Lösung, die wenig oder keinen technischen Aufwand auf ihrer Seite erfordert.