Mads and Dustin showed off their cool VB and C# team t-shirts at BUILD and tons of people liked them and asked where they could get one.

So, we're thinking about making them available for purchase online. I've been working on some new designs and would love to know what you think. See the designs and leave your feedback on the full post over on the .NET team blog.

Regards,

-ADG

This is the culmination of over half a decade of design and investment from some of the brightest minds at Microsoft and in consultation with you, our very passionate community, and with this latest release (included in Visual Studio 2015 RC) we're throwing the doors wide open for all of you to join us in realizing a phenomenal return on that investment!

What does "Go-Live" mean?

First, it means that the C# 6 and Visual Basic 14 compilers are language complete and officially supported by Microsoft for use in production environments.

Secondly, it means that the .NET Compiler Platform ("Roslyn") APIs are officially supported by Microsoft for use in production environments. That means that you can get started writing (and shipping) your own code smart tools, refactorings, diagnostics, fixes, and whatever else you can imagine. And most excitingly it means you can start making your new and existing .NET libraries Code Aware Libraries.

If you hadn't heard, a Code Aware Library is a .NET library distributed via NuGet which comes with domain-specific guidance like live code analysis and code fixes to ensure correct usage and that consumers follow best practices. We feel this is the next evolution of what it means to ship a .NET library and that over time analyzers will be as essential to library authoring as doc comments are today. In fact, the Azure SDK team is shipping a Code Aware Library right now to ensure their developers write the best Azure apps possible.

You'll hear us talk a lot more about .NET Analyzers and Code Aware Libraries in the near future but I highly recommend checking out these resources and getting started writing analyzers now:

• Alex Turner's 5-minute Channel 9 intro to Code Aware Libraries
• My 20-minute intro to writing .NET Analyzers.
• Dustin Campbell's deep-dive into "Analyzers and the Rise of Code Aware Libraries" at BUILD 2015.

And also check out these cool community created analyzers:

• Code-Cracker
• NR6Pack
• .NET Analyzers
• C# Essentials

Does this mean that Roslyn is done?

Roslyn v1.0 will RTM alongside Visual Studio 2015 (because it powers the entire code editing experience inside of VS it kind of has to). Our team will be working hard until then fixing any problems discovered and tuning performance. But we're already imagining opening more scenarios beyond v1.0 for after RTM. Ever since our first CTP in 2011 enthusiasts and tools developers have engaged us with their feedback and their aspirations and that engagement has only grown in the last year since we open sourced. We're listening and have accumulated a backlog of proposals for new APIs that we have a strong interest in and some of which we've already begun actively investigating:

• C# and Visual Basic Scripting APIs (and Interactive) continue to be top of mind in this category. We know just how these APIs will open up exciting new experiences for everyone and will ship them with a go-live license as soon as we can.
• There's also a strong interest in a richer set of APIs for analyzing control flow graphs that we know would enable powerful diagnostic analyzers like dispose checking and nullability detection.
• We're also looking into new APIs for analyzing semantic trees in an efficient and language-neutral way to broaden the set of analyzers which can be written once and work equally well for both C# and Visual Basic.

And the list (and Roslyn) goes on.

Call to Action

If you're a library author, get started making your library a Code Aware Library NOW. Or if you're just a dev looking to make some tools to help them analyze codebases, code faster, or find and fix mistakes sooner, download the SDK and see how Roslyn can help. And even if you're not even remotely interested in any of that stuff, that's OK, you can start using expression-bodied members, getter-only auto-props, string interpolation, the null-conditional (?.) operator and other new language features to remove boilerplate, make your code cleaner, and modernize your existing projects right now. But no matter which of those describes you, you can always join the discussions on GitHub and UserVoice to engage the product team and help shape the futures of C# and Visual Basic.

Regards,

Anthony D. Green
Program Manager
Visual Basic, C#, and F# Languages Team

"I am looking for someone to share in an adventure."

— Gandalf, The Hobbit, J.R.R. Tolkien

On April 3, 2014, Anders Hejlsberg set us on our open source journey when he made the .NET Compiler Platform (aka “Roslyn”) source code public live on stage in San Francisco. Without much open source experience to guide us (or a Grey Wizard), we anxiously yet excitedly hit the open roads. This post details the real and true story of the trials and triumphs we’ve experienced in Roslyn’s first year of open source.

The Call to Adventure

Previously, in order for developers to build a code-focused tool or application they would have to develop their own semantic analysis engine that would imitate what our compiler would do. Guessing how the “black box” of the compiler works is expensive, time intensive, and doesn’t always lead to the correct behavior. We built Roslyn in order to remedy this problem by re-architecting our compiler as a platform. Providing APIs for the compiler platform lowers the barrier-to-entry for developers to build all sorts of code-based innovations: meta-programming, interactive use of C# and VB, code generation/transformation, code analysis, refactoring, and more. With this goal in mind, our team began our work on redesigning the C# and VB compilers in 2009.

Crossing the Threshold

The decision to make Roslyn open source did not come out of the blue. In our original architecture discussions in 2009, we dreamt of open sourcing our language compilers. Access to the platform source code as well as the APIs would empower developers to take their code-based innovations to a whole new level and explore new depths. Our vision enabled us to proactively define principles that would make it easier to go open source if that’s what we decided to do in the future.

Despite this dream of going open source, we didn’t cross the threshold until about five years later. We saw the success the F#, ASP.NET, and TypeScript teams experienced with their open source approach and we quickly followed in their footsteps at Build in 2014.

Trial and First Failure

When we began this journey in April 2014, we did not have a specific map to follow. Instead, we decided to find our path in the open—allowing everyone to see us stumble into Rivendell, dredge through the snowstorms on Caradhras, and explore every cave and nook and cranny in our search for the perfect path. We took a risk with this “learning in the open” approach, but we believed in establishing an open development process from the start. Luckily, the community has been extremely supportive with helping us find the best course-corrections.

Naturally, we didn’t avoid all the cobwebs or snowstorms in our pathfinding. But our open strategy allowed us to catch our mistakes early and adjust to find better ways to manage our project. For example, we now publish our language design notes each week, test our external build scripts, and increase our responsiveness to issues/questions

Meeting Allies

Along the way we have made some great allies (we love dwarves, hobbits, elves, and mankind!) who have really helped and supported us along this journey. The immediate community feedback on our C# Language Design was vital in some of the decisions we made for C# 6.0. For example, this discussion made us realize we had to yank primary constructors. We also gained valuable insights into null-conditional operator syntax and string-interpolation.

Furthermore, the community has already made some truly awesome tools. Here is a sample of community-driven projects that are a part of The Fellowship of the Roslyn Project:

• C# Pad is an interactive shell that lets you run and execute C# in your browser.
• CodeConnect.io creates visualizations of your call stack at design-time and includes refactoring and search features.
• DuoCode cross compiles your C# 6.0 code into JavaScript code
• LINQPad.CodeAnalysis is a library that adds capabilities to LINQPad to make it easier to work with Roslyn.
• Mono/Roslyn is a cross-platform, open source implementation of the .NET Framework.
• OzCode v2.0 uses Roslyn to provide magical debugging experiences.
• Scrawl by FluentCo.de is a light-weight editor for modern web developers.
• scriptcs is an open source project that lets you use C# as a scripting language and provides a command-line C# REPL.
• Try Roslyn demonstrates Roslyn and shows how to repro a compiler bug.
• WebEssentials Markdown editor is powered by Roslyn.

Based on the quantity and quality of projects in the community that use Roslyn, it is clear we made the right move by open sourcing our platform.

Growth & New Skills

We originally put our source code on CodePlex because it was fast and easy to do--as well as the established “place” for Microsoft open projects at the time. However, many of you told us that you would prefer GitHub as a platform and so we moved our source there.

When we moved we also changed our workflow to follow some of the best practices we saw other Microsoft teams using. Before the move, we were using a “source open with limited contributions” model. This means that our issue tracking and code review system were all internal and while we made an effort to bring community contributions into our code base, we did not directly merge their code (instead we copy/pasted their code and merged it ourselves).

Since our move, we have adopted a “fully open source” model where we are developing and working entirely in the open. We file bugs and design notes in GitHub’s issue tracking system and submit all of our code changes as pull-requests. We use GitHub’s code review system as our own and use Markdown to link issues or communicate about code. We also established a crisper idea of what we accept for pull-requests, what sign-offs we require for pull-requests to be merged, what style guide we recommend, and what an acceptable time frame for closing a pull-request is (roughly 1o days, if you were wondering).

This workflow change was critical in getting widespread community participation. By making core committers on the team follow the same code submission process as everyone else in the community we democratized participation in the project and increased the levels of transparency. And now, gone are the days of users telling us what they want and not knowing when it’s going to get done! Developers can look at our issue tracker and see if anyone has started working on their issues yet. Issues are assigned to milestones to communicate our prioritization—which is always up for discussion or up-for-grabs.

Transformation

Moving to a workflow that has our team working in the open as much as possible and using the same contribution model as the community has allowed us to almost double our community engagement in a third of the time:

Our user base for Roslyn is also steadily increasing (the more the merrier!). This graph illustrates how our pull-request users and issue-logging users are growing since our new model:

Here are some additional statistics on our response-rates and engagement that we track to ensure our core team is suitably prioritizing acceptance of code over net-new development:

Our response rate for issues is half that for pull-requests—which is expected due to our high volume of incoming issues! Regardless, we are happy with these numbers and are always looking for ways to make them better.

We have also been open sourcing more code. Since January we have open sourced three more components of our platform:

• Scripting
• Expression Evaluators
• Visual Studio Language Services

Our Interactive design meeting notes are also now in the open.

Acceptance

With the first year of our journey under our belt, there is still plenty more to do. Currently, we are trying to iron out some finer details on our open source system. To start, we still haven’t ported our historical issues from CodePlex into GitHub. We also haven’t really figured out labeling for issues on GitHub and we’d love a way that we could make labelling more democratic:

I inspired a new issue label in #Roslyn! https://t.co/jNjT1c0hdv

— Schabse Laks (@Schabse) March 15, 2015

Also we need to figure out how we map commits to different product releases. How do we best communicate what code has made it into which release, product, or NuGet package? Do you have any ideas on how to make this clear, transparent but democratic without polluting the history too much?

To top it off, we are working on making it easier for F5 builds to pick up the changes you made to the compiler and workspace layer.

The Road Ahead

We still have a long road ahead (fraught with who knows what perils?) but the journey has been thrilling so far. We cannot thank the community enough: thank you, thank you, thank you! You all have created fabulous technologies already with Roslyn and your quality feedback and code contributions have been critical to our success. As Galadriel reminds us, “Even the smallest [pull-request] can change the course of the future.” It has also been an absolute pleasure getting to work and know you all better through Gitter, GitHub, Twitter, etc. So thank you all for being our very own Samwise Gamgees and wish us well on the remainder of this journey! For those of you who haven’t joined our fellowship, check us out and help us on our journey into Year Two.

"End? No, the journey doesn't end here."

— Gandalf, The Lord of the Rings, J.R.R. Tolkien

Over 'n' out
Kasey Uhlenhuth, Program Manager, Managed Languages Team

Before you read more about our improvements in CTP 6, make sure you have read Anthony's post on debugging improvements in Visual Studio 2015 Preview.

Edit & Continue is reaching its potential.

Edit & Continue lets you modify and add to your source code while debugging without ever having to restart your session. I'm happy to say we listened to you all and have fleshed out the Edit & Continue experience. Say goodbye to the days of pre-2005 language support and small edits! See the list below to see what source code edits are possible while debugging*:

• Adding methods, fields, constructors, properties, events, indexers, field and property initializers, and nested and top-level types (including delegates, enums, interfaces, abstract and generic types)
• Modifying bodies of constructors (including constructor initializers), expression-bodied members, and field and property initializers
• Adding and modifying methods that use the following post-2005 types and features:
  • Async/await
  • Operations with dynamic objects
  • Iterators
  • C# 6.0 language features: string interpolation, null-conditional operators, etc.
• Reordering type members and type parameter constraints
• Refactoring code (extract method and inline temporary variable) using Ctrl + .
• 

*The following types of edits are not supported:

• Deletion of members, types, or entire method bodies
• Modifying method signatures and renaming
• Modifying generics, interfaces, and abstract types
• Adding or modifying enum members to an existing enum
• Modifying await expressions wrapped inside other expressions (e.g., G(await F());)

Object IDs are a hidden gem and we've modified the syntax.

Did you know you can tag an object in the debugger and refer to it later using Make Object ID (even when the object is out of scope)? Did you know you could compare references of objects and verify that they refer to the same object with an Object ID tag? While Object IDs have been around for several years, few know and take advantage of this feature.

An Object ID is a unique identifier for an object. Because garbage collection unpredictably shifts object memory addresses, we can’t use pointers to track objects. Instead, our debugger gives you a unique identifier and keeps track of the object's current location for you (using an aliasing mechanism in the CLR). You can use the Object ID when debugging to compare references of objects and be absolutely certain they refer to the same object. You can also use an Object ID to monitor an object when it is out of scope in the debugger.

Below, I am stopped at a breakpoint on line 13. I have created a Watch for Circle a and made an Object ID for it ($1). Now if I step into the initialization of Circle b, putting Circle a out of scope, I can still inspect the value of Circle a via its Object ID:

Another change to note is that we've changed the Object ID syntax for C# and Visual Basic. It is now a dollar-sign ($) followed by a numeric for both languages (e.g., $1). The previous syntax for Object IDs was [number]# for C# (e.g., 1#) and ObjID[number] for Visual Basic (e.g., ObjID1). We chose to alter the Object ID syntax for the following reasons:

• The new syntax will allow us to provide a better IntelliSense experience by showing defined Object IDs in the completion list after typing the “$” prefix character (planned for RTM)
• The new syntax is now consistent with other pseudo-variables, (e.g. $exception, $ReturnValue)

Try out all these new features in Visual Studio 2015 CTP 6. Let us know what you think using Visual Studio’s Send a Smile feature! And don’t forget to log issues on our GitHub.

Over 'n' out
Kasey Uhlenhuth, Program Manager, Managed Languages Team

It’s official. We’re moving to GitHub!

We are moving the Roslyn OSS code from CodePlex to GitHub. GitHub has a vibrant open source community that we want to actively be a part of and contribute to. We are also going to take this time to modify our pull request process. Please see below for more details:

WHEN:  This upcoming Wednesday or Thursday, depending on whether we encounter any problems.

WHERE: Under the .NET Foundation. More details coming soon. HERE! (Edit: 1/16/15)

WHY: We are moving our code to GitHub as well as switching to use git internally. This means we will have fewer moving parts and will get us much closer to the same environment you’d be using on Roslyn code. It will be so worth it.

HOW: This will be a simple switch – turn off CodePlex, turn on GitHub. You’ll be able to see our check-ins on GitHub that same day.

DETAILS:

• Your pull requests may pile up for a couple of weeks because we are going to take the opportunity to also streamline our (currently very complex) pull request process. We’ll reopen in a couple weeks with a much easier process. (At this point, we’d advise holding off on any requests sent to CodePlex.)
• We’ll be using GitHub Issues for both discussions and bugs after the switch.
• We will try to move over outstanding bugs from CodePlex, but this is the trickier part of the plan.
• We will do our best to preserve check-in history.

While we are excited about this move, we might experience some hiccups along the way. Thanks for your patience while we take this next big step!

Stay tuned for more information later this week.

Over 'n' out
Kasey Uhlenhuth, Program Manager, Managed Languages Team

If you hadn't heard, Visual Studio 2015 will support the use of lambda expressions in the debugger windows.

We're all very excited to deliver on this longstanding TOP customer request. When LINQ was introduced in 2008 it was a game changer for the way .NET developers think about and code with data. So, to finally be able to use these powerful coding constructs with the Visual Studio debugger is a match made in Redmond.

But wait. There's more!

The new expression evaluators (the language-specific components that enable you to run snippets of code in various debugger contexts) are the culmination of years of collaboration between the Managed Languages and Visual Studio Debugger teams, and a prime example of why the "Roslyn" project has been such an important investment to the future of C# and VB. But they're not the only things we've been working on. We're still working very hard to enable Edit and Continue in and around lambda and query expressions, and inside of Async and iterator methods (which requires deep collaboration between the VB/C# team, the VS debugger team, and the CLR team to enable) and we'll tell you more about how that's going in a future post :)

The road behind and the road ahead

Visual Studio has always had a world class debugging experience with tools like the Watch and Immediate windows, and conditional breakpoints. And since then we've only made it better with additions such as Design-Time Expression Evaluation and Edit and Continue. In parallel, the C# and Visual Basic languages have increased in expressiveness with each release, often in ways not even dreamed of when we initially built many of the foundational components of the debugger.

For example, the introduction of a query expression, lambda expression, yield statement, or await expression can result in the body of a method being fundamentally rewritten and even whole new methods and types being created behind the scenes. This is all mostly hidden from the developer but the debugger has to understand everything. And in the case of Edit and Continue or the expression evaluators the debugger must actually understand how to execute that rewrite on the fly. The gulf in understanding and capability between the debugger and the compiler has meant that with each release the sets of language features you can use/manipulate at design-time and at debug time have grown further apart.

But, I'm proud to say, that all changes with Visual Studio 2015.

We've rebuilt the expression evaluators on top of the "Roslyn" compilers to ensure they understand modern language constructs, and with the capability to execute exotic IL transformations that they simply weren't able to before. We're also rebuilding Edit and Continue to similarly leverage the "Roslyn" compilers to enable edits in and around more language constructs.

This doesn't mean every language feature will work everywhere overnight. There is still work to do to ensure everything is wired together correctly. But, it does mean that the work of plumbing language features through the debugger is a few orders of magnitude smaller than it used to be. And that's what's really got me excited! We can build great debugging experiences for existing language features and we can ensure new features have those great experiences out of the box.

The new conditional-access and interpolated string expressions are just two examples of new language features which will work in the debugger windows and with Edit and Continue on Day 1.

Call to action: Spread the word and send us your feedback

Help us shout it from the rooftops "LAMBDAS WORK IN THE DEBUG WINDOWS!" (Tweet it, share it, tell your friends, text your parents). Remember, this is just the beginning! If you haven't already, download the Visual Studio 2015 Preview and try it out. Send us your feedback about what you like, what you don't like, and what you'd love to see us enable next.

Warmest regards (and Happy Holidays),

Anthony D. Green
Program Manager
Visual Basic and C# Languages Team

Some features are mostly syntactic sugar (expression-bodied members, string interpolation, nameof), some complete what felt a bit like unfinished work (getter-only auto-properties, await in catch and finally) or expand existing features in a natural way (using static, index initializers). Some expose expressiveness from IL that C# didn’t previously surface (exception filters, parameterless constructors in structs). Some are almost just “bug fixes” to the design, and you’ll hardly know that you’re making use of them (improved overload resolution, extension Add methods in collection initializers).

In the following, I’ll take you through each of these language features. We’ll start at the expression level, and work our way “outwards”. We’re quite confident that this is the set that will end up in the shipping version, but we already know that some of them will change a little. I’ll let you know when we get there.

Expression-level features

nameof expressions are a new form of string literal that require more syntax and are more restricted than the existing kinds. What’s not to like?

Actually there’s a lot to like. Oftentimes you need to provide a string that names some program element: when throwing an ArgumentNullException you want to name the guilty argument; when raising a PropertyChanged event you want to name the property that changed, etc.

Using ordinary string literals for this purpose is simple, but error prone. You may spell it wrong, or a refactoring may leave it stale. nameof expressions are essentially a fancy kind of string literal where the compiler checks that you have something of the given name, and Visual Studio knows what it refers to, so navigation and refactoring will work:

(if x == null) throw new ArgumentNullException(nameof(x));

You can put more elaborate dotted names in a nameof expression, but that’s just to tell the compiler where to look: only the final identifier will be used:

WriteLine(nameof(person.Address.ZipCode)); // prints "ZipCode"

Note: there are small design changes to nameof since the Preview was built. In the preview, dotted expressions like in the last example, where person is a variable in scope, are not allowed. Instead you have to dot in through the type.

String interpolation lets you more easily format strings. String.Format and its cousins are very versatile, but their use is somewhat clunky and error prone. Particularly unfortunate is the use of numbered placeholders like {0} in the format string, which must line up with separately supplied arguments:

var s = String.Format("{0} is {1} year{{s}} old", p.Name, p.Age);

String interpolation lets you put the expressions right in their place, by having “holes” directly in the string literal:

var s = "\{p.Name} is \{p.Age} year{s} old";

Just as with String.Format, optional alignment and format specifiers can be given:

var s = "\{p.Name,20} is \{p.Age:D3} year{s} old";

The contents of the holes can be pretty much any expression, including even other strings:

var s = "\{p.Name} is \{p.Age} year\{(p.Age == 1 ? "" : "s")} old";

Notice that the conditional expression is parenthesized, so that the ‘: "s"’ doesn’t get confused with a format specifier.

Note: This describes the syntax that works in the Preview. However, we’ve decided to change the syntax, to even better match that of format strings. In a later release you’ll see interpolated strings written like this:

var s = $"{p.Name,20} is {p.Age:D3} year{{s}} old";

Also we are adding a scheme so that you can influence the formatting behavior; e.g. to use Invariant Culture. More on this in a later post.

Null-conditional operators address many of the situations where code tends to drown in null-checking. They let you access members and elements only when the receiver is not-null, providing a null result otherwise:

int? length = customers?.Length; // null if customers is null
Customer first = customers?[0];  // null if customers is null

The null-conditional operator is conveniently used together with the null-coalescing operator `??` to provide a default value for when the outcome is null:

int length = customers?.Length ?? 0; // 0 if customers is null

The null-conditional operator exhibits short-circuiting behavior, where an immediately following chain of member accesses, element accesses and invocations will only be executed if the original receiver was not null:

int? first = customers?[0].Orders.Count(); // if customers is null, the result is null

This example is essentially equivalent to:

int? first = (customers != null) ? customers[0].Orders.Count() : null;

Except that customers is only evaluated once. None of the member accesses, element accesses and invocations immediately following the ? are executed unless customers has a non-null value.

Of course null-conditional operators can themselves be chained, in case there is a need to check for null more than once in a chain:

int? first = customers?[0].Orders?.Count();

Note that an invocation (a parenthesized argument list) cannot immediately follow the ? operator – that would lead to too many syntactic ambiguities. Thus, the straightforward way of calling a delegate only if it’s there does not work:

if (predicate?(e) ?? false) { … } // Error!!

However, you can do it via the Invoke method on the delegate:

if (predicate?.Invoke(e) ?? false) { … }

We expect that a very common use of this pattern will be for triggering of events:

PropertyChanged?.Invoke(this, args);

This is an easy and thread-safe way to check for null before you trigger an event. The reason it’s thread-safe is that the feature evaluates the left-hand side only once, and keeps it in a temporary variable.

Index initializers extend object initializers so that you can now initialize not only members but also indices of the newly created object:

var numbers = new Dictionary<int, string> {
    [7] = "seven",
    [9] = "nine",
    [13] = "thirteen"
};

A common use for this would be for creating Json objects declaratively in one expression, rather than having to first create the object and then assign into it in separate statements.

Extension Add methods are now observed in collection initializers; we used to only recognize instance methods called Add. Just a design fix; VB already does this.

Overload resolution has been improved in a few ways, which will likely result in more things just working the way you’d expect them to. The improvements all relate to “betterness” – the way the compiler decides which of two overloads is better for a given argument.

One place where you might notice this (or rather stop noticing a problem!) is when choosing between overloads taking nullable value types. Another is when passing method groups (as opposed to lambdas) to overloads expecting delegates. The details aren’t worth expanding on here – just wanted to let you know!

Statement-level features

Exception filters are a CLR capability that is exposed in Visual Basic and F#, but hasn’t been in C# – until now. This is what they look like:

try { … }
catch (MyException e) if (myfilter(e))
{
    …
}

If the parenthesized expression after ‘if’ evaluates to true, the catch block is run, otherwise the exception keeps going.

Exception filters are preferable to catching and rethrowing because they leave the stack unharmed. If the exception later causes the stack to be dumped, you can see where it originally came from, rather than just the last place it was rethrown.

It is also a common and accepted form of “abuse” to use exception filters for side effects; e.g. logging. They can inspect an exception “flying by” without intercepting its course. In those cases, the filter will often be a call to a false-returning helper function which executes the side effects:

private static bool Log(Exception e) { /* log it */ ; return false; }
…
try { … }
catch (Exception e) if (Log(e)) {}

Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all.

This has actually been a significant limitation, and people have had to employ unsightly workarounds to compensate. That is no longer necessary:

Resource res = null;
try
{
    res = await Resource.OpenAsync(…); // You could always do this.
    …
}
catch(ResourceException e)
{
    await Resource.LogAsync(res, e); // Now you can do this …
}
finally
{
    if (res != null) await res.CloseAsync(); // … and this.
}

The implementation in the compiler is quite complicated, but you don’t have to worry about that. That’s the whole point of having async in the language: so that most of the complicated stuff is left to the compiler.

Member declaration features

Auto-property initializers are now enabled, and are similar to initializers on fields:

public class Customer
{
    public string First { get; set; } = "Jane";
    public string Last { get; set; } = "Doe";
}

The initializer directly initializes the backing field; it doesn’t work through the setter of the auto-property. The initializers are executed in order as written, just as – and along with – field initializers.

Just like field initializers, auto-property initializers cannot reference ‘this’ – after all they are executed before the object is properly initialized.

Getter-only auto-properties allow you to omit a setter on an auto-property:

public class Customer
{
public string First { get; } = "Jane";
public string Last { get; } = "Doe";
}

The backing field of a getter-only auto-property is implicitly declared as readonly (though this matters only for reflection purposes). It can be initialized through an initializer on the property as in the example above, or it can be assigned in the declaring type’s constructor body, which causes the value to be assigned directly to the underlying field:

public class Customer
{
    public string Name { get; };
       public Customer(string first, string last)
    {
        Name = first + " " + last;
    }
}

This is about expressing types more concisely, but note that it also removes an important difference in the language between mutable and immutable types: auto-properties were a shorthand available only if you were willing to make your class mutable, and so the temptation to default to that was great. Now, with getter-only auto-properties, the playing field has been leveled between mutable and immutable.

Expression-bodied function members allow methods, properties and other kinds of function members to have bodies that are expressions instead of statement blocks, just like with lambda expressions.

Methods as well as user-defined operators and conversions can be given an expression body by use of the “lambda arrow”:

public Point Move(int dx, int dy) => new Point(x + dx, y + dy);
public static Complex operator +(Complex a, Complex b) => a.Add(b);
public static implicit operator string(Person p) => "\{p.First} \{p.Last}";

The effect is exactly the same as if the methods had had a block body with a single return statement.

For void returning methods – and Task returning async methods – the arrow syntax still applies, but the expression following the arrow must be a statement expression (just as is the rule for lambdas):

public void Print() => Console.WriteLine(First + " " + Last);

Properties and indexers can have getters and settersgetter-only properties and indexers can have an expression body:

public string Name => First + " " + Last;
public Customer this[long id] => store.LookupCustomer(id);

Note that there is no get keyword: it is implied by the use of the expression body syntax.

Parameterless constructors in structs are now allowed:

struct Person
{
    public string Name { get; }
    public int Age { get; }
    public Person(string name, int age) { Name = name; Age = age; }
    public Person() : this("Jane Doe", 37) { }
}

The expression ‘new Person()’ will execute the declared constructor instead of the standard behavior of providing the default value. Note, however, that ‘default(Person)’ will still produce the default value, as will ‘new Person[…]’ for each of the array elements. In those cases the constructor is not executed: It’s only when you explicitly use ‘new’ on the struct type.

Import features

using static is a new kind of using clause that lets you import static members of types directly into scope.

In the Preview it looks like this:

using System.Console;
using System.Math;

class Program
{
    static void Main()
    {
        WriteLine(Sqrt(3*3 + 4*4));
    }
}

This is great for when you have a set of functions related to a certain domain that you use all the time. System.Math would be a common example of that.

Note: The Preview will only import members of static classes. We have since changed the design in several ways:

1. The syntax will be more different from current using clauses – it will have the keywords “using static”.
2. Members of non-static types can be imported, including structs and en ums
3. Members of VB modules and F# top level functions can be imported
4. Extension methods will not be imported into top-level scope; instead they will show up as extension methods. This gives a way to import extension methods from just a single class, something which wasn’t possible before.

Want to try it out?

Download VS 2015 Preview and tell us what you think. Happy Hacking!

Mads Torgersen, Principal Program Manager, VS Managed Languages

Mads is the PM for the C# programming language at Microsoft. He runs the design meetings and maintains the language specification. He is also involved in the design of Visual Basic and TypeScript.

The Rosetta lander Philae wasn't the only thing in space last week. Our launch of Visual Studio 2015 Preview and our announcement to open source the full .NET server stack were out of this world. After all, it’s not every day that you can say your work trended higher than Kim Kardashian on Twitter.

After an overwhelmingly positive reception to the news of .NET going open source, we want to make sure you know how and where to contribute. The .NET Core repository already has closed about 80 pull-requests (with the majority being merged) and there are some great community efforts going on right now. Here are some links to get you started:

	What's New in C# 6.0 | Mads Torgersen C# 6.0 adds about a dozen bite-sized new features to C#, all aimed at making your code cleaner and clearer. Instead of introducing new concepts, each feature makes a common coding pattern simpler, and removes boilerplate code to let the intent of the code stand out. The video takes a quick tour through the new features: auto-properties without setters, methods and properties with expression bodies, member access that protects against null, interpolated strings and much more.
	What's New in Visual Basic 14 | Lucian Wischik VB14 has a host of improvements across the board. In the IDE, it now includes refactoring, the ability to organize imports, better cref support, and more. Visual Basic 14 projects show metadata as source, display the References node in the Solution Explorer, support Shared Projects, and compile 50% faster. The Visual Basic language has improvements in existing features like comments within LINQ, read-only auto-properties, and multi-line string literals. It also adds new features like NameOf, member access that protects against NullReferenceException, and string interpolation. This video is a quick tour of the highlights.
	Introducing F# for the Enterprise | Lincoln Atkinson Have you looked at F# for your projects recently?  F# is a mature .NET language that's functional-first, cross-platform, open source, and enterprise-ready. You can find the beginnings of Visual F# 4.0, the next F# language and tools version, in Visual Studio 2015 Preview.  If you're curious about F# and want to learn more, take a few minutes to watch this video. We'll cover some of the unique benefits F# has to offer, walk through a bit of F# WPF code, and leave you with some pointers to great F# resources on the web.
	Improving Your Code Quality using Live Code Analyzers | Alex Turner Live Code Analyzers are used to add custom error messages and warnings that appear live as you're typing, along with automatic code fixes to help you clean them up. They are available as NuGet packages that you add to your projects in Visual Studio 2015. In this video, you'll see how the FxCop analyzer package now helps you improve your code even before you build. You'll also see the Azure Code Analysis package, which teaches you best practices for building Azure apps by spotting bugs the moment you introduce them.

Over 'n' out
Kasey Uhlenhuth, Program Manager, Managed Languages Team

Over the past several years, our team has been hard at work re-implementing the full language stacks for C# and Visual Basic. While this was a long investment, we knew that an improved stack with a cleaner architecture would allow our team to work faster, empower others to build "code smart" tools and applications, and create a richer and smarter IDE experience in Visual Studio.

Today, we are pleased to announce that this work has culminated with the release of Visual Studio 2015 Preview. Visual Studio 2015 Preview showcases many improvements—new language features, smarter and better IDE experiences, improved debugging, and code-aware "diagnostic analyzers"—that we believe make it the best version of Visual Studio to date. Our team will publish detailed blog posts on these improvements over the next couple weeks on the C#, Visual Basic, and F# blogs. In the meantime, here are some of the upcoming posts:

	IDE Improvements | Dustin Campbell The IDE experiences have been brought to life! Every core C# and Visual Basic IDE feature has been completely rebuilt and refreshed. Dustin’s post will walk through some of the highlights and drill into new experiences around live code analysis and automated refactorings.
	C#: New Language Features | Mads Torgersen VS 2015 Preview includes C# 6, the latest installment of the language. C# 6 aims at making your everyday code cleaner without adding new concepts, helping remove boilerplate code and making your intent stand out more clearly. Mads’ post will take you through the dozen or so little features, including the null conditional dot (?.) to make null checking fade into the background, string interpolation for easy formatting, and a refactoring-safe nameof operator to get the names of program elements as text.
	Visual Basic: New Language Features | Lucian Wischik In Visual Basic we're adding the same key new language features as C# for reducing boilerplate code. In addition we’ve rounded out lots of existing language features, mainly in response to user requests. ReadOnly auto-properties are a big favorite, along with multi-line string literals, comments within multiline LINQ queries, year-first date literals, partial interfaces and many more.
	Debugging Improvements | Anthony D. Green Anthony’s post will discuss our improvements to the C# and VB debugging experiences in Visual Studio 2015 Preview, including more extensive support for modern language features like LINQ queries, lambda expressions, and extension methods, which can now be used in the Watch window, Immediate window, conditional breakpoints, and other debugger contexts.
	Diagnostic Analyzers & Code Fixes | Alex Turner Alex’s post will introduce everyone to diagnostic analyzers. Diagnostic analyzers are a key new feature of Visual Studio 2015 that lets a NuGet package enable custom warnings and errors in the editor live as you type, with automatic code fixes that can clean up those issues for you. Packages can even be bundled together as a “code-aware library” that pulls in both an API and the domain-specific analyzers to make sure that you stay on course when using it – you’ll have targeted guidance from the moment you download the NuGet package. And because these analyzers are part of your project, everyone on your team gets to see the same warnings. You can download a preview of the Code Analysis for Azure package now, and we expect many more analyzers to be available soon.
	F#: A Preview of F# 4.0 | Lincoln Atkinson The F# language and tooling continues to evolve with Visual F# 4.0, developed in partnership with our active open source developer community.  Lincoln’s post will walk you through the numerous enhancements and features that are ready today: constructors as first-class functions, simplified mutable values, a greatly expanded core library, improved project templates, and much more. Read this post to learn how to install the latest Visual F# update on top of VS 2015 Preview.

Download Visual Studio 2015 Preview. Please help us improve your developer experience by sending a “smile” from Visual Studio, providing feedback on UserVoice, joining our language discussions on Codeplex, or filing bugs on Connect!

Don’t forget to keep an eye on our blogs (C#, Visual Basic, F#) for more details over the next couple of weeks.

Over 'n' out, Kasey Uhlenhuth, Program Manager, Managed Languages Team