While installing VisualStudio 2008 Beta2 I was surprised that the NET framework 2.0 installation got automatically updated. My good old copies of mscorlib.dll v2.0.50727.42 and friends got updated to v2.0.50727.1378. I expected to saw a new C:\WINDOWS\Microsoft.NET\Framework\v3.5.xxx folder but instead I had to search in C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 to see new assemblies. I’ve been especially interested by the new System.Core.dll assembly that contains most of new stuff that should have been put in mscorlib.

When creating a new project with VisualStudio 2008 Beta2, System.Core.dll is automatically referenced. It seems that System.Core.dll has been created to avoid touching mscorlib.dll and System.dll code. This is a consequence of the.NET framework compatibility policy. 

However mscorlib has been updated and by curiosity I compared mscorlib v2.0.50727.0 and v2.0.50727.1378 with the build comparison feature of NDepend :

The following CQL Query matches 389 methods dispatched into 95 types:

SELECT METHODS FROM ASSEMBLIES "mscorlib" WHERE CodeWasChanged

The following CQL Query matches 164 methods:

SELECT METHODS FROM ASSEMBLIES "mscorlib" WHERE CodeWasChanged AND IsPublic

The following CQL Query matches 30 methods:

SELECT METHODS FROM ASSEMBLIES "mscorlib" WHERE WasAdded

The following CQL Query matches no method:

SELECT METHODS FROM ASSEMBLIES "mscorlib" WHERE WasRemoved

The following CQL Query matches 4 methods (all of them were declared as internal and are now private):

SELECT METHODS FROM ASSEMBLIES "mscorlib" WHERE CodeWasChanged AND IsPublic

These numbers might be a bit flawed because some C#3 compiler optimization might have changed the IL code of some methods (and NDepend bases its code comparison on IL code). However, I checked with Reflector and I didn’t find any false positive. So, what code has been changed? Actually I’m not sure I can legally talk about such internal implementations details. If you are curious (as me) I invite you to do the comparison by yourself.

However we can talk for sure about System.Core.dll content. My preferred new class is System.Collections.Generic.HashSet<T> .My code is full of Dictionary<something,object> where the second parameter type is useless and I will be for sure heavy consumer of HashSet<T>. However, we won’t migrate the NDepend code soon to get these facilities since like many ISVs, we have to wait that the .NET framework 3.5 gets largely adopted (end of 2008 sounds reasonable). HashSet<T> is the only new collection in .NET 3.5.

The namespace System in System.Core.dll contains some classes for extended time zone feature and a lot of new delegate classes dedicated to LINQ support(Func<T,TResult>…). There is also 2 new namespaces dedicated to LINQ: System.Linq and System.Linq.Expressions.

There is a new namespace Microsoft.Contract that contains some attribute with sexy names such as ImmutableAttribute or InvariantMethodAttribute. Unfortunately, all these attributes are declared internal and we can’t use them. That’s sad since in my opinion immutable types are an excellent mean to deal with multi-threaded code (I hope to blog about this later). Btw, we recently add some supports in CQL to allow ensuring immutability with CQL queries such as:

// This CQL constraints warns when MyImmutableClass is not indeed immutable

WARN IF Count > 0 IN SELECT TYPES WHERE !IsImmutable AND NameIs "MyImmutableClass"

There seems to be new support for encrypted Safe Handle with some new public classes such as SafeNCryptHandle in the namespace Microsoft.Win32.SafeHandles but so far there is no documentation available online. SafeHandle was a great addition to .NET 2.0, sometime considered as the best v2.0 feature of the .NET Framework 2.0. Safe Handles allow dealing properly with complex situations when using unmanaged resources from managed code.

There is a new namespace System.IO.Pipes that allows using Windows pipe from managed code without relying on .NET Remoting (that relies internally on pipes when using the ipc scheme, InterProcessCommunication).

There is the new namespace System.Diagnostics.PerformanceData that allows to use from managed code some new Vista specific performance counters

There is some new WMI wrappers in the namespace System.Management.Instrumentation.

The namespace System.Runtime.CompilerServices contains 3 classes dedicated to LINQ advanced scenario such as serializing your expressions and scoping their executions. Ayende wrote some thoughts on this.

The namespace System.Security.Cryptography has been enhanced with some new algorithms largely commented by Shawn Farkas here and here.

Finally the namespace System.Threading contains a new ReaderWriterLockSlim that is meant to replace the ReaderWriterLock class that notoriously suffers from both design and performance issues. Joe Duffy has some great talk about this. Actually, the ReaderWriterLock class hasn't been tagged as obsolete.

There is few new ‘core’ stuff in .NET 3.5 comparing to what contained the .NET 1.1 to .NET 2.0 delta. It seems to be a good sign of maturity and it allows developers to concentrate their learning endeavour on high level framework such as WCF and WPF. My two cents is that I would have wished more collection implementations, more core math support (such as linear algebra) and more IO support (especially for absolute/relative/normalized pathes).