Updates for the the .NET Framework 1.1 come in two flavors: One set of packages for 32-bit x86 versions of Windows Server 2003 and a different package for everything else.  Similarly, updates for the .NET Framework 1.0 come in two flavors as well: One set of packages for Tablet PC and Media Center editions of Windows XP, and a different set of packages for everything else.  Confused?  You're not alone.  I'll try to help.

What happened?  To understand this you first need to understand that the .NET Framework is a Windows component that shipped well after many versions of Windows that it targets.  For example, Windows XP shipped in 2001 but the first version of the .NET Framework (1.0) shipped in 2002.  All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework.  We call these .NET Framework installations "OCM" installs because they are installed using the Windows Optional Component Manager.  (This is the same OCM technology behind the Add/Remove Windows Components functionality in Add/Remove Programs in the Windows Control Panel.)  But what about Windows XP Home and Professional?!  Or Windows 2000, NT4, or 9x/ME for that matter?  We want .NET Framework applications to run on these downlevel platforms as well, so in addition to the OCM installations of the .NET Framework we also released the exact same .NET Framework as "redistributables" using the Windows Installer (AKA: "MSI") installation technology.  This seemed like a great solution for a while: The .NET Framework goes everywhere that Windows goes and everybody is happy.  Not quite.

The problem with this solution is that now we are required by the technologies (MSI and OCM) to service each of these two broad classes of .NET Framework installations differently.  That is, we need different update packages for OCM than we need for MSI, even for the same logical fix!  This isn't a terribly difficult thing to accomplish technically: We just need to do the same thing twice, once for OCM and once for MSI.  But it's not so hot for our customers (you guys) who need to translate all this for your systems: You don't need the same fix twice; you need one of two fixes once.  "Let's see: Security Hotfix KB123456 was just released.  Do I want the 'Security Update for the .NET Framework (KB123456)' or do I want the 'Security Update for the .NET Framework on Windows Server 2003 (KB123456)'? And does it matter that this is for my x64 or Itanium servers?" (It turns out that it does.)

I said earlier that "All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  Well, this was an overstatement.  More correctly, "All 32-bit x86 versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  To date, our x64 and Itanium versions of Windows have not shipped with the .NET Framework built-in and are therefore considered MSI.  Sorry for the confusion.

(Side-note: It probably sounds redundant to refer to "32-bit x86".  The rationale here is that the x64 architecture is a superset of x86 and therefore simply referring to "x86" would be ambiguous.  Further, "32-bit" could refer to any number of processor architectures, so neither "32-bit" nor "x86" alone would suffice.  Therefore, for precision, we say "32-bit x86" to refer to all those "mainstream" 32-bit x86 boxes out there.)

There's a tabular answer to the question of which version of the .NET Framework your system has: The .NET Framework version that you have depends on two factors: (1) the operating system edition that you are running (including its target processor architecture: 32-bit x86, x64, Itanium), and (2) the version of the .NET Framework that you want to update. Your system is considered "MSI" unless it is specifically targeted as "OCM". Here it is in tabular form:

Please note the following details for .NET Framework support on 64-bit platforms:

• .NET Framework 1.0 is not supported on 64-bit platforms at all.
• Windows XP for Itanium is not supported at all (though Windows XP for x64 platforms is supported).
• Support for Windows Server 2003 for Itanium requires Windows Server 2003 Service Pack 1.
• Use the 32-bit .NET Framework 1.1 redistributable (MSI) on supported 64-bit platforms.  There are no 64-bit native versions of the .NET Framework 1.1. 
• .NET Framework 2.0 is compiled natively for each supported processor architecture.
• It is possible to run a 32-bit x86 version of Windows on an x64 hardware system.  In this case, use the table row for your 32-bit x86 version of Windows.

We usually market OCM updates using the names of their target operating systems.  For example, "KB123456 for Windows Server 2003" means that it is a .NET Framework 1.1 OCM update.  Similarly, "KB123456 for Windows XP Tablet PC and Media Center Editions" is a .NET Framework 1.0 OCM update.  Also, we usually market MSI updates using the name of its target .NET Framework versions.  For example, "KB123456 for the .NET Framework 2.0" is an MSI update.

The good news is that we are learning our lessons and we are not making the same mistakes again.  Without giving too much away, I think it's safe to say that Windows Vista will come with the .NET Framework built-in but there will not be any need do this OCM vs. MSI mumbo-jumbo.  In other words, we're cleaning things up a bit.  But we cannot go back and change the past: What you see above is what we've got for these .NET Framework versions and these operating systems.  We just plan to do it better next time.

Hope this helps!

Updates for the the .NET Framework 1.1 come in two flavors: One set of packages for 32-bit x86 versions of Windows Server 2003 and a different package for everything else.  Similarly, updates for the .NET Framework 1.0 come in two flavors as well: One set of packages for Tablet PC and Media Center editions of Windows XP, and a different set of packages for everything else.  Confused?  You're not alone.  I'll try to help.

What happened?  To understand this you first need to understand that the .NET Framework is a Windows component that shipped well after many versions of Windows that it targets.  For example, Windows XP shipped in 2001 but the first version of the .NET Framework (1.0) shipped in 2002.  All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework.  We call these .NET Framework installations "OCM" installs because they are installed using the Windows Optional Component Manager.  (This is the same OCM technology behind the Add/Remove Windows Components functionality in Add/Remove Programs in the Windows Control Panel.)  But what about Windows XP Home and Professional?!  Or Windows 2000, NT4, or 9x/ME for that matter?  We want .NET Framework applications to run on these downlevel platforms as well, so in addition to the OCM installations of the .NET Framework we also released the exact same .NET Framework as "redistributables" using the Windows Installer (AKA: "MSI") installation technology.  This seemed like a great solution for a while: The .NET Framework goes everywhere that Windows goes and everybody is happy.  Not quite.

The problem with this solution is that now we are required by the technologies (MSI and OCM) to service each of these two broad classes of .NET Framework installations differently.  That is, we need different update packages for OCM than we need for MSI, even for the same logical fix!  This isn't a terribly difficult thing to accomplish technically: We just need to do the same thing twice, once for OCM and once for MSI.  But it's not so hot for our customers (you guys) who need to translate all this for your systems: You don't need the same fix twice; you need one of two fixes once.  "Let's see: Security Hotfix KB123456 was just released.  Do I want the 'Security Update for the .NET Framework (KB123456)' or do I want the 'Security Update for the .NET Framework on Windows Server 2003 (KB123456)'? And does it matter that this is for my x64 or Itanium servers?" (It turns out that it does.)

I said earlier that "All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  Well, this was an overstatement.  More correctly, "All 32-bit x86 versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  To date, our x64 and Itanium versions of Windows have not shipped with the .NET Framework built-in and are therefore considered MSI.  Sorry for the confusion.

(Side-note: It probably sounds redundant to refer to "32-bit x86".  The rationale here is that the x64 architecture is a superset of x86 and therefore simply referring to "x86" would be ambiguous.  Further, "32-bit" could refer to any number of processor architectures, so neither "32-bit" nor "x86" alone would suffice.  Therefore, for precision, we say "32-bit x86" to refer to all those "mainstream" 32-bit x86 boxes out there.)

There's a tabular answer to the question of which version of the .NET Framework your system has: The .NET Framework version that you have depends on two factors: (1) the operating system edition that you are running (including its target processor architecture: 32-bit x86, x64, Itanium), and (2) the version of the .NET Framework that you want to update. Your system is considered "MSI" unless it is specifically targeted as "OCM". Here it is in tabular form:

Matrix of .NET Framework installation technologies by operating system

Operating System	.NET Framework 1.0	.NET Framework 1.1	.NET Framework 2.0
Windows 95/98/ME, NT4, 2000	MSI	MSI	MSI (x86 package)
Windows XP Home, Professional	MSI	MSI	MSI (x86 package)
Windows XP Tablet PC Edition	OCM	MSI	MSI (x86 package)
Windows XP Media Center Edition	OCM	MSI	MSI (x86 package)
Windows Server 2003 (32-bit x86)	MSI	OCM	MSI (x86 package)
Windows XP 64-bit Edition (x64)	Not Supported	MSI	MSI (x64 package)
Windows Server 2003 (x64)	Not Supported	MSI	MSI (x64 package)
Windows Server 2003 SP1 for Itanium	Not Supported	MSI	MSI (IA64 package)

Please note the following details for .NET Framework support on 64-bit platforms:

• .NET Framework 1.0 is not supported on 64-bit platforms at all.
• Windows XP for Itanium is not supported at all (though Windows XP for x64 platforms is supported).
• Support for Windows Server 2003 for Itanium requires Windows Server 2003 Service Pack 1.
• Use the 32-bit .NET Framework 1.1 redistributable (MSI) on supported 64-bit platforms.  There are no 64-bit native versions of the .NET Framework 1.1. 
• .NET Framework 2.0 is compiled natively for each supported processor architecture.
• It is possible to run a 32-bit x86 version of Windows on an x64 hardware system.  In this case, use the table row for your 32-bit x86 version of Windows.

We usually market OCM updates using the names of their target operating systems.  For example, "KB123456 for Windows Server 2003" means that it is a .NET Framework 1.1 OCM update.  Similarly, "KB123456 for Windows XP Tablet PC and Media Center Editions" is a .NET Framework 1.0 OCM update.  Also, we usually market MSI updates using the name of its target .NET Framework versions.  For example, "KB123456 for the .NET Framework 2.0" is an MSI update.

The good news is that we are learning our lessons and we are not making the same mistakes again.  Without giving too much away, I think it's safe to say that Windows Vista will come with the .NET Framework built-in but there will not be any need do this OCM vs. MSI mumbo-jumbo.  In other words, we're cleaning things up a bit.  But we cannot go back and change the past: What you see above is what we've got for these .NET Framework versions and these operating systems.  We just plan to do it better next time.

Hope this helps!

I stated in an earlier post that "I am the person in charge of getting product updates (service packs and hotfixes) for Visual Studio and the .NET Framework into distribution channels like Windows Update, Microsoft Update, and the Microsoft Download Center."  It occured to me that some of you might care which updates go where.  If you do, read on!

In a nutshell, updates to the .NET Framework go on Windows Update while updates for everything else (in this case, Visual Studio) go on Microsoft Update.  Because all Windows Update content is on Microsoft Update as well (but not vice-versa), one could look at that the other way around and say that all updates (Visual Studio and the .NET Framework) go to Microsoft Update while only .NET Framework updates go to Windows Update.  All updates that go to either Windows Update or Microsoft Update must go to the Microsoft Download Center as well.

Tables have been known to help:

Developer Division Deployment Channels

Product	Windows Update	Microsoft Update	Download Center
.NET Framework	Yes	Yes	Yes
Visual Studio 2005	No	Yes	Yes
Visual Studio 2002, 2003	No	TBD	Yes

You may be saying to yourself, "I've never seen any Visual Studio updates on Microsoft Update."  That's true, but we're working on it.  Expect to see updates targeting Visual Studio 2005 on Microsoft Update starting in Q1 of calendar year 2006.  We will also be evaluating whether to service Visual Studio.NET 2002 and Visual Studio.NET 2003 in the same way.  These latter Visual Studio versions (2002, 2003) are more complicated because they were released before Microsoft Update existed and therefore were not built with Microsoft Update integration in mind.  We'll need to make do with what we have for these.  Let me know how we do!