The C# 5.0 beta release is now available

The C# 5.0 beta release is now available

Rate This
  • Comments 20

I am super excited to announce that the beta release of Visual Studio version 11 (which includes the .NET CLR version 4.5, Visual Basic version 11 and C# version 5) is available for download right now. As you know if you've been following our CTP releases, in C# and VB we've greatly improved the ease of programming in an asynchronous "continuation-passing" style such that the compilers do the hard work of rearranging the code into a form amenable to asynchrony, so that you don't have to. VB also now has iterator blocks, and has surpassed C# in that VB iterator blocks can even be inside lambdas. Pretty neat.

And that's just the big stuff for C# and VB; there is an enormous amount of new stuff here in the languages, the tools and the runtime. I can't wait to see what developers do with all of these amazing features. Please, download the beta and give us feedback on what you like and what you don't like.

See the following blog posts for more details:

* Jason Zander
* C# Team
* VB Team

  • Does it include a runtime so we can use programs compiled with C# 5(and using async-await) on .net 4? Or do we still need to use the library included with the old AsyncCTP for that?

    The beta does not include such a library, no. We hope to be able to provide a new one some time before VS 11 ships, but are not making any promises at this time. -- Eric

  • Great to know, Congratulations, thank you!

  • Congrats!  Very exciting, I can't wait to use Async in production apps.

  • VB gets iterator lambdas while C# doesn't? I don't want to live on this planet anymore. :)

  • I thought the trend was to match CLR to C# version number?

    Nope. See http://stackoverflow.com/a/247623/88656 for a summary of the version number mismatches. -- Eric

  • Am I correct that the only new features in C# 5 are async/await and the new caller info attributes?

    Those are the big ones. We've also added improved support for using the Windows 8 runtime library from C#, and fixed the semantics of closures in foreach loops. -- Eric

    I was kind of hoping for more little things, like being able to speficy Enum and Delegate as generic type constraints (which should be almost free) or tuple unpacking.

    Sorry to disappoint. The platitudes "you can't please everyone" and "the perfect is the enemy of the good" come to mind. -- Eric

  • @Gabe I still check now and then if it is possible to set constructor arguments types in a generic constraints (eg: "where T : new(int, string)"). Besides not having that feature, that doesn't keep me unmotivated, as the new async features look really nice, and I'm sure I'll write a lot of code with them :)

  • didn't microsoft said that c# and vb is same features equals 1-2 years ago ?

    No we did not. We said that we will not pursue a strategy of market differentiation for C# and VB. For example, we would not pursue a strategy such as "C# is for scientist programmers, VB is for line-of-business programmers". Both are general-purpose languages.

    Because of this choice to not pursue a differentiation strategy, we will not add major feature areas to C# and not VB, or vice versa. For example, C# and VB both got LINQ and both got async. Those features were designed for both languages by teams with many shared members. However, it is absolutely not the case that VB and C# are "the same language with different syntax". There are plenty of areas where the feature sets are different and will stay that way. VB will likely never get pointers. C# will likely never get XML literals. Also, the philosophies of the two languages will continue to be different; VB is a comparatively forgiving language, C# is a comparatively strict language. In this particular case, it was comparatively inexpensive to get iterators and async working in nominal and anonymous methods in VB, so we took the opportunity to do so. That does not change the prioritization of the same feature in C# much; we had other priorities. -- Eric

    anyway its good both is different

    it will be nice if c# can unsubscribe from anonymous function

    because i live this kind of code

    button.click+=(s,e)=>{//Hello memory leak!}

  • Hello

    I have a feeling that following example will not work as expected:

    lock(syncRoot)

    {

       await ReadDataFromFileAsync("data.txt");

    }

    Am I right?

    Yes, this example is logcally abit wrong. But still.

    Imagine that "lock" statement is several levels up in the call stack.

  • when can we expect silverlight support?

  • @petka: This is forbidden by the spec. await cannot occur inside a lock block (nor a catch as well as a few other restrictions...)

  • I know this is a VS not a C# question but as they go hand in hand: are there any plans to release x64 versions of Visual Studio, or support edit-and-continue in 64-bit C# code?

  • Congrats, awaiting the new version!

  • Excellent!

    Therefore, in the upcoming months, we can expect posts about meta programming features for C# 6.0 ;)

    I cannot wait!

  • I vote for allowing writing async/await programs targeting .NET 4.0!

    All that's needed is for the compiler to be happy to find the necessary types (eg AsyncTaskMethodBuilder) in any assembly, rather than just looking in mscorlib. Then we can ad-lib a solution, for example using the old AsyncCtpLibrary.dll.

Page 1 of 2 (20 items) 12