none
Problem with Visual Studio 2008 Installer Bootstrap (setup.exe)

    Question

  • I have a Visual Studio setup project that utilizes the Prerequisites installer bootstrap (setup.exe) which I have migrated to VS 2008.  I use Winzip Self Extractor to package the setup.exe and .msi into a single downloadable .exe file for my customers, they just run my .exe and it unpacks and kicks off the setup.exe generated by visual studio.

    I just noticed that after the upgrade to VS08, that setup.exe behaves a bit differently and my WinZip approach no longer works.  What used to happen is the setup.exe would stay running until msiexec had completed the installation and WinZip would simply wait for the setup.exe to exit before deleting the temporary extracted files.  Now, though, setup.exe exits immediately and doesn't wait for the msi to be installed so Winzip Self Extractor deletes the msi file (thinking it's done).

    What can I do about this?  I'm thinking of taking my old setup.exe file and using that with the 08-generated msi, or just ditching altogether the vdproj.  Are there any command line flags I can send setup.exe to have it behave in the same manner as before?

    Is there any documentation regarding the change I've run into?
    Saturday, February 02, 2008 6:41 PM

All replies

  •  

    I am seeing this exact same problem myself and wound up here after doing a search for the problem.  WinZip self-extractor worked fine with the setup.exe and .msi file under VS 2005 but now fails with either a missing .msi file or a random error that the administrator has disabled setup through a policy setting.  Running the self-extractor a second time and the policy error does not happen.  Also, if I open the a ZIP version of the file in ZIP viewer mode and click on setup.exe it works fine.  Something has changed but exactly what I have no idea.
    Monday, February 11, 2008 4:43 PM
  • Yep, I think all that has changed is that setup.exe no longer waits for msiexec to complete its task and just immeditely shuts down after the pre-requisites check.  That obviously poses a big problem for how Self Extractor does its job - it thinks the installation is complete when setup.exe has returned and starts the cleanup process.

     

    I've had it with the VS Setup Projects.  I'm going to be moving to Advanced Installer for my next release - I've run a few quick tests with it and it provides everything the .vdproj does without these idiosyncrasies and headaches.

     

    Monday, February 11, 2008 4:54 PM
  • Thanks for the heads up on the cause.  Based on that information I decided to poke around a bit to see what I might be able to do to get the old behavior working again and I did have some success with two different solutions.  It turns out the "new" Visual Studio 2008 setup.exe routine is stored in:

     

    \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin

     

    From what I can tell, it is copied to setup.exe in the deployment project output folder.  As I still have Visual Studio 2005 installed, I searched around for other copies of setup.bin.  Low and behold I found the Visual Studio 2005 copy in:

     

    \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Engine\setup.bin

     

    So, just for fun I renamed the v6.0A copy to setup.bin-v6.0A and copied the Visual Studio 2005 copy of setup.bin over to the v6.0A directory.  I built my deployment project and it built without complaining.  I ran my resultant installer through WinZip self-extractor and it worked!  There is a newer 6.1 SDK in beta available for Windows Server 2008 but it is beta and I was not able to get it installed for testing so I do not know if there is a setup.bin in that kit and if it perhaps solves the problem.  My deployment project is not terribly complicated so I think this is why it is working.  I suspect that if I were checking for .Net Framework 3.5 or some of the newer prerequisites that showed up in Visual Studio 2008 and that the new setup.exe can check for, it will fail.

     

    As for the second solution, I decided to review all of the WinZip self-extractor documentation to see if perhaps there is a solution there because setup.exe terminating early is similar to the behavior of some InstallShield projects.  Bingo!  There is a command line option called "-wait".  I added the option "-wait msiexec" before the "-c setup.exe" option and it seems to be working using the v6.0A copy of setup.bin.

    Monday, February 11, 2008 7:28 PM
  • Good work in finding the setup.bin and swapping it out. 

     

    I tried the -wait option myself and had mixed results - because sometimes there can be multiple msiexec.exe's running on the machine and Winzip won't know which it's waiting for.  So I would stay with your first approach on this one.

     

    Thanks for the info,

    Eric

    Monday, February 11, 2008 7:37 PM
  • I found a better and simple solution. In WinZip Self Extractor you must tell self exctractor to wait for the module "msiexec". It then waits for msiexec to complete and not setup.exe.

    This works quite well except when the user manually cancels the installation. You then have to manually close the Self Extractor dialogue, and it will warn you that setup.exe has not yet finished. I don't know why it behaves like this, but this is tolerable, since normally users don't cancel the installation.

    Tuesday, March 25, 2008 6:06 PM
  • Be careful with that msiexec module check. When you run an install there are two copies that are running on the system, one running the UI part and then the MSI service that runs for a lot longer than just the UI part. If you end up waiting for the service executable to finish it'll be a much longer wait.

     

    Tuesday, March 25, 2008 7:15 PM
  •  n2jtx wrote:

    Thanks for the heads up on the cause.  Based on that information I decided to poke around a bit to see what I might be able to do to get the old behavior working again and I did have some success with two different solutions.  It turns out the "new" Visual Studio 2008 setup.exe routine is stored in:

     

    \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin

     

    From what I can tell, it is copied to setup.exe in the deployment project output folder.  As I still have Visual Studio 2005 installed, I searched around for other copies of setup.bin.  Low and behold I found the Visual Studio 2005 copy in:

     

    \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Engine\setup.bin

     

    So, just for fun I renamed the v6.0A copy to setup.bin-v6.0A and copied the Visual Studio 2005 copy of setup.bin over to the v6.0A directory.  I built my deployment project and it built without complaining.  I ran my resultant installer through WinZip self-extractor and it worked!  There is a newer 6.1 SDK in beta available for Windows Server 2008 but it is beta and I was not able to get it installed for testing so I do not know if there is a setup.bin in that kit and if it perhaps solves the problem.  My deployment project is not terribly complicated so I think this is why it is working.  I suspect that if I were checking for .Net Framework 3.5 or some of the newer prerequisites that showed up in Visual Studio 2008 and that the new setup.exe can check for, it will fail.

     

    As for the second solution, I decided to review all of the WinZip self-extractor documentation to see if perhaps there is a solution there because setup.exe terminating early is similar to the behavior of some InstallShield projects.  Bingo!  There is a command line option called "-wait".  I added the option "-wait msiexec" before the "-c setup.exe" option and it seems to be working using the v6.0A copy of setup.bin.

     

    I understand the problem, and I understand the solution (swapping out the setup.exe).

     

    While it's great that this works, it's rubbish that this is an issue, and this isn't a sustainable (or supported) fix. I wonder what the "official" way to do this would be? I've wasted far too much time on this already.

     

    The msiexec idea is a no-go because of the issues with multiple msiexec.exe processes being active most of the time.

    Tuesday, April 22, 2008 12:05 PM
  • I have discovered the same problem and found the only reliable solution was to revert back to the VS2005 setup.bin solution stated above.

     

    This is a very tricky problem to test due to the fact it's a timing issue. I first found the problem on Windows Vista. However it would only fail when I copied my setup to the local drive. If I ran the same setup from a shared network drive, then it worked everytime.

     

    Once I'd worked out what was going on (setup.exe not wait for msiexec to complete), I tried the -wait option. This seemed to work reliably on both Vista and XP. However as soon as I gave a beta tester the setup, it failed immediately. Why - because I was doing all my testing in VMs. As soon as he ran the setup on a real PC, the timing changed and it failed.

     

    I then ran the setup on my dev PC (only to the point of beginning the install). Although the install came up ok, if I waited several seconds, the WinZip self-extractor would exit, even though there were 3 instances of msiexe running on my PC at the time.

     

    Conclusion: While -wait msiexec seems like the correct approach, it just doesn't work.

     

     

    Tuesday, June 24, 2008 11:24 AM
  • I ended up switching to NSIS, a free open-source installer system. It took about 2 days to completely switch, start to finish, including learning the NSI scripting language, with a much better end result.

     

    I will never use the setup projects in Visual Studio again in their current form, and I strongly encourage others to take a look at NSIS.

    Tuesday, June 24, 2008 11:29 AM
  • I agree! I've got this on my todo list. The Visual Studio setup projects have caused me a lot of pain. I'm going to make a promise to myself to evaluate and choose a new installer for the next release. Everyone who has used NSIS seems really happy with it, so it's going to be at the top of my list. Another tool I've heard that is quite powerful is wix. However I think this is just another way of configuring MSI, so I think the first question should be what does MSI give me that an alternative engine such as NSIS doesn't?

     

    Tuesday, June 24, 2008 11:44 AM
  • You'll be very happy once you have ditched the Visual Studio setups - they shouldn't take as much work as they do with Visual Studio!

    I have been extremely happy with a product called Advanced Installer, while it isn't free it doesn't cost an arm & a leg and it Just Works.

    Tuesday, June 24, 2008 11:49 AM
  • Thanks for the recommendation. I'll add it to my list to evaluate. It certainly seems to have all the features I need and like you say, it's realistically priced.

     

    Cheers.

     

    Tuesday, June 24, 2008 12:04 PM
  • I have the exact same problem with Installshied.  It started when I stared using version 12 Which must contain the same setup.exe that does not wait as the VS installer project. I guess I'll have to try to use the older setup.exe to get past this for now, but I am not happey with this as it is unspported and may not work forever.

     

     

    Monday, June 30, 2008 2:38 PM
  • The fix suggested in this thread won't work for InstallShield - it is specific to the way Visual Studio builds setup projects.

    Monday, June 30, 2008 2:41 PM
  • I agree it wont owrk with Installshield. I am thinking I could try using the Setup.exe (the older one from Installshield 10.5) with installshield which might work, but that wont help mw know since I am trying to do an uninstall programmatically and the "bad" setup.exe has already been shipped to our customer. At this point I have no options. I love the way these files just change and break working code. I dont know who is responsible for this, but it really sucks. I've tried the /w option and its does not wait. This is not an installshield forum, so I am taking my post there, good luck to all suffering with this.

     

    Monday, June 30, 2008 3:06 PM
  • I have raised this issue on the Microsoft Connect site.  If you have had this issue please go an review my post and add your validation https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=369138

    Hopefully, we can get Microsoft to help us out with an elegant solution!

    BTW - If any of you have found a workaround, you could add that too!
    Monday, September 22, 2008 2:41 PM
  • I think you'll find that the InstallShield  setup.exe has an option to cause it to wait. Setup.exe /SMS .

     

    http://www.appdeploy.com/articles/InstallShield%20Setup%20Parameters.pdf 

     

    Tuesday, September 23, 2008 10:35 PM
  • Thanks for the response Phil.

    I am not (or at least think I am not!) using the InstallShield setup.exe.  I am using the Microsoft Bootstrapper setup.exe.  Were you suggesting that I use
    InstallShield instead?  Or did I miss something?

    --
    Ben Taylor

    Wednesday, September 24, 2008 10:39 AM
  • We are aware of this problem and we are investigating a fix for the next verison of Visual Studio.

     

    This problem arrived because of two things that came together:

     

    We made a change in how MSI's are launched in VS 2008 to ensure that the bootstrapper works correctly with Vista's UAC system.

     

    We haven't considered the self-extracting .exe scenario one of our core scenarios.  We do now!

     

    So, I appreciate the issue report, particularly the connect item.  It will either come to me, or I've already assigned it to our team to work on.

     

    HTH,

     

    Thursday, September 25, 2008 4:49 AM
  • Hi David

     

    Thanks for the clarification, very much appreciated.

     

    Looking forward to the next release of VS, particularly towards full multi-monitor support.

     

    Kind regards

    Tom

     

    edit: the mentions of InstallShield in this thread are red herrings - this has nothing to do with IS.

    Thursday, September 25, 2008 8:54 AM
  • Hi David,

    Thank you for posting this information.

    My understanding was that the new bootstrapper is smarter when it comes to .NET download and install.  Is this correct?  I ask, because I have used the workaround suggested in this post (replacing the latest bootstrapper with the old bootstrapper) but if the new bootstrapper is smarter and will result in quicker download and install for my customers, I would like to use it!  Especially, as my app is going to be migrated to .NET 3.5. 

    So, what I am getting at, is if your team can come up with a decent workaround that means we can use the latest bootstrapper, that would be good! (as I am guessing VS v.Next is not anytime soon...)

    Ben

    PS For some reason alerts on this thread are not working for me.  So responses may be patchy...

    --
    Ben Taylor
    Thursday, September 25, 2008 9:41 AM
  • I have very similar problem with custom installer which contains msi file created by Visual Studio 2008.
    In the past i could invoke WaitForSingleObject to determinate when msi finish installing and launch
    another install procedures. Now everything is broken because msi exits before finishing installing
    like in mentioned WinZip scenario.

    If anybody is curious i am not doing any fancy things, just one CreateProces method to launch
    setup.exe built by VS2008 and then immediately WaitForSingleObject call.
    In VS2005

    this was working like a charm.

    CreateProcess(file_name,args2,NULL,NULL,false,NULL,NULL,NULL,&startup_info,&pi);
    WaitForSingleObject(pi.hProcess,INFINITE);

    Thanks for idea of replacing setup.bin from previous version, it has worked for me but it is a pity that there
    is no more proper way of fixing this problem Sad Waiting for another version of VS is not very encouraging Smile

    Best regards

    Wednesday, November 12, 2008 4:09 PM
  • I had the same issue too. I was trying to package the setup.exe and the .msi into a single installer using IExpress. The workaround was to include an additional .exe in the post install event in IExpress that did nothing but introduce a delay. This seems to be working without any issues so far.

    The .exe for the delay was nothing but a small winforms app:

        static class Program
        {
            [STAThread]
            static void Main()
            {
                System.Threading.Thread.Sleep(3000);
            }
        }

    Wednesday, November 26, 2008 4:05 PM
  • I also stumbled about this problem today since I am using IExpress and VS 2008. Simply adding a Thread.Sleep as suggested by Jojy didn't help because IExpress will still cleanup its temporary files so I included a small in the self-extracting package which lets IExpress wait until the msi setup has completed:

     

    1 // We wait to make sure that the msiexec process has already been launched  
    2 Thread.Sleep(5000);  
    3  
    4 string processName = args[0];  
    5 string installerName = args[1];  
    6  
    7 try  
    8 {  
    9     // use WMI to retrieve the command line  
    10     SelectQuery selectQuery = new SelectQuery(string.Format("select CommandLine, ProcessId from Win32_Process where name='{0}'", processName));  
    11  
    12     using (ManagementObjectSearcher searcher = new ManagementObjectSearcher(selectQuery))  
    13     {  
    14         foreach (ManagementObject wmiProcess in searcher.Get())  
    15         {  
    16             try  
    17             {  
    18                 string commandLine = wmiProcess.Properties["CommandLine"].Value.ToString();  
    19  
    20                 // check whether we got the right process where our installer is contained in the command-line args  
    21                 if (commandLine.ToLowerInvariant().Contains(installerName.ToLowerInvariant()))  
    22                 {  
    23                     // we assume the process id to be numeric. if it isn't we are pretty much out of luck anyway  
    24                     int processId = int.Parse(wmiProcess.Properties["ProcessId"].Value.ToString());  
    25                                       
    26                     Process process = Process.GetProcessById(processId);  
    27                     if (process != null && !process.HasExited)  
    28                     {  
    29                         // wait for the installer to complete  
    30                         process.WaitForExit();  
    31                         return;  
    32                     }  
    33                 }  
    34  
    35             }  
    36             catch (Exception)  
    37             {  
    38                 // fail silently (yes, we do, hehe)  
    39             }  
    40  
    41         }  
    42     }  
    43 }  
    44 catch (Exception)  
    45 {  
    46

    It's more or less a dirty hack (not supporting more than one instance of the specific msi setup plus requiring .NET 2.0 already present). I really hope this gets fixed sooner than VS 2010.
    Monday, February 02, 2009 7:24 PM
  • Let me add a "me too" to this problem.

    I am using IExpress to combine an msi and the msbuild boostrapper into one file (since the bootstrapper apparently doesn't allow embedding the msi itself). Finding out that this solution _should_ work but doesn't is a little frustrating. I hope I don't have to wait for 2010 for a fix, since I am building Installers now...

    Wednesday, February 04, 2009 4:05 PM
  • what is the impact of reverting back to VS2005 setup.bin solution? Does it miss any newly added functionality in VS2008 setup.bin?

    Tuesday, June 09, 2009 8:51 PM
  • Basically the below method creates a copy of the setup files in the temp folder (which will be deleted by the OS in time).  The copy of the files is run so when IExpress mistakenly thinks it has completed the setup, the original files being deleted do not affect the install.

    1) Create a bat file called setup.bat with the following commands, substituting <UNIQUE PRODUCT NAME> for your product name with no spaces:

    MKDIR %Tmp%\<UNIQUE PRODUCT NAME>
    XCOPY . %Tmp%\<UNIQUE PRODUCT NAME> /S /E /Y
    %Tmp%\<UNIQUE PRODUCT NAME>\setup.exe

    2) Use IExpress (not WinZip - type in Iexpress to your Run... command prompt in XP or Vista) to create a package with your setup files.  Include the setup.bat file and set the "Install Program" in IExpress to setup.bat.

    3) <Optional> You can delete the files manually from within your Main() program.  You must tell the code to wait for the install process to finish before doing this.  There is a nice project on CodeProject which instructs you how to do this (it also tells you how to launch your program from the setup program but not appear until after the msi has finished): Go to http://www.codeproject.com/KB/install/Installation.aspx  and do the method in the message (towards the bottom of the screen) "Re: Proper Way to Do This [modified]" by dmbrider at 13:39 on 28 Sep '08.  Simply add the following lines, substituting <UNIQUE PRODUCT NAME> for the same as above after "lineinstallProc.WaitForExit();"

    try
    {
             string instalFileDirectory = String.Concat(Environment.GetEnvironmentVariable("Tmp"), @"\<UNIQUE PRODUCT NAME>");
             if (System.IO.Directory.Exists(instalFileDirectory)) 
             {
                      System.IO.Directory.Delete(instalFileDirectory, true);
             }
    }
    catch(Exception)
    {
             //No problem.  Not important!
    }

    • Proposed as answer by Phylliss Friday, August 14, 2009 6:15 PM
    • Edited by Phylliss Tuesday, August 18, 2009 12:22 PM ORIGINAL POST CONTAINS INCORRECT SOLUTION. CORRECTED.
    Friday, August 14, 2009 6:13 PM
  • Thanks Phylliss!

    Great idea to use the batch file.  It worked perfectly for me.  I don't want to tell you how many hours I spent trying to figure this problem out before I came across this excellent discussion and your suggestion in particular.

    Another relevant thread was:

    http://social.msdn.microsoft.com/Forums/en/windowssdk/thread/73aea060-e8bf-4094-9fa6-0f06d076a22d
    Wednesday, December 30, 2009 1:44 AM
  • Phylliss,

    I tried following your directions, but I ran into an error when I attempted to run the self-extracting EXE on 64-bit Windows 7:

    Error creating process <Command.com /c C:\Users\username\AppData\Local\Temp\IXP000.TMP\setup.bat>.  Reason: The system cannot find the file specified.

    I believe the problem is that this version of Windows no longer includes "command.com" (the Windows 95-era command prompt?). 

    But, I learned on another forum that if you rename "setup.bat" to "setup.cmd" it will work properly because "setup.cmd" will launch with "cmd.exe" (the Windows NT command prompt).


    Thank you for including your instructions, I would not have learned of "IExpress" without your help.
    Friday, November 12, 2010 10:13 PM
  • Thanks MikeW-d.  I had the same error as you (about command.com and "cannot find the file specified").  Your solution to simply rename the setup.bat file to setup.cmd worked for me.
    Tuesday, March 29, 2011 3:08 AM
  • Is there any resolution to this using WinZip to merge the setup.exe and setup.msi files?

    I can't use IExpress, because it apparently won't include folders in the zip file, which I need to include the setup files for SQL Server Express, .NET Framework, etc. 

    What a pain.


    bill
    Wednesday, May 18, 2011 4:40 PM
  • We are aware of this problem and we are investigating a fix for the next verison of Visual Studio.

     

    This problem arrived because of two things that came together:

     

    We made a change in how MSI's are launched in VS 2008 to ensure that the bootstrapper works correctly with Vista's UAC system.

     

    We haven't considered the self-extracting .exe scenario one of our core scenarios.  We do now!

     

    So, I appreciate the issue report, particularly the connect item.  It will either come to me, or I've already assigned it to our team to work on.

     

    HTH,

     

    What happened, Dave?

    bill
    Wednesday, June 01, 2011 1:48 PM
  • Thanks so much n2jtx for providing this work around.  I don't know how I would have ever found it otherwise!
    Monday, July 22, 2013 7:38 PM