New .NET 3.5 core stuff

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

This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://m_mehdi_m62@yahoo.com Mehdi

    I encountered to this error”Error 1 The type or namespace name ‘ReaderWriterLockSlim’ could not be found (are you missing a using directive or an assembly reference?)” while I was try use RWLockSlim.
    I am using .NET 3.5
    I have added the “using System.Threading;”.

  • Stefan Lange

    The implication is that after installing Visual Studio 2008 on a machine, all new functions from V2.0.50727.1378 are available and may accidentally be used in Visual Studio 2005 projects. Everything works fine and is completely invisible for the developer, but a customer with V2.0.50727.42 gets a “Function not found” exception. This is strange and unexpected, because the developer uses Visual Studio 2005 explicitly to prevent this problem (as he uses Visual Studio 2003 earlier to create .NET 1.1 compatible applications).
    I believe that most developers will not see the problem and maybe this situation lead us to new kind of DLL hell.

  • http://www.NDepend.com Patrick Smacchia

    MS guys have a great and stable CLR 2.0 implementation in which they invested a lot. I completely agree with their decision to build the new stuff on top of this implementation.

    However the 3.0 and 3.5 install still remains a bit dirty.

    For another example, have a look in:
    C:\WINDOWS\Microsoft.NET\Framework\v3.0
    You have these folders:
    {Windows Communication Foundation}
    {Windows Workflow Foundation}

    and while you would expect also a folder named
    {Windows Presentation Foundation}

    instead you found a folder named {WPF}?!

    You might ask
    ‘Who cares?’
    and I would answer
    ‘All ISV guys that build tools for .NET developers that need to reengineer the .NET installation’ (as my company and many others)

  • Mike

    “I expected to saw a new C:\WINDOWS\Microsoft.NET\Framework\v3.5.xxx folder”

    The CLR is still 2.0 I knew that because I was looking for new machine.config and web.config files in the same location.

  • http://www.NDepend.com Patrick Smacchia

    Thanks Daniel, upadted!

  • http://www.danielmoth.com/Blog/2007/06/net-framework-35.html Daniel Moth

    >>
    My good old copies of mscorlib.dll v2.0.50727.0
    < <

    Don't you mean v2.0.50727.42 (or v2.0.50727.312 if you are on Vista)?

    More detail here:
    http://www.danielmoth.com/Blog/2007/05/clr-v20-remains-at-same-version.html

    BTW, a complete list of new stuff in 3.5 is here:
    http://www.danielmoth.com/Blog/2007/06/net-framework-35.html

  • http://www.NDepend.com Patrick Smacchia

    Done!

  • http://blogs.msdn.com/bclteam Inbar Gazit

    Please correct this blog to either not mention BigInteger or to say it has been removed. It’s Internal in System.Core.dll from beta1 and forward and so it cannot be used by developers.