What's New in the BCL in .NET 4.0 CTP [Justin Van Patten]

The Visual Studio 2010 and .NET Framework 4.0 CTP is available for download as of last week.  The CTP contains new functionality throughout the .NET Framework, including several new BCL features and improvements:

• Code Contracts
  System.Diagnostics.Contracts provides a language-agnostic way to express coding assumptions in .NET programs.  The contracts take the form of pre-conditions, post-conditions, and object invariants.  Contracts act as checked documentation of your external and internal APIs.  The contracts are used to improve testing via runtime checking, enable static contract verification, and documentation generation.  We partnered with Microsoft Research to deliver this feature in .NET 4.0.  More information and tools are available on Microsoft Research’s code contracts website.  There’s also a highly-rated PDC session available online.
  
  
• Parallel Extensions
  We worked with the Parallel Extensions team to add the Task Parallel Library (TPL), Coordination Data Structures, and Parallel LINQ (PLINQ) to the BCL in .NET 4.0.  This includes an improved ThreadPool scheduling algorithm for tasks, the static Parallel class, concurrent collections in System.Collections.Concurrent, and other coordination data structures such as LazyInit<T>, CountdownEvent, Barrier, SemaphoreSlim, SpinLock, SpinWait, and ManualResetEventSlim. More information is available over at the PFX team’s blog.  Also, check out Daniel Moth’s PDC session on Parallel Programming for Managed Developers with the Next Version of Microsoft Visual Studio.
  
  
• BigInteger
  System.Numerics.BigInteger is an arbitrary-precision integer data type.  We worked with the Microsoft Solver Foundation team to deliver a highly performant big integer implementation.  BigInteger supports all the standard integer operations, including bit manipulation.  It can be used from any .NET language, and some of the new .NET languages—such as F# and IronPython—have support built-in to the language.
  
  
• Memory Mapped Files
  System.IO.MemoryMappedFiles exposes the memory mapping functionality provided by Windows as first-class managed APIs.  Memory mapped files can be used to efficiently edit very large files and can also be used to create shared memory for inter-process communication.  Along with this feature, we’re also introducing System.IO.UnmanagedMemoryAccessor, a new class that enables random access to unmanaged memory similar to how UnmanagedMemoryStream enables sequential access to such memory.
  
  
• ResourceManager Improvements
  The ResourceManager in System.Resources has been improved to respect the user’s preferred UI languages when looking for localized resources, instead of only using the CurrentUICulture’s parent chain.  This means if the user has specified that she prefers French and Spanish, the ResourceManager will look for French and Spanish resources before falling back to the neutral resources.  This change is present in Silverlight 2 as well as .NET 4.0.
  
  
• Compression Improvements
  The compression algorithms in System.IO.Compression have been improved in .NET 4.0.  DeflateStream and GZipStream no longer inflate already compressed data.  This means that in most cases you’ll see much better compression ratios when using these streams on .NET 4.0.  We’ve also removed the 4 GB size limit, so you can now compress streams over 4 GB in size.
  
  
• String Security Changes
  The default partial matching overloads on System.String (StartsWith, EndsWith, IndexOf, and LastIndexOf) have been changed to be culture-agnostic (ordinal) by default.  In addition, ToUpper and ToLower on System.String and System.Char have been changed to use the invariant culture instead of the current culture.  Although we have guidance and FxCop rules that recommend always using overloads that take a StringComparison parameter, unaware developers often just use the default overloads.  In previous versions of .NET, these default overloads do a culture-sensitive comparison using the current culture.  This can often lead to subtle bugs, most notably security vulnerabilities, when unaware developers use the default overloads to do security-sensitive string comparisons.  This change helps mitigate these vulnerabilities.  The change is present in both Silverlight 2 and .NET 4.0.  Even with these changes, our guidance still stands: whenever an overload exists that takes a StringComparison parameter, use it instead of an overload that does not take this parameter.  It makes your code clearer and easier to maintain.  This is especially important because the default overloads for String.Compare and String.CompareTo will remain culture-sensitive because these methods are most often used when sorting strings to be shown to the user.  We plan to add a compat switch in the beta that will allow an app to specify whether it wants the old behavior.
  
  UPDATE for .NET 4 Beta 1 In order to maintain high compatibility between .NET 4 and previous releases, we have decided to revert this change.  The behavior of String's default partial matching overloads and String and Char's ToUpper and ToLower methods now behave the same as they did in .NET 2.0/3.0/3.5.  The change back to the original behavior is present in .NET 4 Beta 1.  We apologize for any interim confusion this may cause.  We continue to recommend being explicit about the string comparison behavior you want, by always specifying a StringComparison value for the methods on String that accept it.

We’re also evaluating a number of potential new features and improvements for .NET 4.0 beta:

• Variance annotations
  The next versions of C# and VB support safe co- and contra-variance for generic interface and delegate types.  Co-variance means that a generic of a type, e.g. an IEnumerable<String>, can be treated as a generic of any supertype, e.g. an IEnumerable<Object>.  Contra-variance means that a generic of a type, e.g. an Action<Object>, can be treated as a generic of a subtype, e.g. an Action<String>.  In C#, co-variance is annotated with the “out” keyword and contra-variance is annotated with the “in” keyword.  We are annotating several interfaces and delegates in the BCL for variance.  You can learn more about co- and contra-variance in Anders Hejlsberg’s PDC session on The Future of C#.
  
  
• Tuples
  We are providing common tuple types in the BCL to facilitate language interoperability and to reduce duplication in the framework.  A tuple is a simple generic data structure that holds an ordered set of items of heterogeneous types.  Tuples are supported natively in languages such as F# and IronPython, but are also easy to use from any .NET language such as C# and VB.
  
  
• SortedSet<T>
  We plan to add a SortedSet<T> collection along with an ISet<T> interface.  SortedSet<T> uses a self-balancing tree which maintains data in sorted order for performance guarantees with insertion, deletion, and searches.  Both the new SortedSet<T> and the existing HashSet<T> implement ISet<T>.
  
  
• File System Enumeration Improvements
  We plan to add new file system enumeration APIs to System.IO.Directory and System.IO.DirectoryInfo that return IEnumerable<T>’s instead of arrays.  These new APIs are more efficient than the array-based APIs because they do not need to allocate a (potentially large) array and you can access the first results immediately instead of waiting for the entire enumeration to take place.  We’re also planning to add new convenience APIs for efficiently reading, writing, and appending lines from/to a text file using IEnumerable<String>.  These new APIs are useful in LINQ scenarios where you may want to quickly and efficiently query the contents of a text file and write out the results to a log file without allocating any arrays.
  

There are also a bunch of improvements to the CLR in .NET 4.0.  Here’s a high-level summary:

• In Process Side-by-Side: support for multiple CLR versions running in the same process.
• Interop improvements: no PIAs (check out Under the Hood: Advances in the .NET Type System and Managed and Native Code Interoperability: Best Practices)
• Simplified security model
• GC improvements (notifications and low-latency background collections)
• Profiling improvements (ability to attach/detach performance and memory profilers on the server)
• Debugging enhancements (support for Windows Error Reporting mini-dumps)

You can learn more about the next version of the CLR in Joshua Goodman’s PDC session on Microsoft .NET Framework: CLR Futures.

Over the next couple of weeks we’ll be posting more about the new functionality that’s available in the CTP.  Do note that we’re working on many other improvements for 4.0 that we’re not quite ready to announce just yet.

As always, we’d love to hear what you think of the CTP and announcements so far.