Home Dashboard Directory Help
Search

Setup.exe Bootstrapper Execution Lifecycle Changed - Breaks WinZip Self Extracting Installs by BenTaylorUK


Status: 

Closed
 as Fixed Help for as Fixed


20
3
Sign in
to vote
Type: Suggestion
ID: 369138
Opened: 9/22/2008 7:34:46 AM
Access Restriction: Public
5
Workaround(s)
view

Description

It appears that the VS.NET setup.exe bootstrapper lifecycle has changed between VS.NET 2005 and VS.NET 2008. Previously, you could start setup.exe and it would run WHILE the MSI was running with msiexec. AFAIK it would not stop executing until the msiexe process was done. In VS.NET 2008 setup.exe bootstrapper appears to run, do it's work, fire up the MSI and then EXIT immediately.
Details
Sign in to post a comment.
Posted by belgie on 5/31/2011 at 7:30 AM
ExeMsiCombiner did not work for me because I have prerequisites (SQL Server Express, .NET Framework), and when ExeMsiCombiner extracts the setup.exe and .msi files into a temporary folder, the prerequisite setup files are not there and setup.exe fails.
Posted by shakyajones on 5/11/2011 at 10:50 AM
ExeMsiCombiner does have a bug though. When ExeMSICombiner was used to created the install exe for an app, and when there are possibly multiple users who can login to the same machine to run the app, then if any user other than the user who was logged into Windows when the app was installed attempts to run the app, the app blows up – unless the current user (trying to run the app) has admin privileges. This is because the app is trying to find its msi file again and that msi file is stored in a temp directory under the AppData directory of user that was logged into Windows at the time of the install.

When using setup.exe and blah.msi, this problem does not manifest.
Posted by Mike Diack on 4/13/2011 at 7:51 AM
I can confirm that this BUG is still not fixed. I'm running Win 7 SP1, VS2008SP1, VS2010SP1, i.e. about as up to date as possible, yet the version of IExpress in that _STILL_ exhibits this bug even now in April 2011. This basically renders IExpress useless for me - I've had to use batch files with unzip etc instead.

Please, some news on a fix and its availability, Microsoft? It makes IExpress basically unusable.
Posted by Hedgehog on 10/4/2010 at 12:32 PM
There is a solution outlined in the 'workarounds' tab to do with making a helper application that launches setup.exe and waits until the corresponding .msi file has finished executing.

Alternatively, you could try a free tool called ExeMsiCombiner which combines the setup exe and msi files into one exe installer file. At the time of posting, this tool can be downloaded from here: http://www.epav.co.uk/giles/
Posted by hwan1 on 1/31/2010 at 5:49 AM
Visual Studio 2010 Beta 2 are distributed in two ways;(Bootstrapper or "ISO"image)..Bootstrapper problem occurs when the installation is VS2010beta2. The installation itself is a bug, my system is wrong I do not know what happened. My system spec cpu Intel Q6600, ram4GB, operating system, Windows 7 Home Premium K (32bit) was installed.
Posted by LWhitehall on 12/10/2009 at 2:21 PM
While Microsoft states that they have a fix for this, why must everyone wait until Dev10 is released to get the fix. Can't this fix be a service patch for VS-2008?
Posted by DaveWampler on 11/30/2009 at 5:32 AM
Here it is Nov30, 2009, and this problem still has not been fixed. Can anyone tell me why I need the setup file? Can I just run "msie.exe App.msi" to install the the application. Do I need to run the setup.exe program?
Posted by Esther 14 on 10/23/2009 at 9:16 AM
I had the the problem today! I give up for today! My operating system is Win 7 and i have 2010- it was horrible!
Posted by Phylliss on 8/18/2009 at 5:26 AM
My above solution did not work on all computers. Jumped the gun posting it - apologies.

Please see my comments on the following link for a workaround that DOES work:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/3731985c-d9cc-4403-ab7d-992a0971f686/?ffpr=0
Posted by Phylliss on 8/14/2009 at 11:28 AM
I came up with not-very-elegant solution using IExpress - a free alternate to WinZip Self Extractor which is bundled with XP and Vista (just type IExpress in your Run... command prompt). The same problem happens with IExpress too. Here is the workaround.

Basically, I believe the problem arises because setup.exe exits and the installer deletes the msi file before it is loaded. So you just need to delay IExpress from thinking it is finished. To do this: include a bat file in your package and run it in the "Post Install Command". The bat file simply pauses, and as there are no pause commands in DOS you have to create a bat file which reads:

@echo off
ping -n 10 127.0.0.1 >NUL

This pings for 10 seconds, which is long enough for your msi to start. IExpress can't delete the msi once it starts so the msi gets to complete. Not sure if IExpress manages to delete the files after that. And you get an ugly dos window in the background, but hey, I did say it was a less elegant solution.

You could have the ping go for longer until the setup ought to have finished so IExpress would surely delete the files, but if the user hasn't got .Net (for example), it could take 30 minutes or more for it to download from MS as part of the setup routine so you probably do not want to have a DOS prompt for that long as a just-in-case scenario. Anyway, IExpress might manage to delete the files - I can't find them so I do not know. And they could be running from inside tmp files anyway in which case they would be deleted eventually.

Any better ideas please let me know... Or if you can work out how to hide the ugly dos window.
Posted by a2abinc on 4/6/2009 at 7:25 AM
This is a serious issue for us as we are delaying a product release as a result of this issue. A seamless install of our demo version is critical to our success in a non-techical target market. Our customers need to download and run ONE program and everything they need should be installed for them. Waiting for VisualStudio 2010 isn't an option from a market perspective. And we also need .NET 3.5 so the workaround isn't an option for us either.    
Posted by mercedes45 on 3/31/2009 at 7:58 PM
true
Posted by Microsoft on 1/23/2009 at 2:54 PM
Resolved as Fixed in the duplicate bug on 9/10/2008 ... will be in the Dev10 product.
Posted by anupjishnu on 1/2/2009 at 12:31 PM
This creates an issue when working with IExpress too.
Though WinZIp is mentioned here, as it is a Visual Studio issue, it breaks IExpress creates setups too.
Posted by anupjishnu on 1/2/2009 at 12:28 PM
Why is this issue in Resolved state when there has been no resolution as yet?
Posted by Andrew S UK on 11/10/2008 at 1:29 PM
This is also a problem for me - however the workaround suggested does not work as I need to install .net 3.5 and the old setup.exe in VS 2005 does not show a readable EULA for .net 3.5 - do you have another solution or any workarounds?
Posted by Microsoft on 10/2/2008 at 9:29 AM
Thank you for reporting this issue. This has been reported as feedback/connect item 356051. We are investigating and hoping to fix this.
Posted by MarkGladding on 9/22/2008 at 1:18 PM
I have the exact same problem and have used the same workaround as the previous commenter.
Posted by n2jtx on 9/22/2008 at 9:08 AM
This has been a problem for me too. My solution has been to copy the Visual Studio 2005 version of setup.bin to the location where the newer version is located in order to utilize the older behavior. A better supported solution would be appreciated.
Sign in to post a workaround.
Posted by Hedgehog on 10/4/2010 at 12:29 PM
You can write a small windows helper program to solve this problem. The helper program has to run setup.exe (which will run the corresponding msi) and wait until the msi has finished.

The helper program is not a trivial to write, but the psuedo code would be something like this:

1) Run setup.exe and get the process id.
2) If setup.exe returns 0 then we know the msi program has been launched.
3) If so, get the process id of the msi program by searching all active processes until you find the one who's parent's process id matches process id from step 1 (see CreateToolhelp32Snapshot in tlhelp32.h for help on how to do this).
4) Wait for the msi process to exit. A simple way is to keep trying OpenProcess(..., processId) until it returns 0.

Alternatively, you can download a free tool called ExeMsiCombiner, which combines the exe and msi files into one exe installer file. At the time of posting, this can be downloaded from here: http://www.epav.co.uk/giles/
Posted by digucit on 9/25/2009 at 10:24 AM
Disabling the “Windows Installer” service
Rebooting
Posted by gogosonicboom on 8/14/2009 at 2:06 AM
dont install
Posted by göteborg on 5/15/2009 at 11:06 PM
bugar och tackar
Posted by azad123321 on 2/25/2009 at 5:03 AM
d