Framework 3.5 green bits can touch existing framework files

Green and red bits where introduced at the release of the .NET Framework 3.0. Somasegar talked about it, and there is a fragment with Jason Zander at Channel9 on green bits in a video that covered the WinFX to .NET 3.0 rename (recommended viewing).

In short, green bits are additional assemblies that are installed on top of existing assemblies and frameworks. The .NET Framework 3.0 is a green bits addition to your system. This means that when you install .NET FX 3.0, your 2.0 installation will not be affected. Even more drastically, the files are not (supposed to be) changed at all. From the video with Jason Zander:

When you install version 3.0 it is additive to the machine. It’s not going to break things inside of 2.0 or even touch those files.

In contrast, red bits are serviced assemblies, that have undergone some form of bugfixing. These are delivered by service packs, updates or hotfixes. These assemblies could break your existing application and are therefore considered dangerous. Hence, the red bits.

Well, I was investigating the Framework 3.5 and the new extension in WCF for web enabling bindings. I found that I could not add the binding extensions, binding and behavior element extensions on my .NET 3.0 machine by copying the 3.5 framework directory v3.5.20209 from the Virtual PC image. This should have been true, because FX 3.5 is told to be a set of green bits. I started to investigate. Some background information first.

You will see new additive improvements, … We call those ‘Green bits’. … Green bits basically says ‘it is additive’ and ‘look it doesn’t change anything in this box‘. …

The fragment is from the video again and talk about 3.5. This box means the framework 3.0 and 2.0. Well, here is some new for you: In the FX 3.5.20209 beta some assembly files for FX 3.0 and 2.0 are different! Take a look at this bit that showed up in Reflector for the assembly level attributes of System.ServiceModel assembly (of FX 3.0) on the machine that had FX 3.5 installed:

[assembly: InternalsVisibleTo(“WireTool, PublicKey=0024…”)]

[assembly: SecurityCritical(SecurityCriticalScope.Explicit)]

[assembly: InternalsVisibleTo(“System.ServiceModel.Web, PublicKey=0024…”)]

[assembly: InternalsVisibleTo(“System.WorkflowServices, PublicKey=0024…”)]

[assembly: InternalsVisibleTo(“Indigo_ServiceModelUnitMetadata, PublicKey=0024…”)]

[assembly: InternalsVisibleTo(“ChannelFx, PublicKey=0024…”)]

Note the two bold items, which are assemblies from the FX 3.5. The attributes give access to the internals of System.ServiceModel.dll. Why is this necessary? Some of the internal types inside FX 3.0 assemblies are used by the 3.5 assemblies. For example, the new WCF extensions (3.5) need access to the System.Xml.XmlBaseReader class inside the System.Runtime.Serialization (3.0) assembly. This is fixed by adding the InternalsVisibleTo attribute to some of the 3.0 assemblies.

Obviously, these two attributes are not present in a pristine .NET FX 3.0 installation, so the files must have been changed. Here are some assembly and file version numbers:

.NET FX 3.0 (without 3.5):
System.ServiceModel, assembly, file 3.0.4506.25
System.Runtime.Serialization, assembly, file 3.0.4506.25

.NET FX 3.0 (with 3.5):

System.ServiceModel, assembly, file 3.0.4506.30
System.Runtime.Serialization, assembly, file 3.0.4506.504

But, wait a minute: those files were not be be touched by Green bits installations! This may have been true for 3.0 versus 2.0. but apparently doesn’t hold (at the moment) for 3.5 versus 2.0 + 3.0.

Some more oil on the fire. Check out the file version number of System.Web of framework 2.0 (which was 2.0.50727.312 originally). Then, notice the AssemblyKeyFile file location: RedBits.

[assembly: AssemblyKeyFile(@”F:RedBitsToolsdevdivFinalPublicKey.snk”)]

[assembly: AssemblyDelaySign(true)]

[assembly: NeutralResourcesLanguage(“en-US”)]

[assembly: SatelliteContractVersion(“”)]

[assembly: AssemblyInformationalVersion(“2.0.50727.1302”)]

I wonder what Microsoft means by “not touched”. I did not compare the implementations of the different assemblies. Maybe, the only thing that has changed is the addition of the attributes.

Thoughts, anyone?

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s