About Windows Installer, the .NET Framework, and Visual Studio.
No doubt you've heard the Microsoft .NET Framework 3.5 was released. Aaron Stebner has posted a list of links to 3.5, as well as 2.0 Service Pack 1 (SP1) and 3.0 SP1. It's important to note that if you install 3.5 you're actually getting 2.0 SP1 and 3.0 SP1 both.
The .NET Framework 3.5 consists of the following:
While 2.0 SP1 and 3.0 SP1 are actually full major upgrades that will replace older versions if installed, they update the SP detection keys as documented previously. The registry detection keys we introduced in .NET Framework 3.0 and Visual Studio 2005 will not work for 2.0 SP1 and 3.0 SP1, unfortunately, until at least one patch is installed that will add them in. If you're using the NetFxExtension with WiX, however, to add the AppSearch property NETFRAMEWORK20_SP_LEVEL or NETFRAMEWORK30_SP_LEVEL you'll be fine. These use the older detection keys that will continue to work as documented.
so you have released .NET 2.0 SP1.
But how can you call it RTM (Release To Manufacturing) if I can't even say RTM (Read The Manual) becuase there is no such manual?
I just can't find any document which describes what hotfix and changes got into this SP.
I have seen multiple requests for this information over blogs and groups.
Can you point me to such document?
In the mean time, I have created a list of all .NET 2.0 hotfixes i have found:
1. I am being offered KB932471 repeatedly by Microsoft Update after installing .NET 3.5 RTM.
2. As per http://blogs.msdn.com/heaths/archive/2006/12/16/slipstreaming-visual-studio-2005-service-pack-1.aspx, I successfully completed steps 1-3, however I do not have a network and will be installing locally from my HDD. How then do I deploy the slipstreamed Visual Studio? Could you show me the exact procedure to DEPLOY it? I copied the setup bootstrapper, WCU and Setup folders. I was careful not to replace any files. However I am getting "Internal error 25003" when I install from the slipstreamed package, but it installs properly when I install from the original DVD (the one which is not slipstreamed).
someone, regarding #2 you need to install all the pre-reqs separately then install vs_setup.msi using the command line like so:
msiexec /i <slipstream path>\vs_setup.msi /l*vx %TMP%\MSI_VS.log NOVSUI=1
Yonatan and someone, I'll have to get back to you on those other issues.
There is a known issue with the detection logic for the update KB932471 because of which this update is reoffered after you install the .NET Framework 3.0 SP1 or the .NET Framework 3.5. This blog post provides more information about this issue:
I tried deploying but I'm getting "Internal error 25003". According to http://support.microsoft.com/kb/827076, it's related to CD-ROM copy errors but I'm running the setup from my local hard disk. Please help.
I just want to post quick question to make sure I understand this correctly.
Installing 3.5, would give me both 2.0 SP1 and 3.0 SP1, which are full updates of 2.0 and 3.0 respectively, is that correct?
so if I do a clean install, no .net frameworks installed, all I need is 3.5, unless, of course I still want 1.1. am I right?
Thanks in advance!
Glenn, yes, you are right. It works whether you have nothing, 2.0, or 3.0 installed. 1.0 and 1.1 are still separate. 2.0 through 3.5 all run on the 2.0 CLR, though 3.5 has its own set of tools while 3.0 is just extra assemblies.
Yes, it gets confusing here, too.
Where's the release notes for this? Have searched high and low!
At last, Microsoft published the list of fixes in SP1.
See my blog for details: http://readcommit.blogspot.com/2007/12/problems-that-are-fixed-in-net.html
Is it just me the thinks that .NET Framework product group botched the detection process? If you google .NET Framework detection you'll find conflicting KB articles and guidance on how to detect various versions:
I hope that someone in the NETFX product group can go and clean up the mess they have left. Now I'm seeing Microsoft's own products break because they can't manage proper framework detection. The latest victim has been the MBS Dynamics GP 10.0 installation which refuses to install because it says the .NET Framework 2.0 is not installed when in fact it is, along with the Service Pack 1 of the Framework. The setup process once again takes a back seat at Microsoft and it's getting very frustrating for IT professionals around the world having to deal with regular inconsistencies.
Colin, the registry keys that specify "NET Framework Setup" have always been recommended primary approach to detection. They keys that were missed are specific to detecting the Service Pack level. While unfortunate they were changed in SP1, subsequent versions will have the old, correct path again.
I'm not sure how Dynamics detected the framework, but I know I have seen other product groups internally and externally use non-documented, self-discovered ways of detecting the framework. These approaches are not recommended. Some even try loading the latest CLR in a "mini-host" which is another universal way of doing detection but, of course, more expensive as you're loading the CLR.
The challenge is which registry key do we use? Some articles point to the policy key, others the NDP key. KB 315291 and the article I linked to on MSDN are a great example where there are two different ways to detect the .NET Framework 2.0. The article, while it covers up to 3.0, is competing against a KB article that was last updated this month. While one might infer that the registry is the best approach we're still left holding the bag when it comes to which key to check. The risk isn't clear for those of us who can't call up the product group and ask which is why I'm poing out that there needs to be a better way to provide authoritative guidance. It isn't a small task, but there needs to be a better way before we are at version 6.0 and have a smelly code block of if statements checking several locations. We're all fine with a change in methods from version to version, it's more a case of worrying about a moving target that we'll have to hotfix for after the fact.
On the note of the internal product groups it sounds like they could use the guidance too. The Dynamics GP support folks have just asked me to uninstall the .NET Framework 3.0, 2.0, reboot, run their installation package, and then reinstall the service packs. On a machine that is also running SQL Server 2005 and BizTalk Server 2006 that's not a small change. There is at least a day of my time dedicated to a workaround because someone made the wrong call in the development process. Multiply that by other customers who are faced with the same issue and suddenly we're talking many weeks, if not months, of time wasted because of a lack of consistent detection within the company. I'm not sure how you solve it Heath, but it sounds like someone needs to set some guidelines out or throw something into the common engineering practices as to how to best approach detection. Inevitably someone will not follow it and I would think it should be the responsiblity of the product group to treat it as a bug, not ask the customer to uninstall half their system to workaround an error in the program design.
Colin, the "NET Framework Setup" has always existed across platforms and .NET versions and is recommended for simply "Is .NET installed?" queries. Some of the other registry keys like I've documented (and KB content based on) are for more specifics. The SOFTWARE\Microsoft\Updates key is for all servicing products to write to (not all do, mind you) about patches that are installed. So if you're looking for a specific fix across platforms that's the key to check. You'll also find SP level in the "NET Framework Setup" key. The "DevDiv" servicing keys were added in Whidbey to try to have a common path, but those only started with Whidbey and, hence, are recommended for VS.
I've got a lot of specs written over these things that are to help make sure they aren't changed and to inform product groups. Like everything else, though, you have to be looking in the right place. In most cases where detection logic failed it was from people poking around the registry looking for whatever works. Because of differences in installation technology (MSI, OCM, and CMI) across platforms we can't guarantee the same registry keys or even file layout across platforms.
We have just found a (reproduble) bug in xslt processing that didn't occur in 2.0 but does in 2.0 sp1.
Where is the appropriate place to log the bug online?
A reader pointed out that the list of fixes for .NET Framework 2.0 Service Pack 1 were published. I also