问题
I've created a custom setup package to install some fonts on a client machine and deployed it to the prerequisites folder under C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\FontsInstaller. Everything is fine with reference it as a prerequisite in Visual Studio 2010 and I am able to publish the application without issue.
The client on the other hand gets an error during the Hash verification:
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.
I've tried including the hash and excluding it with the Bootstrapper Manifest Generator and I always get the same result on the client. The file is immediately deleted (for security reasons) as soon as it fails hash verification.
Now, I've found a Microsoft Connect bug report saying:
"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."
I tried building this installer on another workstation with no VS2012 installed, and it passes the hash validation on the client (I ran into a signing issue, but thats a different story). It really is a problem with the build machine having VS2012, not the client, as the package built on my original workstation also fails on the machine that does not have VS2012.
Has anyone else experienced this issue, if so, have you found a workaround besides not having VS2012 installed?
回答1:
I used a reflection tool to look at the bootstrapper generation MSBuild task (on a machine with .NET 4.5 installed) and found that it augments the product.xml file's <PackageFile /> elements. Specifically, it attempts to compute a public key from each file. If it can find one, it compares the key with the value of the PublicKey attribute. If the values are different, it emits a warning but in both cases it keeps the value it just computed.
If it couldn't determine a public key, it then computes a SHA256 hash of the file and performs a similar comparison with the value of the Hash attribute, emitting a warning if they are different and setting the value of the Hash attribute with the computed value.
You can confirm these findings by extracting the SETUPCFG resource from the resulting setup.exe; it's a text version of a merge of the product.xml files.
Anyway, remember how I said it computes a SHA256 hash of the files if it could not find a public key? The documentation for the <PackageFiles> Element (Bootstrapper) says the value of the Hash attribute should be a SHA1 hash.
I was not able to verify which of SHA1 or SHA256 the resulting setup.exe uses to verify the value of the Hash attribute (it's unmanaged code and I couldn't find the symbols for it), but let the record show that a similar look at the .NET 4.0 version of the bootstrapper generator MSBuild task reveals that it is indeed using the SHA1 algorithm for computing the value of the Hash attribute, so by deduction we can say setup.bin (at least the one from the Windows SDK v7.0A) is using SHA1. I'm pretty sure I tried using the setup.bin from the Windows SDK v8.0A and I got the same (wrong) results. (One could confirm this by copying the setup.bin from the v8.0A SDK to a .NET 4.0-only machine and seeing if the resulting setup.exe can install a custom bootstrapper package using hash-based verification)
So, if hash-based verification is broken in the setup bootstrapper, we can at least use the public key (certificate-based) verification instead. The good news is that the bootstrapper generator will automatically start using this mechanism if it was able to extract the certificate's public key from the package file. The bad news is that this means each package file must be signed with signtool.exe and a valid code-signing certificate (not everybody might have a code-signing certificate lying around, although if you're doing click-once you might...).
Once I signed the package files used by our custom bootstrapper, I stopped getting the installation failures at run-time when I built the project using a machine that had .NET 4.5 installed, while still producing a valid bootstrapper when using a machine that did not have .NET 4.5 installed.
tl;dr: Sign your package files with a code-signing certificate to avoid a defect introduced in .NET 4.5.
回答2:
You need to change GenerateBootstrapper Path from:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper
to
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper
回答3:
You need to change GenerateBootstrapper Path from:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper
to
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper
and copy msi packages (that you want to use) from C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper to C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper
来源：https://stackoverflow.com/questions/13073915/clickonce-prerequisite-error-published-installer-may-be-corrupt