Share via

How to manage reboots when deploying the .NET Framework

  • Article

One of the common questions I get from customers who are trying to redistribute the .NET Framework with their setup package is how to handle reboots that might happen during .NET Framework setup. I'll try to address the various questions I've seen so far in this blog post.

When does .NET Framework setup require a reboot?

The .NET Framework setup will require a reboot when one of the files it needs to install is in use during installation. There are a handful of files that are shared by all versions of the .NET Framework, so if there is an earlier version of the .NET Framework installed on the system than the one that is currently being installed, and a managed application is running and holding one of the shared files in use, then a reboot could be required at the end of installation.

How can I tell if .NET Framework setup requires a reboot?

The .NET Framework setup will return code 3010 if it detects that a reboot is required in order to complete installation. It will return this code if .NET Framework setup is run in full UI mode, unattended mode or silent mode.

Can I defer the reboot if the .NET Framework setup returns code 3010?

In general, it is safe to defer a reboot required by the .NET Framework until the end of your setup process. This means you can install the .NET Framework and your application in a single setting and then reboot afterwards if the .NET Framework setup returned 3010. You can also install the .NET Framework and a .NET Framework hotfix and defer the reboots until after your product setup completes.

You should not defer the reboot indefinitely, however. You may see unpredictible behavior in your application if it is attempting to run on top of a version of the .NET Framework that needed a reboot at the end of setup and the reboot has not yet happened.

How can I force a reboot during .NET Framework setup to make sure my setup it will handle it correctly?

Because of some work done in the .NET Framework 2.0 setup, it can be difficult to create scenarios where .NET Framework setup returns error code 3010. However, it is necessary to create reboot scenarios in order to test the code paths in your setup program that are designed to handle these reboots.

The most reliable way I have found to test reboot scenarios is to do the following:

  1. Install an earlier version of the .NET Framework than the one you are including in your setup package. For example, if you are going to redistribute the .NET Framework 2.0, then install the .NET Framework 1.1 or 1.0.
  2. Use a tool to lock one of the files for writing that was installed to %windir%\system32 by the previous version of the .NET Framework installed in step 1. I have been using a tool written by a fellow Microsoft employee named lock.exe (you can download it here). This tool provides a graphical user interface that lets you specify the type of lock to place on a file. For this type of reboot testing, you can use the write lock (number 3 in the lock.exe UI).
  3. Run your setup and let it install the .NET Framework while the files are held in use by the tool from step 2. Verify that your setup handles the 3010 return code the way you intend it to.

Note - make sure to not use read/write locks (number 4 in the lock.exe UI) to test reboot scenarios. If you try to do that, you will receive an error message with the following text, and the only options are to retry or cancel.

---------------------------
Microsoft .NET Framework 2.0 Setup
---------------------------
Error 1306.Another application has exclusive access to the file 'C:\WINDOWS\system32\mscorier.dll'. Please shut down all other applications, then click Retry.
---------------------------
Retry Cancel
---------------------------

Unfortunately, you cannot ignore this error and have setup continue. If you try to force one of the .NET Framework shared files to be in use by opening the DLL in Microsoft Word, you will see this error as well because it opens the file for read/write access.

Summary

Hopefully this post has addressed any questions you might have about how to handle reboots during .NET Framework setup in redistribution scenarios. Please let me know if you see anything that I've missed....

<update date="7/23/2009"> Fixed broken link to lock.exe. </update>

Comments

  • Anonymous
    June 13, 2006
    PingBack from http://blogs.msdn.com/astebner/articles/574618.aspx

  • Anonymous
    July 02, 2006
    I have gotten several questions in the past from customers who need to install the .NET Framework 2.0...

  • Anonymous
    July 10, 2006
    The comment has been removed

  • Anonymous
    July 18, 2007
    The comment has been removed

  • Anonymous
    April 09, 2012
    what are the file we can lock to simulate reboot while installing .net 4.0

  • Anonymous
    April 10, 2012
    Hi Sid - You can simulate this type of reboot scenario by locking %windir%system32mscoree.dll (and also %windir%syswow64mscoree.dll if you're installing on a 64-bit OS).

  • Anonymous
    June 17, 2012
    Hi Aaron, I used lock.exe to force a write-lock (#3) on %windir%system32mscoree.dll and %windir%syswow64mscoree.dll. I then ran the .NET 4 installer on a Windows 7 x64 machine that didn't previously have .NET 4 installed. I was hoping to be prompted to restart but I wasn't. Are there any other files that I should lock?

  • Anonymous
    June 18, 2012
    Hi Mark Ingram - I would've expected that to work, but maybe a write-lock isn't aggressive enough.  What I usually try when nothing else seems to work is to open mscoree.dll in Microsoft Word.  I'm not sure what lock that ends up using, but I haven't ever seen a case where that didn't trigger a reboot prompt during .NET Framework setup.

  • Anonymous
    October 08, 2012
    Hi Aaron, Can you please help me to find out whether machine reboot completed or not (in case dot net frame work installation requires reboot).

  • Anonymous
    October 09, 2012
    Hi VenkataRaja - I don't know of a reliable way to detect whether or not a reboot requested by .NET Framework setup has been completed.  I've seen installers in the past try to use registry-based detection logic for this, but they ran into cases where registry keys that indicated a pending reboot would get stuck on the machine.  In those cases, their installers would continually tell users that a reboot was needed, even after a reboot had just been completed.

  • Anonymous
    November 15, 2012
    Check the event log for an entry from the event log itself.  It will show the last time the server was rebooted.