Freigeben über

Erstellen Sie ClickOnce-Anwendungen zur Bereitstellung durch andere

Nicht alle Entwickler, die ClickOnce-Bereitstellungen erstellen, planen die Bereitstellung der Anwendungen selbst. Viele von ihnen packen einfach ihre Anwendung mithilfe von ClickOnce und übergeben dann die Dateien an einen Kunden, z. B. 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 in solchen Bereitstellungen in Versionen von .NET Framework vor Version 3.5 auftreten. Anschließend wird eine neue Lösung beschrieben, die mithilfe des neuen Features "Manifest für Vertrauen verwenden" in .NET Framework 3.5 bereitgestellt wird. Schließlich endet es mit empfohlenen 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

Beim Bereitstellen einer Bereitstellung für einen Kunden treten mehrere Probleme auf. Das erste Problem betrifft die Codesignatur. Um in einem Netzwerk bereitgestellt zu werden, muss das Bereitstellungsmanifest und das Anwendungsmanifest einer ClickOnce-Bereitstellung mit einem digitalen Zertifikat signiert werden. Dies stellt die Frage, 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 wichtig, 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 lizenziert eine ClickOnce-Anwendung von Microsoft Corporation, die Berichte aus daten generiert, die in einer SQL-Datenbank gespeichert sind. Microsoft liefert jede Abteilung mit einer Version der Anwendung, die für ihre Daten angepasst ist. Wenn die Anwendungen mit demselben Authenticode-Zertifikat signiert sind, würde ein Benutzer, der versucht, beide Anwendungen zu verwenden, einen Fehler feststellen, da ClickOnce die zweite Anwendung als identisch mit dem ersten betrachtet. In diesem Fall könnte der Kunde unvorhersehbare und unerwünschte Nebenwirkungen haben, die den Verlust von lokal von der Anwendung gespeicherten Daten umfassen.

Ein weiteres Problem im Zusammenhang mit der Codesignierung ist das deploymentProvider-Element im Bereitstellungsmanifest, das ClickOnce angibt, wo nach Anwendungsupdates gesucht werden soll. Dieses Element muss dem Bereitstellungsmanifest hinzugefügt werden, bevor es signiert wird. Wenn dieses Element danach hinzugefügt wird, muss das Bereitstellungsmanifest erneut signiert werden.

Den Kunden auffordern, das Bereitstellungsmanifest zu signieren

Eine Lösung für dieses Problem von nicht eindeutigen Bereitstellungen besteht darin, dass der Entwickler das Anwendungsmanifest signiert und der Kunde das Bereitstellungsmanifest signiert. Während dieser Ansatz funktioniert, werden andere Probleme eingeführt. Da ein Authenticode-Zertifikat ein geschütztes Objekt bleiben muss, kann der Kunde dem Entwickler nicht nur das Zertifikat zum Signieren der Bereitstellung erteilen. Während der Kunde das Bereitstellungsmanifest selbst signieren kann, indem er Tools verwendet, die mit dem .NET Framework SDK frei verfügbar sind, erfordert dies möglicherweise mehr technische Kenntnisse, als der Kunde bereit ist oder in der Lage ist, bereitzustellen. In solchen Fällen erstellt der Entwickler in der Regel eine Anwendung, Website oder einen anderen Mechanismus, über den der Kunde seine Version der Anwendung zur Signierung übermitteln kann.

Auswirkungen der Kundenanmeldung auf clickOnce-Anwendungssicherheit

Selbst wenn der Entwickler und der Kunde zustimmen, dass der Kunde das Anwendungsmanifest signieren soll, löst dies andere Probleme aus, die die Identität der Anwendung umgeben, insbesondere, wenn sie für die Bereitstellung vertrauenswürdiger Anwendungen gilt. (Weitere Informationen zu diesem Feature finden Sie in der Übersicht über die Bereitstellung vertrauenswürdiger Anwendungen.) Angenommen, Adventure Works möchte seine Clientcomputer so konfigurieren, dass jede anwendung, die von der Microsoft Corporation bereitgestellt wird, voll vertrauenswürdig ausgeführt wird. Wenn Adventure Works das Bereitstellungsmanifest signiert, verwendet ClickOnce die Sicherheitssignatur von Adventure Work, um die Vertrauensstufe der Anwendung zu ermitteln.

Erstellen Sie Kundenbereitstellungen mithilfe des Anwendungsmanifests zur Gewährleistung von Vertrauen

ClickOnce in .NET Framework 3.5 enthält ein neues Feature, das Entwicklern und Kunden eine neue Lösung für das Szenario gibt, in dem die Manifeste signiert werden sollen. Das ClickOnce-Anwendungsmanifest unterstützt ein neues Element namens <useManifestForTrust>, das es einem Entwickler ermöglicht zu kennzeichnen, dass die digitale Signatur des Anwendungsmanifests für Vertrauensentscheidungen herangezogen werden soll. Der Entwickler verwendet ClickOnce-Verpackungstools wie Mage.exe, MageUI.exeund Visual Studio, um dieses Element in das Anwendungsmanifest einzuschließen sowie sowohl den Publisher-Namen als auch den Namen der Anwendung im Manifest einzubetten.

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

Die Verwendung eines selbstsignierten Zertifikats für das Bereitstellungsmanifest bietet mehrere Vorteile. Durch die Beseitigung der Notwendigkeit, dass der Kunde sein eigenes Authenticode-Zertifikat erhält oder erstellt, <useManifestForTrust> vereinfacht die Bereitstellung für den Kunden, während der Entwickler seine eigene Brandingidentität für die Anwendung beibehalten kann. Das Ergebnis ist eine Reihe signierter Bereitstellungen, die sicherer sind und eindeutige Anwendungsidentitäten aufweisen. Dadurch wird der potenzielle Konflikt beseitigt, der durch die Bereitstellung derselben Anwendung für mehrere Kunden auftreten kann.

Schritt-für-Schritt-Anleitungen zum Erstellen einer ClickOnce-Bereitstellung mit aktivierter <useManifestForTrust> finden Sie unter Durchführung: Manuelles Bereitstellen einer ClickOnce-Anwendung, die keine erneute Signierung erfordert und die Markeninformationen bewahrt.

Funktionsweise des Anwendungsmanifests für Vertrauen zur Laufzeit

Um besser zu verstehen, wie das Anwendungsmanifest im Kontext von Vertrauen zur Laufzeit funktioniert, ziehen Sie das folgende Beispiel in Betracht. Eine ClickOnce-Anwendung, die auf .NET Framework 3.5 abzielt, 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-Kunden 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. Die Zertifikat- und Bereitstellungsinformationen identifizieren die Anwendung eindeutig für ClickOnce auf dem Clientcomputer. Wenn der Benutzer versucht, dieselbe Anwendung erneut von einem anderen Speicherort zu installieren, kann ClickOnce diese Identität verwenden, um festzustellen, dass die Anwendung bereits auf dem Client vorhanden ist.

Als Nächstes untersucht ClickOnce das Authenticode-Zertifikat, das zum Signieren des Anwendungsmanifests verwendet wird, wodurch die Vertrauensstufe bestimmt wird, die ClickOnce gewährt. Da Adventure Works seine Clients so konfiguriert hat, dass jeder Anwendung, die von Microsoft signiert ist, vertraut wird, erhält diese ClickOnce-Anwendung volle Vertrauenswürdigkeit. Weitere Informationen finden Sie in der Übersicht über die Bereitstellung vertrauenswürdiger Anwendungen.

Kundenbereitstellungen für frühere Versionen erstellen

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 Vorteilen und Nachteilen der einzelnen Lösungen zusammengefasst.

Bereitstellungen im Auftrag des Kunden signieren

Eine mögliche Bereitstellungsstrategie besteht darin, dass der Entwickler einen Mechanismus zum Signieren von Bereitstellungen im Namen ihrer Kunden mithilfe des eigenen privaten Schlüssels des Kunden erstellt. Dadurch wird verhindert, dass der Entwickler private Schlüssel oder mehrere Bereitstellungspakete verwalten muss. Der Entwickler bietet nur die gleiche Bereitstellung für jeden Kunden. Der Kunde muss ihn mithilfe des Signaturdiensts für seine Umgebung anpassen.

Ein Nachteil dieser Methode ist die Zeit und Kosten, die für die Implementierung erforderlich sind. Während ein solcher Dienst mithilfe der im .NET Framework SDK bereitgestellten Tools erstellt werden kann, wird dem Produktlebenszyklus mehr Entwicklungszeit hinzugefügt.

Wie weiter oben in diesem Thema erwähnt, besteht ein weiterer Nachteil darin, dass jede Version der Anwendung dieselbe 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 für jede Version der Anwendung eine separate Identität erstellt und potenzielle Identitätskonflikte beseitigt. Dieses Feld entspricht dem -Name Argument für Mage.exeund dem Feld "Name " auf der Registerkarte " Name " in MageUI.exe.

Angenommen, der Entwickler hat eine Anwendung namens Application1 erstellt. Anstatt eine einzelne Bereitstellung mit dem Feld "Name" auf "Application1" zu erstellen, kann der Entwickler mehrere Bereitstellungen mit einer kundenspezifischen Variante für diesen Namen erstellen, z. B. Application1-CustomerA, Application1-CustomerB usw.

Bereitstellen mithilfe eines Installationspakets

Eine zweite mögliche Bereitstellungsstrategie besteht darin, ein Microsoft Setup-Projekt zu generieren, um die erste Bereitstellung der ClickOnce-Anwendung durchzuführen. Dies kann in mehreren Formaten bereitgestellt werden: als MSI-Bereitstellung, als ausführbare Setupdatei (.EXE) oder als Cabinet-Datei (.cab) zusammen mit einem Batchskript.

Mit dieser Technik stellt der Entwickler dem Kunden eine Bereitstellung bereit, die die Anwendungsdateien, das Anwendungsmanifest und ein Bereitstellungsmanifest enthält, das als Vorlage dient. Der Kunde würde das Setupprogramm ausführen, das ihn auffordert, eine Bereitstellungs-URL (den Server- oder Dateifreigabespeicherort, von dem Benutzer die ClickOnce-Anwendung installieren werden) sowie ein digitales Zertifikat einzugeben. Die Setupanwendung kann auch festlegen, dass zusätzliche ClickOnce-Konfigurationsoptionen angezeigt werden, z. B. das Updateüberprüfungsintervall. Sobald diese Informationen gesammelt wurden, generiert das Setupprogramm das eigentliche Bereitstellungsmanifest, signiert sie und veröffentlicht die ClickOnce-Anwendung an dem angegebenen Serverspeicherort.

Es gibt drei Möglichkeiten, wie der Kunde das Bereitstellungsmanifest in dieser Situation signieren kann:

  1. Der Kunde kann ein gültiges Zertifikat verwenden, das von einer Zertifizierungsstelle ausgestellt wurde.

  2. Als Variante dieses Ansatzes kann der Kunde das Bereitstellungsmanifest mit einem selbstsignierten Zertifikat signieren. Der Nachteil ist, dass die Anwendung die Wörter "Unbekannter Herausgeber" anzeigt, wenn der Benutzer gefragt wird, ob er sie installieren möchte. Der Vorteil besteht jedoch darin, dass kleinere Kunden nicht die Zeit und das Geld ausgeben müssen, die für ein von einer Zertifizierungsstelle ausgestelltes Zertifikat erforderlich sind.

  3. Schließlich kann der Entwickler sein eigenes selbstsigniertes Zertifikat in das Setuppaket aufnehmen. Dies führt zu den potenziellen Problemen mit der Anwendungsidentität, die weiter oben in diesem Thema erläutert wurden.

    Der Nachteil der Projektmethode für die Einrichtungsbereitstellung ist die Zeit und die Kosten, die zum Erstellen einer benutzerdefinierten Bereitstellungsanwendung erforderlich sind.

Den Kunden das Bereitstellungsmanifest generieren lassen

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 über einen Entwickler- oder Systemadministrator verfügen muss, der sie verwendet. Einige Kunden fordern möglicherweise eine Lösung, die wenig oder gar keinen technischen Aufwand erfordert.

Verwandte Inhalte

  • Last updated on