Answering follow-up questions about .NET Framework 2.0 setup behavior

I posted some instructions earlier this weekend about how to perform unattended installations of the .NET Framework 2.0 redistributable and SDK.  I got a couple of comments with some really good follow-up questions, and I want to address them as a separate post because that will make the answers easier to find than if they were only posted in the comments on the previous post.

Question 1

What is the most common way to have an application install .NET Framework on to a computer along with an application?  Do they typically just include dotnetfx.exe and call that using silent/unattended command-line switches?  Or are there merge modules available that an MSI can include to automatically install the .NET Framework?

Answer 1

There are not merge modules available for any versions of the .NET Framework.  We worked on one for early versions of the .NET Framework 1.0 but it was cut because of some major serviceability issues.  Once a merge module is consumed into another MSI, the bits in the merge module generally have to be serviced using the product code for the MSI that consumes it.  That makes it very difficult for a redistributable package like the .NET Framework because there is not a way of knowing exactly which applications will consume your merge module.  This issue affected SQL MSDE when the slammer virus hit because a lot of applications consumed the MSDE merge module and there were active, vulnerable versions of MSDE that could not be patchable by our standard patches.

If you plan to install the .NET Framework as part of your setup, you can use one of the following options:

  1. Carry dotnetfx.exe with your setup package, and have a bootstrapper that will check for the existence of the .NET Framework on the system and spawn dotnetfx.exe for the user if it is not already installed

  2. Have your setup check for the existence of the .NET Framework on the system and block and point the user to a web site to download and install the .NET Framework themselves if it is not installed.

You will have to weigh the tradeoffs of these options - carrying the .NET Framework results in a larger package size, but also provides a more seamless user experience.  Blocking results in a smaller package size because you don't have to carry dotnetfx.exe, but likely will result in user frustration because they will have to find and install the .NET Framework themeselves before being able to install your product.

Question 2

How will the .NET Framework installer respond if the .NET Framework is already installed on a system?  Is it acceptable for a setup package to skip detecting whether the .NET Framework is already installed and always launch dotnetfx.exe, or should we write code that detects if it is installed first, and then invoke dotnetfx.exe only if necessary?

Answer 2

The .NET Framework setup will run in repair mode if it is already installed.  Despite this, I recommend that your setup package detect whether or not the .NET Framework is already installed and only run the dotnetfx.exe setup package if it is not already installed for the following reasons:

  1. This results in a faster installation for users who already have the .NET Framework installed.

  2. I have seen issues where re-running dotnetfx.exe on a system that already has the .NET Framework plus a service pack installed will result in error messages.  You can see this by downloading and running the .NET Framework 1.1 setup package on a system that already has .NET 1.1 and 1.1 SP1 installed.

Question 3

What is the officially-supported method for detecting whether .NET 2.0 Framework is already installed and the correct version?

Answer 3

The officially supported method of detecting the presence of the .NET Framework 2.0 is to check the following registry key/value:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Net Framework Setup\NDP\v2.0.50727]
Install = 1 (REG_DWORD)

You can take a look at some sample code I wrote to check for the presence of each shipped version of the .NET Framework and the installed service packs (if any).

Question 4

Regarding the three different versions of the .NET Framework 2.0 - is it correct that the Intel 64 version is for Itanium and that the AMD64 version also covers Intel Xeon with 64-bit extensions?

Answer 4

The Intel 64 version of the .NET Framework 2.0 is intended for Itanium systems.  I have not personally used a computer with Intel Xeon hardware with 64-bit extensions.  However, based on the information I found in some quick web searches, it appears to be considered an x64 system.  That means that you can install the AMD64 version of the .NET Framework 2.0 if you are running an x64 OS, and you can install the the 32-bit version of the .NET Framework 2.0 if you are running a 32-bit OS.


Comments (13)

  1. tzagotta says:

    Thanks for the great answers! Very helpful!

  2. John Styles says:

    Hi Aaron,

    this is all very well but this web page seems to suggest that you are not allowed to do silent installs.

    note in particular the text:

    "Note that the redistribution license does not allow the ISV to alter the installation experience of the runtime components (for instance, it does not allow calling the runtime setup applications with the silent option turned on)."

  3. Hi John – You are correct.  I listed the command line parameters above that describe how you can perform an unattended install from a technical perspective.  From a policy perspective, however, ISVs are not allowed to perform silent installations if they include the .NET Framework as a part of their setup package.

  4. tzagotta says:

    Why does the redistribution license have that clause?

    It seems the net effect is to make the installation experience worse for the user who is installing an application that requires .NET 2.0 on a machine that doesn’t already have the framework.  Why should they be forced to run through that wizard also?

    Can this license be changed?

  5. Hi Tzagotta – the primary reason for this clause is to ensure that the license agreement for the .NET Framework is viewed and accepted by the user who installs the product.  We definitely understand the concern regarding simplification of setup wizards and there are some folks looking into ways to simplify this experience while still allowing the license agreement to be accepted.  I apologize for the inconvenience in the meantime.

  6. Tony says:

    Wondering if there is sample bootstrapper code available?  Seems like we need to do the same thing to install WSE 3.0.  It would be nice to see some sort of generic, or sample, bootstrapper install.

    1) check pre-reqs

    2) run exe

    3) repeat 1-2 until all non-merge module pre-reqs are met

    4) launch product install msi (or exe)

    Obviously, I don’t expect "sample" to meet all of our needs, just give use a working outline.

  7. Hi Tony – You might want to look at the Component Installer SDK for some samples for this type of scenario –

  8. Lisa says:

    In question 1, you suggest two methods for handling a.NET 2.0 Framework prerequisite.  Both these methods seem to be handled by using a Visual Studio 2005 setup project.

    I use the VS 2005 setup project for my application.  I can add a Launch condition for the .NET 2.0 Framework.  My resulting MSI file will post a dialog indicating the requirement, ask the user to continue, and then install it from the location I provide (e.g. local on my CD or from a web site).  The problem with this is that after .NET is installed, it does not continue with my installer.  The user has to launch my .msi file again to finish the installation.  This will not be apparent to the end-user of my application.

    The VS 2005 setup project also places a setup.exe bootstrap file in my build output directory, along with my .msi file. If setup.exe is run, then the .NET EULA is shown, the user accepts it, .NET is installed, and then my installer is run.  However, the first screen the user sees in this case is the .NET EULA, with the only thing that identifies it as being part of my install is the title bar with "MyApplicationName Setup".  This is not a good first user-experience with my application.  The .NET EULA appears before my welcome screen.

    The installation flow with setup.exe is better, but the UI is worse.  Using the MSI file, it’s clearer to the user what is going on with respect to the .NET install.  Using setup.exe to install, it’s not.  But setup.exe will do the full install and launching the MSI won’t.

    Neither of these install scenarios is ideal.  Is there an easy way to get the best of both worlds, hopefully without have to dive too deeply into editing MSI files, or creating my own bootstrapper.  I attempted to search the web but struggled with good search terms to narrow the results.  I did, however, end up here, and so now I’m hoping you have some info to help me along.

  9. Hi Lisa – You are correct that both of the scenarios offered by the Visual Studio setup/deployment wizard will technically work, but I agree with you that they are less than ideal.  You might want to take a look at the Microsoft Component Installer SDK (located at and see if it meets your needs.  There is also a doc describing how to customize it at

    Unfortunately, there is not a good general-purpose, generic configurable chainer that will meet all scenarios like this.  Unless you have the resources to be able to invest in your own chainer that meets your specific needs, you’ll have to make trade-offs and choose the best of the available options.

    Hope this helps!

  10. vishal says:

    Really your answers have been proven very useful to me for application deployment and Some of the problem that I was facing, I could solve them successfully with the help of this article.

    Thanks a lot

    Shah vishal

  11. Michael says:

    Question for scenario outlined by Lisa "The VS 2005 setup project also places a setup.exe bootstrap file in my build output directory, along with my .msi file." Given we determined that .Net 2 had been installed what would be the way to launch a silent installation for this pair :


    my component.msi

    I played with the parameters but without success.

    >msiexec /i "my component.msi" /jm /qn  /l*v c:msi.log

    brings msiexec windows with parameters

    Is this because msi name contains spaces ?

  12. Michael says:

    /jm seemed to upset it. Works without it.

    >msiexec /i "my component.msi" /qn  /l*v c:msi.log

    Now is there way to launch it silent from setup.exe ? If so , could you please show a command syntax and should I get rid of spaces in  naming my msi file ?

    >setup ?

Skip to main content