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).