Restart after installing a prerequisite?

Question

Hello,  I have a click-once deployment which installs .Net3.5 SP1 if it's missing, then my product.

I'm observing the following behavior: after clicking the install button in publish.htm the user is prompted to install the framework bits and at the end, prompted to reboot the machine. If the user reboots, the browser does not reopen and the install does not resume. (in other words, the user needs to know to go back to the web page and click the install button again)

Is this an expected behaviour or am I doing something wrong? I know this is confusing to users and I could write a README, but I'm hoping I did the setup wrong

Answer 1

 

Hi yanak,

In fact, after installing .Net Framework doesn't need to reboot system, We have test it on Windows XP/2003, it can finish install .Net Framework and begin to install ClickOnce application.

The reboot action occurred when the system file currently is in use and your installation process is trying to replace it, then it will require reboot. It's hard to know which system file is in use and require replacement. But after you reboot your computer, it won't reopen the IE with the ClickOnce URL navigated. This is a system action.

Sincerely,
Kira Qian

---

Please mark the replies as answers if they help and unmark if they don't.

Answer 2

If the setup.exe bootstrapper detects that a reboot is required, then it will write a regkey in the runonce key, and should restart after rebooting.

If it's not, I'd start looking at the install.log and seeing that it set the restart info, and that it restarted.  The install.log file is found in a vsd* folder under the temp folder.  Look for the most recent instances of those folders.

The one thing that could be happening is that the setup.exe is launching, and is trying to launch the ClickOnce app before ClickOnce is up and running.  I'd be a bit surprised, since I don't think ClickOnce is a windows service that needs to be started, but it's something worth looking at.

 

David Guyer

Program Manager - Setup Projects and Bootstrapper.

---

David Guyer - Deployment Technologies Group PM

Answer 3

I'm getting this same problem when installing .Net 3.5 SP1 as a pre-requisite from a Visual Studion 2008 deployment project. From our testing we get the following results:
1. If the machine has no .Net installation of any version then the restart dialog gets launched but the installation proceeds and we can wait until the full installation of our product has finished before addressing the restart dialog.
2. If any older version of .Net exists on the machine, then the installation procedure stops once .Net3.5 SP1 has completed and requests a restart. If you accept the restart, then the machine reboots but the installation does not proceed. If you tell the dialog to restart later, even then the installation does not proceed. If the installer is run for a second time then it all works as expected.

This occurs when the .Net installation is included with the setup.exe, or if it is specified to be downloaded from Microsoft's server. I haven't checked the log files as advised above yet because we re-ghost our test machine regularly, but this does seem to be a problem with the .Net 3.5 SP1 installation.
There do seem to be some proposed solutions to this problem on other forums but they are based around suppressing the restart functionality and don't appear to be trivial when using the Microsoft bootstrapper.

Has there been any more research into this? I'd really like a better solution than having to ask our customers to run the installer twice.

Answer 4

Hi again, I reproduced my problem (described above) and followed David's advice above and went through the installation log file.
It turns out that the flags were all set correctly to restart the installation following the restart, but this failed because the msi file was being run from a network location. I'm guessing that Windows had not fully established its network connections before it attempted to restart the installation.

Provided we require our installation to be run locally this is not a problem. Thanks for the help.

Answer 5

I'm glad this is OK for you.  I'll work with the team to get a bug logged to try to handle the network availability issue better.  I'm confident we have done testing in that scenario, but there are so many variables it could have worked on test machines and still be machines out there that take longer to spin up.  (We do have oldish/slowish test machines, they are not powerhouses, I assure you! :-) )

David Guyer
Program Manager - Deployment Technology Group

---

David Guyer - Deployment Technologies Group PM