Red-bits, Green-bits and .NET Framework Versions…

A question came up on standardizing on .NET Framework 3.5 and the effects on older ASP.NET applications.  The short answer is that .NET Framework 3.5 is compatible with .NET Framework 2.0 or 3.0.  However, .NET Framework 1.0 / 1.1 ASP.NET applications are not compatible with .NET Framework 2.0 or higher, i.e. there are breaking changes.  Here’s some additional background….


Starting with .NET Framework 3.0 (.NET 2.0 laid the foundation), the .NET Framework is divided up into red bits and green bits.  Red bits are core functionality available in .NET 2.0, 3.0 and 3.5, i.e. the CLR, base ASP.NET support, etc..  Green bits are the “new stuff” that is additive.  ALL share the same core CLR in .NET Framework 2.0 so any changes in service packs that touch red bits are consistent in .NET 2.0, 3.0, and 3.5.  If you have any doubts:-) compare the contents of these directories:

C:\Windows\Microsoft.NET\Framework\v2.0.XXXXX (contains the core CLR assemblies like all the mscor*.dll assemblies and core binaries)

C:\Windows\Microsoft.NET\Framework\v3.0  (new libraries for WCF, WPF, and WF 3.0)

C:\Windows\Microsoft.NET\Framework\v3.5 (more additive updates including new compilers, assemblies, msbuild functionality, and tools but no new core CLR libraries).

(Note the XXXXX version is important in that 3.0 and 3.5 include service packs that will update the XXXXX build number because they will force service pack updates on .NET 2.0 to keep the runtime up-to-date, however, those same updates are also available for the stand-alone version of .NET 2.0).

Change in green bits are additive to .NET 2.0.  Developers do not pull in additive pieces (green bits) (and are not affected by green bit installs) until they add a reference to 3.0 or 3.5 assembly OR if they install green bits and have not kept .NET Framework 2.0 up-to-date.   So if an application runs on .NET Framework 2.0 and hasn’t been recompiled to a newer version, it does not matter whether 3.0 or 3.5 are installed on the same server or not as long as they are patching correctly.  To put it another way, if they are patching .NET 2.0 and keeping it up to date the red bits are the same whether 2.0 is only installed or whether 3.0 or 3.5 are installed as well as 2.0. 

The product team took these actions to reduce complexity and to not make the same mess as what happens in some other run-time environments.  To put it another way:-)  if .NET 3.5 does need to update red bits, the same update would also available for .NET framework 2.0 to keep things consistent---so keep things up-to-date via System Center / windows update and consistency is maintained.

To clarify further, I found a blog post with a somewhat confused blogger:

The blogger misinterprets what “not touched” means.  As an example, if you install .NET Framework 3.0 or 3.5 on an original install (RTM) of the .NET Framework 2.0, both the .NET Framework 3.0 and 3.5 will update .NET Framework 2.0 (red bits) to .NET Framework 2.0 SP1 as a minimum, i.e red bits are still serviced and patched with hotfixes and service packs. 

When you look at the download page for .NET Framework 3.5 it clearly states that .NET Framework 2.0 RTM will be serviced to .NET Framework 2.0 SP1:

“Microsoft .NET Framework 3.5 contains many new features building incrementally upon .NET Framework 2.0 and 3.0, and includes .NET Framework 2.0 service pack 1 and .NET Framework 3.0 service pack 1”

So, if a server is already at .NET Framework 2.0 SP1, there are not any changes---i.e. keep servers patched and up-to-date and consistency is maintained.

As additional background, .NET Framework 1.0 mainstream support ended 10 July 2007, and extended support ended 14 July 2009. Mainstream support for .NET Framework 1.1 ended on 14 October 2008, and extended support ends on 8 October 2013. Since .NET 1.1 is a component of Windows Server 2003, extended support for .NET 1.1 on Server 2003 will run out with that of the OS - currently 14 July 2015.  More information on support lifecycle information is available here.

.NET Framework Support Lifecycle

Skip to main content