Base types, Collections, Diagnostics, IO, RegEx…
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:
We’re also evaluating a number of potential new features and improvements for .NET 4.0 beta:
There are also a bunch of improvements to the CLR in .NET 4.0. Here’s a high-level summary:
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.
PingBack from http://mstechnews.info/2008/11/whats-new-in-the-bcl-in-net-40-justin-van-patten-2/
Ah, the BigInteger makes its return. Heheh. Let's hope it sticks this time around!
So, I've looked at the research implementation of Code Contracts for VS2008, are there any differences between the VS2008 research version of Code Contracts and the RTM .NET 4.0 version. I think the functionalities in the Code Contract framework are cool, but using the framework as well as the integration in VS2008 feels kinda sketchy.
Contracts are wonderful! I only wish they were properly integrated into the languages (C# and VB); well, now that they're there, I would expect that there will be work towards that in C# 5.0 & VB11. Aside from the less clumsy syntax, it would also easily enable proper contract inheritance.
Why such restrictive license for the present Managed Contracts for VS2008 release, though?
BigInteger - expected since 3.5; 'nuff said.
Changes in System.String - I'm sure that Michael Kaplan will be jubilant ;)
Tuples - yes, please! Bonus points if you make them F#-compatible (i.e., so that F# tuples would use the corresponding BCL class under the hood, or at least be implicitly convertible to/from it). I guess that would require cooperation with the F# team, but I think it's well worth it.
I agree, this move towards putting everything in the framework instead in the language, even when extending the langauge makes much more sense, is concerning. I know why they do it: eiether it's easier to create a runtime for the features; or it much easier adds the capability to other languages (the goal of .NET); perhaps makes it easier to extend and enhance, even.
But still, things like contracts and parallelism and so on just feel much better in the langauge. Hopefully a future JIT will do some uber optimizations on such things so it isan't all function calls, virtual calls, and lambda calls overhead.
Regardless, I've long wanted a contracts feature and have created my own (get this: framework for it too) but it's nice now to have it as part of the commons.
I wish that all BCL methods taking arrays were reviewed. Top of my list is String.Join(). It's stupid to deal with List<T> and IEnumerable<T> and then have to .ToArray() on them just to perform the common operation of joining sequences with a delimiter.
You're right that the StringComparison enum should always be used where there is an overload that supports it.
So why is it that String.Replace(String,String) still doesn't take a StringComparison arg? The String.Contains method is another oversight.
I logged a case on Ladybug years ago for these two methods to gain a StringComparison. Years!
If you would fix these two methods in .NET 4.0, that would make me VERY happy.
P.S. Your changes to existing String methods to be ordinal/invariant instead of culturally aware is welcome, long overdue, and the way it should have been done in the first place. However, I think we all know the dangers of people recompiling their .NET 1/2/3 code against .NET 4.0 and suddenly getting the different behaviour. Much migration guidance needs to be given.
I've been reading with interest about the SSE support in Mono... any chance similar changes could appear in MS's CLR?
Thanks a great time at the PDC 2008 - I enjoyed the talk with Kim Hamilton at the BCL session (ask the experts).
I second the request for reviewing all methods that take arrays and determine whether IEnumerable<T> should be introduced also.
Regarding the string class, I'd like to request that string.Contains is overloaded to take params (i.e. "contains all these strings" instead of just one operator). Also string.ContainsAny with params would be nice as it's a very common pattern among developers to check a string for either N or any inclusive instances of other strings.
The SortedSet<T> is definately a keeper.
Come molti di voi sanno, da qualche giorno è possibile scaricare dal sito Microsoft una macchina virtuale
I’m not pleased where this whole co- and contra-variance thing is going. Don't get me wrong, this is what we all want, but I don't want language support; I want CLR support! In C# 4.0 it's currently implemented as a bad language trick. It only works on interfaces and delegates.
Since you are releasing a new version of the CLR with the next version of the framework (and don't get me started on the CLR’s new version number), you have change to make a real change here and don't leave it up to the language teams. Are you working on platform support for this for all generic types?
We are working with F# to make sure the Tuple is compatible. In fact, great deal of effort went into this already, more than what meets the eye here :-
>>>>> are there any differences between the VS2008 research version of Code Contracts and the RTM .NET 4.0 version
The Microsoft Research implementation and .NET implementation are very much in sync. However, there will likely be a few differences by the time we ship. It should be relatively easy to switch once we have these in production and not just up as a research project for non-commercial use.
>>>>> I only wish they were properly integrated into the languages (C# and VB)
We won’t have language support for contracts in .NET 4.0, but this is something we will consider for releases down the road. In the meantime, the APIs can be used from any language.
>>>>> Why such restrictive license for the present Managed Contracts for VS2008 release, though?
This is mainly due to the fact that this feature is in active development and that Microsoft Research is not set up to support/service the research project if there are any bugs/issues with it. But we are productizing this for 4.0, meaning in 4.0 / VS 2010, this will be fully supported.
>>>>> I guess that would require cooperation with the F# team, but I think it's well worth it.
As Ravi mentioned, we have been working with the F# team on compatibility :-)
>>>>> I wish that all BCL methods taking arrays were reviewed. Top of my list is String.Join(). It's stupid to deal with List<T> and IEnumerable<T> and then have to .ToArray() on them just to perform the common operation of joining sequences with a delimiter.
Thanks for the suggestion. We’ll see if we can address some of these pain points in 4.0.