Boostrapper package creation corrupted when VS 2012 installed - by Daryl J Reed

Status : 


Sign in
to vote
ID 758814 Comments
Status Active Workarounds
Type Bug Repros 24
Opened 8/20/2012 3:31:07 PM
Access Restriction Public


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.
Sign in to post a comment.
Posted by Keith Dorken on 9/8/2015 at 9:43 AM
This problem has appeared as well using VS 2015 and building a bootstrapper for SQLSysClrTypes. The relevant part of the install log at time of failure is:

Downloading files to "C:\Users\KADORK~1.THI\AppData\Local\Temp\VSD7C9F.tmp\"
(9/8/2015 9:29:22 AM) Downloading 'SqlClrTypes_x86\SQLSysClrTypes.msi' from '' to 'C:\Users\KADORK~1.THI\AppData\Local\Temp\VSD7C9F.tmp\'
Download completed at 9/8/2015 9:29:23 AM
Verifying file integrity of C:\Users\KADORK~1.THI\AppData\Local\Temp\VSD7C9F.tmp\SqlClrTypes_x86\SQLSysClrTypes.msi
WinVerifyTrust returned 0
File trusted
Error: Setup has detected that the file 'C:\Users\KADORK~1.THI\AppData\Local\Temp\VSD7C9F.tmp\SqlClrTypes_x86\SQLSysClrTypes.msi' has changed since it was initially published.
Posted by Microsoft on 1/6/2014 at 11:42 AM
Sorry for the delayed reply.
Let me explain the fix we made in VS 2012 Update 2, what is expected to work with that version and suggest a workaround for scenarios with VS 2010 + VS 2012 side by side on the same machine.

As the earlier comments in this bug suggest the problem arises when we switched to using a SHA256 hash when building custom unsigned bootstrapper packages.
When you publish any prerequisite bootstrapper the first thing we try to use is the bootstrapper packages certificate. If the package is not signed then we fall back on a hash of the bootstrapper to verify the integrity of the file being downloaded (This is why there is no issue when the bootstrapper package is signed).
In VS 2012 RTM we switched the hash calculation mechanism to SHA256 as its a more secure standard. Unfortunately we only did this during the msbuild package generation step. At runtime when the bootstrapper package was downloaded it would still try to create a SHA1 hash of the package it downloaded and compare it to the SHA256 hash generated during build which would never work. With VS 2012 Update 2 we updated the runtime component (setup.bin) to correctly calculate SHA1 or SHA256 hashes of the file being downloaded for comparison to the hash generated during build.
So with VS2012 update 2 you should be able to sucessfully publish and install a custom unsigned bootstrapper package.

Now with the side by side issue when you have VS 2010 installed on a machine which also has VS 2012 (or .Net 4.5 installed). Unfortunately when .Net 4.5 gets installed on a machine even when you use a VS2010 project the .Net 4.5 MSBuild task gets used when generating the publish package and this task ends up creating a SHA256 hash for the bootstrapper package.
The runtime bootstrapper component in VS 2010 isnt able to calculate this SHA256 hash correctly on the downloaded bootstrapper package and so VS2010 packages would still fail.

The workaround to this is to replace the VS2010 Bootstrapper runtime component with the one from VS2012 Update 2 which is capable of handling the SHA256 hash -
To get the VS 2012 Update 2 bootstrapper engine copy the file at -
%Program Files (x86)%\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Engine\setup.bin
(v8.1A - VS2012)

and replace the VS 2010 bootstrapper engine at -
%Program Files (x86)%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Engine\setup.bin
(v7.0A - VS2010. You may want to keep a backup copy of this file just in case)

Once you have updated the VS2010 setup.bin with the VS2012 Update 2 setup.bin it should be able to correctly calculate the SHA1/SHA256 hashes even for projects published through VS2010.

Again you only need to do this if you want to publish a VS2010 project on machine which also has VS2012 or .Net 4.5.
If you have just VS2012 update 2 on the machine then it should work just fine without the need for any workaround.
Similarly if you have just VS 2010 on the machine then too it should work fine without any workaround.

Please let me know if you are still facing issues outside these scenarios.
Apologies for all the trouble and thanks for reading through.

Saurabh Bhatia
Program Manager, Visual Studio
Posted by Capstoner on 1/6/2014 at 10:50 AM
I just confirmed that this is STILL a problem even with the latest VS2012 Update 4.
Posted by DCTPT on 11/20/2013 at 11:54 AM
Since the bug was not corrected in VS 2012 Update 2 as announced, can we at least get an update on when it will be done? On one hand Microsoft wants us to move to .NET 4.5 and Windows 8, on the other hand they give us software that doesn't work on .NET 4.5. We have to keep a .NET 4.0 build machine around for a single bootstrapper and that's absurd. It's been over a year, please wake up and do something.
Posted by Capstoner on 9/24/2013 at 5:16 AM
We have VS2012 Update 3 and can still reproduce this problem.
Posted by Bill Arnette on 8/20/2013 at 10:28 AM
Appears to be fixed in Update 3.
Posted by giammin on 7/9/2013 at 4:30 AM
just experiencing this bug. Till today no solution provided by Microsoft.

the workaround provided is quite useless in many cases.

It is shameful!
Posted by Travis Troup on 5/22/2013 at 2:37 PM
I also can confirm that Update 2 does not fix this issue. Microsoft, is it going to be in Update 3? What happened?
Posted by bawoodruff on 4/24/2013 at 2:20 PM
I've installed Update 2 to VS 2012 and the problem with including custom packages in VS 2010 for ClickOnce deployment is still broken.
Posted by Microsoft on 2/5/2013 at 4:13 PM
Thank you for your feedback. We are able to reproduce this issue and are fixing it in Visual Studio 2012 Update 2 release that is scheduled to be released in the end of March.
Many customers have found it useful to discuss issues like this in the forums ( where Microsoft and other members of the community can suggest workarounds.  Please keep the feedback coming.
The Windows Forms Team
Posted by Olivier Dagenais on 1/10/2013 at 8:57 PM
I have independently arrived at the same conclusion by looking at the MSBuild task and seeing that the .NET 4.0 version generates a SHA1 hash, while the .NET 4.5 version generates a SHA256 hash.

We worked around this defect by signing the package files with a code-signing certificate, bypassing the [now-broken] hash verification.

Ideally, setup.bin would be updated with a hotfix/service pack to verify hashes with the same algorithm used to build the SETUPCFG resource, i.e. SHA256.
Posted by Its Andrew on 1/10/2013 at 2:27 PM
It looks like framework 4.5 uses SHA256 to store each prerequisite hash code for further validation but during the installation it continues to use SHA1 to obtain hash for each prerequisite on disk and then compare SHA1 and SHA256 results. No wonder they differ.
I did this research by reading hash code from setup files created with 4.0 and 4.5 frameworks and comparing them with hash codes I created by myself using System.Security.Cryptography.SHA1 & System.Security.Cryptography.SHA256
Posted by Its Bryan on 1/9/2013 at 10:28 AM
The SHA1 Hash included in the Setup.exe is different after .net 4.5 is installed. We examined the hash included in an earlier Setup.exe and it was a 20 byte value which matched our calculation of the hash. Bootstrappers built with .net 4.5 installed had a longer hash that did not resemble the 20 byte hash.
Posted by Microsoft on 8/20/2012 at 11:27 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 8/20/2012 at 3:53 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(