How to detect what .NET Framework 1.1 service pack is installed
I have seen a few questions on the newsgroups about how to determine whether or not the .NET Framework 1.1 SP1 is installed on your machine. A colleague pointed me to a KB article that describes a method of looking at file versions to determine this. We created a new registry hive that started getting installed in the .NET Framework 1.1 specifically to address this and a few other types of detection issues and make this simpler for 3rd party developers, so I wanted to quickly outline how to check for this in the .NET Framework 1.1 and new versions moving forward (it will take a bit for my request to have that KB article updated to go into effect on the live KB site).
Basically you need to query for the existence of a registry value and then check the data in that value. Here is where it is located:
- Key Name: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322
- Value: SP
- Data type: REG_DWORD
The data in this SP value tells you which service pack is installed for the .NET Framework 1.1. For future versions of the .NET Framework, you will just need to change the part of the key named v1.1.4322 to be the version you are interested in.
Note that this method cannot be used to tell you whether or not you have any QFE's or GDR's installed for the .NET Framework. If anyone out there needs to be able to detect on this granular of a level, let me know via a comment or email and I can dig into this further.
There are also other alternative ways of detecting the presence of the .NET Framework 1.0 service packs, I will post something about that when I figure out the exact details of how to do that.
Hope this helps....
Comments
Anonymous
September 14, 2004
Aaron - I was always frustrated by the methodology of determining the version of the .NET framework(s) that are installed. The KB article doesn't help that much if you are trying to programatically determine the version. Worst of all, for each release of the framework, I need to rewrite the detection code. It would be nice if you or Microsoft provided a C++ sample that will return the appropriate installed versions that is somewhat future-proof.Anonymous
September 14, 2004
MeThink you should explain how to take advantage of the IE user agent string when possible. Combined with the download page of some website, it can provide a more transparent experience.Anonymous
September 14, 2004
Thank you for the feedback so far. I like the idea of a code sample - I need to do a bit more research on methods of detecting 1.0 SPx before I can code that up, but stay tuned.
Stephane - can you clarify what you mean by taking advantage of the IE user agent string in your comment?
Thanks!Anonymous
September 14, 2004
Thanks, Aaron, that would be great to get a sample together!Anonymous
September 14, 2004
Is there a KB article about "How to detect WHY the .NET Framework 1.1 service pack is NOT installed"?
That TargetInvocationException during installation is really annoying... :-(Anonymous
September 14, 2004
http://blogs.msdn.com/ie/archive/2004/09/02/224902.aspx
When the .NET run-time is installed, IE6 is updated and it appends whatever is found in the following registry key, in the user agent string of every single web request : HKLM/Software/Microsoft/Windows/CurrentVersio/Internet Settings/5.0/User Agent/Post PlatformAnonymous
September 14, 2004
The comment has been removedAnonymous
September 15, 2004
Michael - I am sure this is possible. I believe System.Environment.Version gives you this.
Stephane - I think relying on the User Agent string is a bad idea. Some people change this string using various tweaks to hide (or change) their browser version and its capabilities.Anonymous
September 16, 2004
There are APIs within the .NET Framework to detect what its own version is, and that can be useful in some scenarios. If you are writing a setup that is trying to bootstrap the .NET Framework, it is likely not going to work to try to make a managed code API call to detect .NET Framework version. Also I wouldn't recommend writing a setup in managed code due to the additional complexity and possible points of failure.Anonymous
September 16, 2004
"Some people change this string using various tweaks to hide".
I think this is a ridiculous statement. The 0.01% people who purposedly do this get what they deserve. All others are provided a better user experience with the website able to redirect the user to a proper page, not a default one.Anonymous
September 19, 2004
Hi Stephane,
>I think this is a ridiculous statement.
It certainly sounds that way, but it can be a means of exploit reduction. If I browse with a Firefox string, I can be served up a different exploit than browsing with an IE string. But corner-cases aside, I was referring to detecting the .NET runtime for a setup application, and I would prefer to rely on a 100% method of detecting the available versions, not 99.99%. For web site detection, this is all you have to go on, and yes, people who change it deserve what they get.Anonymous
September 20, 2004
"and I would prefer to rely on a 100% method of detecting the available versions, not 99.99%".
No pun intended, but I think you need to take a look at web deployment a bit more. By reading what you say I have that feeling you haven't been doing too much of that install-from-the-web thing.
Let's get to the point : the first impression from your audience -- potentially customers -- are your web pages, and your setup. It had better be appropriate.
By being not only appropriate, but even to the point, you are setting yourself well. A seamless .NET detection minimizes the amount of round-trips, default cab and msm modules.
Even more, a seamless .NET detection reduces the amount of clicks between your home page and the user actually installing the software.
Sum up all the benefits mentioned in this thread, and compare with the ol' way of doing things.Anonymous
September 22, 2004
Stephane, I have done web deployment. Thanks for reminding me of the web deployment pain! I am in complete agreement on your methodology.
I was guilty of writing an ActiveX control to determine if I should send someone to a simple msi download or an exe that contained the MSI redistributable for their OS. It is important to conserve as much of your potential or paying customer's 56k bandwith as possible, especially in the old days, by giving them what they need to get going and nothing more.
Using your example of looking at browser strings, for the most part (today) this gives me the information I need to know - if the user is XP or 2k, I know they have the MSI runtimes and can behave appropriately. As you stated, it is great for .NET applications, since this works across the board.
Firefox browsers don't help you determine anything - nor do they support ActiveX, so they are left with less automatically determined options. Same with people who muck with their user agent strings. In those cases, I would expect the user knows what they are doing and give them a variety of download options.
My (limited) point of view above was from that of a customer with a CD in their drive and/or a tiny web download bootstrapper application. In those situations, I wouldn't look anywhere near the browser string.Anonymous
September 23, 2004
I came across an excellent example that shows how to determine what editions and service pack level of the existing Microsoft .NET Framework is installed. Unfortunately for most of my readers, this code was in C . I've converted the code to VB.NET for everyone to benefit ;-)Anonymous
June 29, 2005
Hey all,
In response to some suggestions from folks who read my blog posts describing how to detect...Anonymous
July 12, 2005
Does anyone have a table or can point me to a link listing .Net versions and their corresponding service packs? I haven't seen one previously.Anonymous
July 12, 2005
Hi Jason - I wrote up a table listing these versions, you can find it at http://blogs.msdn.com/astebner/archive/2005/07/12/438245.aspx. Hope this helps. Let me know if you have any questions.Anonymous
September 02, 2005
I have 1.1 installed on my machine (XP SP2). However, the registry key is totally diferent. Any idea?Anonymous
September 02, 2005
Hi Vlad - this registry info for .NET 1.1 on XP SP2 should be the same as I describe above. Can you let me know what the registry looks like on your machine and I can try to figure out what is going on?Anonymous
March 20, 2007
PingBack from http://blogs.msdn.com/astebner/archive/2005/07/12/what-net-framework-version-numbers-go-with-what-service-pack.aspxAnonymous
July 20, 2007
PingBack from http://blog.lowesoftware.com/software-development/detecting-installed-microsoft-net-framework-clr-version-information