ClickOnce Voraussetzung: Fehler: veröffentlichtes Installationsprogramm ist möglicherweise beschädigt

Question

Ich habe ein benutzerdefiniertes Installationspaket erstellt, um einige Schriftarten auf einem Clientcomputer zu installieren und im Ordner mit den Voraussetzungen unter C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\FontsInstaller bereitzustellen. Alles ist in Ordnung, als Referenz in Visual Studio 2010 und ich bin in der Lage, die Anwendung ohne Problem zu veröffentlichen.

Der Client auf der anderen Seite erhält einen Fehler während der Hash-Überprüfung:

Verifying file hash

Error: Setup has detected that the file 'C:\Users\RMORAN~1\AppData\Local\Temp\VSD4684.tmp\FontsInstaller\fontsinstaller.msi' has either changed since it was initially published or may be corrupt.

Ich habe den Hash versucht, einschließlich und es mit dem Bootstrapper Manifest Generator ohne und ich das gleiche Ergebnis auf dem Client immer erhalten . Die Datei wird sofort (aus Sicherheitsgründen) gelöscht, sobald die Hash-Überprüfung fehlschlägt. Jetzt

, habe ich festgestellt ein Microsoft Connect bug report sagen:

"I have a custom bootstrapper package installed as a prerequisite for my application. When I build this on a system that has Visual Studio 2012 installed, the installation fails with the following error:

Setup has detected that the file '...' has either changed since it was initially published or may be corrupt.

I am building in Visual Studio 2010, with no changes to the package or projects. When Visual Studio 2012 is not installed, this works as expected."

Ich habe versucht, den Aufbau dieser Installationsprogramm auf einem anderen Arbeitsplatz ohne VS2012 installiert und übergibt die Hash-Validierung auf dem Client (ich lief in eine Unterzeichnung Ausgabe , aber das ist eine andere Geschichte). Es ist wirklich ein Problem mit der Build-Maschine mit VS2012, nicht der Client, da das Paket auf meiner ursprünglichen Arbeitsstation auch auf der Maschine fehlschlägt, die nicht VS2012 hat.

Hat jemand anderes dieses Problem erfahren, wenn ja, haben Sie eine Problemumgehung gefunden und VS2012 nicht installiert?

Answer 1

benutzen ich ein Reflexionswerkzeug an der Bootstrap Generation MSBuild Aufgabe zu suchen (auf einer Maschine mit 4.5 installiert .NET) und festgestellt, dass es der <PackageFile /> Elemente product.xml Datei erweitert. Insbesondere versucht es, einen öffentlichen Schlüssel aus jeder Datei zu berechnen. Wenn es einen finden kann, vergleicht es den Schlüssel mit dem Wert des PublicKey Attributs. Wenn die Werte unterschiedlich sind, wird eine Warnung ausgegeben, aber in beiden Fällen behält sie den Wert bei, den sie gerade berechnet hat.

Wenn es keinen öffentlichen Schlüssel bestimmen kann, berechnet dann eine SHA256-Hash der Datei und führt einen ähnlichen Vergleich mit dem Wert des Hash Attributs, eine Warnung emittieren, wenn sie den Wert der Hash anders und Einstellung sind Attribut mit dem berechneten Wert.

Sie können diese Ergebnisse bestätigen, indem Sie die SETUPCFG Ressource aus dem resultierenden setup.exe extrahieren; es ist eine Textversion einer Zusammenführung der product.xml Dateien.

Wie auch immer, wie ich sagte, es berechnet einen SHA256-Hash der Dateien, wenn es keinen öffentlichen Schlüssel finden konnte? Die Dokumentation für die <PackageFiles> Element (Bootstrapper) sagt der Wert des Hash Attribut sollte ein SHA1 Hash sein.

war ich nicht in der Lage, die von SHA1 zu verifizieren oder SHA256 die resultierenden setup.exe verwendet den Wert des Hash Attributs, um zu überprüfen (es ist nicht verwalteten Code, und ich konnte die Symbole für ihn nicht finden), aber die Aufzeichnung zeigen lassen, dass ein ähnlicher Blick auf die .NET 4.0-Version des Bootstrapper-Generators MSBuild Aufgabe zeigt, dass es in der Tat den SHA1-Algorithmus für die Berechnung des Werts der Hash Attribut verwendet, so dass wir sagen können setup.bin (zumindest die aus dem Windows SDK v7. 0A) benutzt SHA1. Ich bin mir ziemlich sicher, dass ich versucht habe, die setup.bin aus dem Windows SDK v8.0A zu verwenden, und ich habe die gleichen (falschen) Ergebnisse. (Man könnte dies bestätigen, indem man die setup.bin aus dem SDK v8.0A in ein .NET 4 kopiert.0-only-Maschine und sehen, ob die resultierende setup.exe eine benutzerdefinierte Bootstrap-Paket mit Hash-basierte Verifikation installieren können)

Also, wenn Hash-basierte Verifikation im Setup Bootstrap gebrochen ist, können wir zumindest verwenden den öffentlichen Schlüssel (zertifikatsbasierte) Überprüfung statt. Die gute Nachricht ist, dass der Bootstrapper-Generator diesen Mechanismus automatisch startet, wenn er den öffentlichen Schlüssel des Zertifikats aus der Paketdatei extrahieren konnte. Die schlechte Nachricht ist, dass dies bedeutet, jede Paketdatei muss mit signtool.exe und einem gültigen Code-Signing-Zertifikat signiert sein (nicht jeder hat vielleicht ein Code-Signing-Zertifikat herumliegen, obwohl, wenn Sie Click-Once tun, können Sie .. .).

Sobald ich die von unserem benutzerdefinierten Bootstrapper verwendeten Paketdateien signiert hatte, hörte ich die Installationsfehler zur Laufzeit auf, als ich das Projekt mit einem Computer mit .NET 4.5 erstellte und trotzdem einen gültigen Bootstrapper erzeugte Maschine, auf der .NET 4.5 nicht installiert war.

tl; dr: Unterschreiben Sie Ihre Paketdateien mit einem Codesignaturzertifikat, um einen in .NET 4.5 eingeführten Fehler zu vermeiden.

Answer 2

Sie müssen GenerateBootstrapper Path aus ändern:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper

zu

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper

Answer 3

Sie ändern müssen GenerateBootstrapper Pfad aus:

C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bootstrapper

zu

C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ V8.1A \ Bootstrapper

und kopieren msi Pakete von C (die Sie verwenden möchten): \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bootstrapper nach C: \ Programme (x86) \ Microsoft SDKs \ Windows \ v8.1A \ Bootstrapper