• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)

Date: Tuesday, 24 Jun 2014 23:35

This post is brought to you by Beth Massi, a Program Manager on the Visual Studio team.

If you’ve been reading this blog I’m sure you know by now that the .NET Compiler Platform (code named "Roslyn") is the next generation of the Visual Basic and C# .NET compilers. But what does that mean? I was up in Redmond a couple weeks ago and I caught up with Dustin Campbell (Program Manager on the Managed Languages Team) and sat him down to explain Roslyn to me, a .NET developer. I mean, let’s face it folks, I’m not a compiler geek. I’m a busy, practical, programmer who trusts their compiler will just work. So what’s in it for me?

It turns out that Roslyn brings a ton of value to anyone writing VB or C# code. By making it much easier for partners to build amazing tools and for language and IDE features to get implemented much faster, developers everywhere will benefit from the faster innovation. Dustin also shows off some of the new IDE features like quick fixes and new refactorings for both VB and C# that are available in the Visual Studio "14" CTP.  

Watch: .NET Compiler Platform ("Roslyn") for the Rest of Us

Thanks, Dustin, for setting me straight!

For more information on Roslyn and to try it out, see "Installing the Preview" section of the Codeplex site at https://roslyn.codeplex.com/

-Beth Massi, Visual Studio Community

Author: "CSharpFAQ" Tags: "roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 03 Jun 2014 19:06

As announced today by Soma, we've just released the first CTP (Community Technology Preview) of the next version of Visual Studio. This is doubly-exciting as this is the first public release of a version of Visual Studio powered by "Roslyn" by default. At BUILD we released the "Roslyn" End User Preview which extends Visual Studio 2013 by replacing some components with their "Roslyn" equivalents but this version of Visual Studio is built from the ground up on "Roslyn" with "Roslyn".

The Visual Studio "14" CTP includes new and improved language and IDE features for C# such as a revamped refactoring experience (including new refactorings):

And the highly requested conditional access (?.) operator*:

*Because this is an experimental language feature, to enable it in a project you must add this element to your .csproj file to enable the "Experimental" language version:


These are just some of the small but powerful enhancements we're building for C# developers and we're far from done. But that's no reason for you to wait. Since we've literally rebuilt the very foundations of C# it couldn't be more critical for us to get your feedback early and often on what you like, don't like, love, and what you want to see more of.

Stay tuned for more posts from the Managed Languages team highlighting new and improved language features and experiences. In the meantime…

And one more thing: Visual Studio side-by-side support is not available on this early build. DO NOT install this CTP (or feed it after midnight) on a machine with any other version of Visual Studio installed.


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

Author: "CSharpFAQ" Tags: "roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 20 May 2014 20:25

Thanks everybody for all the great feedback!

We've received hundreds of replies since last week with detailed information and concrete examples for us to review. We are closing the survey today and have started to process the tons of data you have provided.

The overwhelming majority of you have told us that Edit and Continue is important and you'd like us to make it even better. We asked of the scenarios we'd identified where Edit and Continue is disallowed today how many of you were impacted by which restrictions and here's what you said:

As you can see the most frequently reported problem is that Edit and Continue doesn't allow you to modify or add LINQ queries or lambda expressions.

The good news is that hope to address LINQ and lambdas (and more) in the next release of Visual Studio! In fact, we've investigated what it would take and the work is already underway to make the necessary changes across the Visual Studio debugger, .NET Runtime, and Managed Languages teams to make Edit and Continue play nice with LINQ queries and lambda expressions in vNext.

We'll share more about that and other exciting developments in future posts. Until then, a HUGE THANKS from all of us on the Visual Studio team for helping us figure our what is important to you.



-The Visual Studio team

Author: "CSharpFAQ" Tags: "debugger, Edit and Continue"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 16 May 2014 01:52

If you didn't get a change to make it to TechEd this year, fret not, we got it all on video for your viewing pleasure.

Join Principal Program Managers Dustin Campbell and Mads Torgersen as they give you the inside scoop on the future of VB and C#.

You'll learn about:

  • What "Roslyn" is about, why we're building it, and how it impacts you
  • Cool tools built with Roslyn (and how to build your own)
  • Visual Basic and C# becoming open source languages
  • New IDE features we're building
  • New language features we're considering for the next version of VB and C#
  • How you can get involved and interact with the VB and C# language designers and "Roslyn" architects

And better than just showing off all of these cool features you can get your hands on many of them today with today with the "Roslyn" End-User Preview. This preview includes the new code editing experience we're building for VB and C# as well as a smattering of new language features and a preview of the "Roslyn" APIs.

If you haven't had a chance to hear about the great things our team is working on for the future (or if you're so excited you just want to hear about them again) watch the video. And if you haven't already install the preview. Then ask us questions, here on the blog or on CodePlex and tell us what you like, what you love, what you hate, and what we're missing.

Also, over the next weeks we'll be diving into the features and the APIs shown in the video (and more) and how to use them. So keep checking back here for new content so you stay up-to-date with all the latest news about your favorite programming languages from your favorite team (and get the word out!).

Have fun!


P.S. If you haven't already please take a moment to fill out the Edit & Continue survey and tell us where we can be more awesome.

Author: "CSharpFAQ"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 13 May 2014 19:28

UPDATE 2014-05-20: We've received enough responses and the survey is now closed. Thanks everyone!

Hey C# developers!

Do you get tired of seeing this box (I know I do)?

Tell us about it!

The Visual Studio team would like your anonymous feedback on improving Edit and Continue (E&C) when developing .NET applications. This survey can take as little as 3 minutes to complete (I’ve saved you some time already by copying all the words on that page to this page so you don’t have to read it twice) and will guide ongoing support and making it work in more places. If you consider yourself a regular E&C user or would like to see improvements that let you use it more often – we need to hear from you!

Please take a few minutes to complete the survey @ http://aka.ms/encsurvey and if it’s not too much trouble tell all of your developer pals about it. Blog, wall, and tweet the link to anyone who’ll listen!

The information you provide is entirely voluntary. If you do not wish to provide us with any information, please disregard this survey. By filling out and returning this survey, you agree that we can use, disclose, reproduce, or otherwise distribute your feedback at the aggregated level. Your personal information will remain confidential. Please check http://privacy.microsoft.com/en-us/default.aspx for Microsoft Privacy Statements.


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

Author: "CSharpFAQ" Tags: "debugger"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 17 Apr 2014 19:30

Hello everyone! I hope you had a chance to catch the recent announcements around the .NET Compiler Platform (“Roslyn”). If not, I encourage you to view Anders’s presentation at Build 2014 (skip to 1:10:28). If you haven’t already, download the previews and take them for a spin!

What’s included?

The Roslyn compiler codebase is now open source. Check out Matt’s recent post for details around how to enlist in the open source project and modify the compiler. In addition to the End User Preview that Matt discussed at the beginning of his post, we are also releasing an SDK Preview. The End User Preview allows you to try out the new Roslyn IDE experience as well as some new language features that we are planning to include in the next version of C#. The SDK Preview on the other hand, contains tools and samples that will help you build your own applications, code refactoring extensions, quick fixes etc. atop the Roslyn APIs.

In this post, I’d like to introduce to you the Syntax Visualizer tool included in the SDK Preview. Detailed documentation for this tool is available on the Roslyn CodePlex site.

If you are new to Roslyn, I recommend starting with the Roslyn Overview document which provides a nice overview of how C# syntax and semantics are modelled in the Roslyn APIs. Also check out this talk that Dustin and Mads presented at Build 2014 for a tour of what’s in the above previews. More documentation and learning resources are available on the Roslyn CodePlex site.

What is the Syntax Visualizer?

The Syntax Visualizer is a Visual Studio extension that allows you to inspect and explore Roslyn syntax trees. This tool will be your faithful companion as you build your own applications atop the Roslyn APIs.

Why do I need a Syntax Visualizer?

In Roslyn, each type of syntactic construct in the language is modelled using a type named SyntaxNode. For example, C# class declarations are modelled using the type ClassDeclarationSyntax that is a derived type of SyntaxNode. A SyntaxNode can contain other SyntaxNodes. For example, the SyntaxNode for a class declaration contains SyntaxNodes for each method declaration in this class. The SyntaxNode for a method declaration in turn contains SyntaxNodes corresponding to each variable declaration inside this method and so on.

The source code in each file for a given program is thus modelled by a tree of SyntaxNodes. SyntaxNodes also contain SyntaxTokens and SyntaxTrivia which form the leaf nodes of syntax trees. SyntaxTokens represent significant text in the code (such as keywords, identifiers, literals and punctuation) while SyntaxTrivia represent text that is largely insignificant for normal understanding of the code (such as whitespace and comments).

The following image depicts what the syntax tree for a small snippet of C# code would look like. You can read more about SyntaxNodes, SyntaxTokens and SyntaxTrivia in the Roslyn Overview document.


Now the C# language supports a large variety of syntactic constructs (type declarations, method declarations, lambdas, variable declarations, method calls etc. etc.). So we have a corresponding large variety of SyntaxNodes in Roslyn and a variety of configurations in which these SyntaxNodes can appear within different syntax trees.

SyntaxNodes also happen to be the primary form of currency in the world of Roslyn APIs. Most tasks in the Roslyn APIs begin with SyntaxNodes. For example, you pass the SyntaxNode for the construct that you are interested in to other APIs such as SemanticModel to get richer semantic information about the construct. You specify which types of SyntaxNodes you wish to “handle” when you use the Roslyn Diagnostics and Code Fixes APIs to implement your own code fixes and code refactoring extensions.

When you combine these two aspects (i.e. a large surface area of syntactic constructs and the need to communicate in terms of these constructs all the time), it is clear that in order to be productive when building applications atop Roslyn, you need some easy way to inspect and navigate syntax trees. You need some easy way to answer questions like – What does the syntax tree for this piece of code look like? What is the type / Kind of the SyntaxNode that represents this language construct? This is where the Syntax Visualizer tool comes in handy.

What can I do with the Syntax Visualizer?

Once installed, the Syntax Visualizer allows you to inspect the syntax tree for any C# or VB code file that is open inside the Visual Studio IDE. You can select any piece of code in your file and the Syntax Visualizer will tell you what SyntaxNode it corresponds to and what the properties of this SyntaxNode look like. You can also select nodes from the Visualizer’s tree view and it will tell you what piece of code each node corresponds to.


The Syntax Visualizer also allows you to view a Directed Syntax Graph for selected sub-trees in case you want a more detailed graphical view of the nodes in this sub-tree.



Finally, the Syntax Visualizer also has some rudimentary support for inspection of Symbols and semantic information. You can read more about Symbols and APIs for performing semantic analysis in the Roslyn Overview document.


As I mentioned above, detailed documentation around how to install and use the Syntax Visualizer tool is available on Roslyn CodePlex site. Do try it out and use it as you explore and build rich code applications and extensions atop Roslyn! :)


We would love to hear your feedback, ideas and suggestions. A list of the different ways in which you can provide feedback for the preview is available here. You can provide general feedback about the Syntax Visualizer here and report any issues you find over here.

Have fun with Roslyn! :)

--Shyam Namboodiripad on behalf of the Roslyn team

Author: "CSharpFAQ" Tags: "roslyn, Shyam Namboodiripad, Syntax Visu..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 03 Apr 2014 23:00

It’s a big day for us on the Managed Languages team! As announced at the //BUILD conference earlier today, and as posted by Soma on his blog, we are not just delivering a new preview of Roslyn to all of you, but are in fact moving all of the compiler code to open source! The code will be released and maintained by MS Open Tech, who are our partners in this endeavor.

The goal of open-sourcing the compilers is something that we’ve been working towards for just over a year, and we’re really excited that it’s finally time to make the “big reveal.” (Best of all, we no longer have to try to keep a poker face every time we’re asked about whether or not the compilers will ever be open sourced!) And as this momentous day drew closer, I found myself struggling a bit to write a blog post which could capture the enormity of this moment on behalf of our team. Although Microsoft has actively embraced openness as a part of day-to-day operations for quite some time now, it’s nevertheless very difficult to put into words how exciting this particular change is for us, given how it takes our participation in the world of open source to an entirely new level.

In a vain effort to capture all of that emotion, I inflicted (which is really the only word for it) several drafts on my team and my management, none of which really added anything to the basic facts already planned to be revealed in Soma’s blog. Finally, Jay Schmelzer (our PM director) took me aside and wisely said, “Look, we’ve got your back on the ‘big reveal;’ don’t worry about that. Why don’t you take everyone the rest of the way and show us how it actually works?”

Of course, he was exactly right, and so, here we go…

Installing the preview

Before jumping into the open source code, you should first install the Roslyn preview. To do this, follow these steps:

(1) Browse to the preview site. You’ll be asked to sign in with a Microsoft account (and will have the opportunity to create a free one if you don’t have one already).

(2) Once you are signed in, you’ll be taken to a survey page, where you will just need to fill in your name, preferred e-mail address, and country – this is just so we can stay in touch with folks installing the preview in order to get feedback from them and send new information to them.

(3) After filling out the survey, your Microsoft account will be given permission to access the preview. A “Thank you” page will appear; click the Go to .NET Compiler Platform (“Roslyn”) link that appears on it, as shown here:


(4) The .NET Compiler Platforms (“Roslyn”) main page will be presented to you with a couple of options, as shown here:


Click the “Download” button. This will take you to a standard Connect download details page that describes the download and shows the options for obtaining it. Click the Download button on that page to actually download the preview.


(5) Once downloaded, now you can install it! The team has worked hard to make the installation as absolutely quick and painless as possible. After downloading & running it, you’ll be presented with the following dialog:


Clicking “Install” will cause the older compiler & IDE pieces in Visual Studio to be turned off and the Roslyn versions to be installed and turned on in their place. This takes mere seconds to complete. (The old pieces are not deleted, so if you choose to uninstall the VSIX, you’ll safely revert back to using them.)

(6) Once the installation is finished, you’ll need to restart your instance of Visual Studio (assuming it was open during the installation).


After installing & relaunching Visual Studio, you should now be able to see Roslyn-specific improvements. For example, consider the following reasonably-common code in C#:

        static void Main(string[] args)
            int n1;
            if (int.TryParse(args[0], out n1))

Using one of the new language features in Roslyn (inline declaration expressions), you can now simplify this to:

        static void Main(string[] args)
            if (int.TryParse(args[0], out var n1))

An example for VB which demonstrates a new feature would be:

    Sub Main()
        Dim s As String = "This is a multiline
            string literal."
    End Sub

which was impossible using the old VB compiler.

Your older projects should build fine against the new compilers (obviously, speak up if they don’t!), though you should be aware that any changes you make to them which use the new language features won’t work if you uninstall the preview.

Beyond examples of how the language is evolving, the Roslyn preview also showcases many examples of how we are using the new Roslyn compilers to provide stronger IDE functionality. One of my personal favorites is inline renaming: select any symbol or method name, right-click and choose Rename (or just press F2), and start typing a new name right in the program file. Your name changes will be reflected instantly throughout all uses of that name in your solution, all at once, without affecting any other symbols/methods that coincidentally have the same name but in a different context.


In this case, there is no guessing about which names refer to the same symbol; that information is known and exposed, without having to resort to string comparisons bolted on top of the text buffer (as used to be the case), all thanks to the new compilers.

Here’s the fine print: please be aware the set of features that end up in the final version is subject to change before an official version is released – features can and will be added, removed, or modified in the interim, often due to getting feedback from you as to what works and what needs to be improved (see the end of this post for details on how to give feedback). Similarly, the language features showcased in the preview are not locked down, and should be viewed as examples of things that are being considered for the final version. Finally, you may sometimes notice that one language might showcase an IDE or language feature in the preview while the other language doesn’t. You shouldn’t worry about that; although it might be because a given feature simply doesn’t make sense for the other language, it’s far more likely that the developers just haven’t gotten around to it yet, as such things are generally implemented serially from one language to the other. (FWIW, I’m already planning to go into more detail as to how features are vetted and scheduled in a future blog post, in case anyone is curious about that.)

Enlisting in the open source project

Now, if you’d like to take it a step further, you can enlist in the open source project to view and experiment with the code yourself. Here are a couple of important points:

  • NuGet is used for packaging, and it’s important to use using version 2.8.1 (or later) of it. If you don’t have that extension (or that version) installed on Visual Studio yet, you can add it by selecting Tools→Extensions and Updates, and then in the Online section, select and install “NuGet Package Manager for Visual Studio 2013.” You can also install it from here, and that’s a great site to visit if you encounter any problems with NuGet.
  • Also, you’ll also need the Visual Studio 2013 SDK in order to open the projects – you can download that from here.

Once you’ve got those set up, open Team Explorer in Visual Studio (View→Team Explorer). At top of that window, you’ll see a dropdown labeled “Home” listing whatever your current workspace is. (Mine happens to be our internal Roslyn TFS project, as shown below, but your default workspace will be different or possibly even “offline” – the important thing to note and use is the dropdown arrow to the far right of what I’ve circled in the image.)


  • In the dropdown menu, select Projects and My Teams→Connect to Team Projects.
  • At the bottom of the resulting view, you’ll see a section labeled “Local Git Repositories.” Drop-down the Clone list. You’ll see a dialog similar to this:


  • In the first field, type in http://git01.codeplex.com/roslyn (as shown in the picture), and in the second field, specify the location on your local machine where you’d like to store the code.
  • Press “Clone.”

You can now open the solution and build it exactly like any other solution. Furthermore, Visual Studio supports the typical Git commands, so that you can (for example) use the Unsynced Commits pane in Team Explorer keep your enlistment up-to-date with any changes that have gone in by using Pull, as shown here:


I encourage you to run Pull often – by keeping your enlistment up-to-date, you’ll be able to see the direction that the compiler work is headed, and to provide feedback on it in our forums.

If you try building Roslyn from an enlistment, please note that Roslyn is built using itself as a requirement, so make sure that you’ve installed the Roslyn preview first before trying that. Don’t try building Roslyn using the old compilers that shipped with VS 2013 – you’ll just get lots of interesting errors which won’t make a lot of sense.

Making local changes in the compilers

When making local changes in the compilers, you’ll want to first create a fork of the code. (The main branch is never modified directly; it only takes pulls coming from forks.) You’ll need to have a CodePlex account to do this first, however. Once you’ve got that, then launch your browser, navigate to https://roslyn.codeplex.com/SourceControl/latest, and click on the “Fork” link:


Give your fork some meaningful name and description, and press “Save”:


You now have your own fork of the code that you can experiment with & update as you see fit without changing your copy of the “main” source. You can clone it locally using the Team Explorer, just as I showed in the previous section, except that you would specify the forked location (e.g., https://git01.codeplex.com/forks/mattgertz/testfork using my example) as the source, and some other appropriate local disk location for where the code would be stored. (Note that you may see a couple of warnings in the build regarding linking to Syntax.xml.Generated.* files. These warnings are benign and will eventually be addressed; you can safely ignore them for now.)

After building your updated compilers, you’ll find the outputs below the Binaries directory off of the root of the enlistment (e.g., in Binaries\Debug, if that’s the configuration you built), and you can use rcsc.exe (for C#) and rvbc.exe (for VB) to compile any test programs that you want to create.

If, at some point in the future, you want to submit one of your changes for consideration in the main source code repository (as opposed to your own fork of it), you’ll be able to send a pull request to the team from inside CodePlex. (Note that the devs are heads down on finalizing this first version of the new compilers, and so during that remaining time, only simple fixes are likely to be accepted in order to avoid churn. You can expect a blog post later on regarding the types of changes that would be accepted, the procedure for verifying stability before submitting, and so on.)


It is also possible to update your copy of Visual Studio to use your own built version of Roslyn (for example, to see how the IDE reacts to your changes), but it’s slightly complicated:

First of all, you’ll need to use the release fork, not the master fork. This is because the compiler code is constantly changing in reaction to feedback, and that includes changes to the APIs that are used by the non-open IDE bits in the Roslyn preview in order to access compiler information (until the APIs get locked down as we get closer to completion). When these APIs change, the ability to communicate between the two is lost. The release fork, however, accurately reflects the state of the code at the time that the Roslyn preview was snapped, and so is safe to use as a baseline for this sort of thing. (You can see the fork on the Roslyn CodePlex site by choosing “Source Code” and then opening the “Browsing changes in” dropdown – it’s called “releases\build-preview.”)

To switch to this fork in Git, you will need to execute the following two commands from an appropriate Git prompt in your enlistment:

> Git fetch

> Git checkout – track origin/releases/build-preview

Your git repository will now have the contents of the releases/build-preview branch.  Once you’ve done this, you can switch back and forth between the branches using Git checkout master and git checkout releases/build-preview. (Details on Git usage are beyond the scope of this blog; see http://www.git-scm.com/book/en/Git-Branching-Remote-Branches for more information on branching in Git.)

Second, you’ll need to disable Visual Studio’s strong-name assembly checking for the relevant assemblies first. There’s a script to help with that, which you can find checked into the source code at Src/Tools/Microsoft.CodeAnalysis.Toolset.Open/Scripts/Prepare.bat.

Finally, you need to create/set the environment variable OpenSourceDebug to true in your build environment, so that the code is built with the proper key. In a command line build, you can actually do this while building your changes using msbuild /p:OpenSourceDebug=true. For building inside Visual Studio, you can open a command prompt window, enter set OpenSourceDebug=true, and then launch Visual Studio from there.

With all of that done, make your changes. After building, you’ll find the resultant VSIXs to install under your Binaries directory (e.g., Binaries\Debug).

Please note that we will never accept pull requests for the release fork – we need to keep it pristine and accurately reflecting the state of the code relative to the Roslyn preview bits. Anything you actually want considered for submission would need to be ported to a fork created from the master first.

Example of updating the compiler

For those who attended the //BUILD conference, you may have seen Anders demonstrate one example of a change to the language, in which he added support for French quotes in the language. I’ll go through that example in detail here, so that you can replicate it yourself:

(1) Open your fork of the Roslyn codebase in Visual Studio

(2) The next steps depend on which language you want to alter:

(3) For C# developers:

a. Open the file Src\Compilers\CSharp\Source\Parser\Lexer.cs

b. Scroll down to the method ScanSyntaxToken, and copy & paste in the code that is highlighted below. This will add the character « (Unicode 0x00AB) as a token which can start a string scan:

            // Start scanning the token
            character = TextWindow.PeekChar();
            switch (character)
                case '\"':
                case '\'':
                case '«':
                   this.ScanStringLiteral(ref info);

c. Next, scroll down to the method ScanStringLiteral, and copy & paste the in code that is highlighted below. The character will now become a valid beginning to a string.

        private bool ScanStringLiteral(ref TokenInfo info, bool allowEscapes = true)
            var quoteCharacter = TextWindow.PeekChar();
            if (quoteCharacter == '\'' || quoteCharacter == '"' || quoteCharacter == '«')

d. Finally, scroll further down in the same method, and copy & paste the in code that is highlighted below. The » character (U+00BB) will now become a valid terminator to a string, but only if it matches a corresponding earlier « character.

                    else if (ch == quoteCharacter || (ch == '»' && quoteCharacter == '«'))

e. Build the Roslyn solution. The output will be in the Binaries\Debug directory off of the root of your enlistment.

f. Navigate to the Binaries\Debug directory, and create a file there called Program.cs. Paste the following text into it:

     using System.Console;

     class Program
         static void Main(string[] args)
             WriteLine(«Welcome to my version of Roslyn!»);

g. Open a command prompt, change directory to the Binaries directory, and enter rcsc.exe Program.cs

h. Now, enter program.exe and see Welcome to my version of Roslyn! successfully print out!

(4) For VB developers, it’s a similar process. However, Visual Basic is trickier because double quotes can also be used in escape sequences for the quotes themselves, which adds a lot of more cases to support. Supporting that would make this example much longer; therefore, humbly begging the reader’s indulgence, I will leave that remainder as an exercise for them. In the meantime…

a. Open the file Src\Compilers\VisualBasic\Source\Scanner\CharacterInfo.vb

b. Scroll down to the IsDoubleQuote function, and change its contents to the highlighted line below (code comments removed for brevity’s sake):

        Friend Shared Function IsDoubleQuote(c As Char) As Boolean
            Return c = """"c OrElse (c >= DWCH_LSMART_DQ AndAlso (c = DWCH_DQ Or c = DWCH_LSMART_DQ Or c = DWCH_RSMART_DQ))
                             OrElse c = "«"c OrElse c = "»"c
        End Function

c. Build the Roslyn solution. The output will be in the Binaries directory off of the root of your enlistment.

d. Navigate to the Binaries directory, and create a file there called Program.vb. Paste the following text into it:

Imports System.Console
Module Module1

    Sub Main()
        WriteLine(vbCrLf & «Welcome to my version of Roslyn!»)
    End Sub

End Module

e. Open a command prompt, change directory to the Binaries directory, and enter rvbc.exe Program.vb

f. Now, enter program.exe and see Welcome to my version of Roslyn! successfully print out!

Saving changes back to the server

Of course, once you’ve finished building and testing your code modifications, you’ll want to push your changes back to server. The typical usages of Git are supported in Visual Studio – code that you’ve modified will be marked with a checkmark, and you can (for example) create a commit (which I tend to think of as a local shelveset, being used to TFS) by right-clicking on a changed file in the solution explorer and choosing Commit, or by using the Changes pane in Team Explorer, as shown below:


Team Explorer also lets you push your changes back to the server at the same time (and bring down any other changes pushed by others) by choosing Commit and Sync, or you can do that separately afterwards from the Unsynced Commits pane in Team Explorer by either doing a full synch with the server, or else pushing individual commits:


Changes that you push will also be reflected on the CodePlex site, and you can also see them in Visual Studio by choosing the View History… action in the Changes pane in Team Explorer:


It’s a brave new world

And so, a new chapter begins for the C# and VB compilers, which will lead to more innovation, more transparency, and the strongest .NET experience for everyone involved. We are really looking forward to partnering together with you in that environment!

As part of that partnership, I want to note that hearing back from you on the preview and the open source code is really important to us, and is what will lead to the best products for you. Furthermore, the (anonymous) telemetry coming back from preview will be of tremendous help as well to gauge the performance and reliability of the code. The Discussions and Issues tabs on the Roslyn CodePlex site are great places to make your voice heard, as well as the comments sections in this blog and the Connect site. The MS Open Tech site is a great place to learn more about their open source investments and to provide feedback about that. Finally, I encourage you look at the HelpCustomer Feedback Options dialog in Visual Studio to learn more about on how your telemetry information is used.

There is no doubt that there’s still a lot for us to learn about being part of the open source community, but we’re glad to have all of you along for that ride.

Now, go off and have fun with the preview and the codebase!

--Matt & the Managed Languages Team

Author: "CSharpFAQ" Tags: "roslyn, MS Open Tech, Open Source"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 15 Jan 2014 17:36

(For the next few posts, I’m going to introduce readers to the different feature teams in the Managed Languages org.  Today, I’m starting this with a focus on the performance team.)

Back in 2000, I found myself assigned to be the performance lead of the Visual Basic team, and my first assigned goal was to drive the performance marks of the (then) forthcoming Visual Basic .NET to be in line with the numbers for Visual Basic 6.0.  The primary focus was on the VB runtime APIs at first.  That was a relatively simple task; APIs are nicely discrete bits of code, easy to measure and easy to evaluate and so, within a couple of months, I’d worked with the team to get the APIs at parity (or better).   “Ah,” said I, “this performance work is so simple that I wonder why everyone is challenged by it.  I must have a special gift for performance or something!”

This peculiar form of self-delusion lasted about a week, until the next challenge arose, which involved improving the shutdown speed of Visual Basic .NET itself, which was taking over a minute for large solutions.  That functionality was not in code that was nicely constrained like APIs, and so it took me a long time (probably longer than it should have, in retrospect) to realize that the process was blocking on background compilation even when shutting down, instead of just abandoning the compilation altogether.  And, having fixed that, I then moved on to tuning F5 build times, which involved several threads all needing to get their tasks done quickly and yet in a semi-serial fashion.  None of them were operating incorrectly with respect to themselves; it was the combination of them that were causing slowdowns.  That took days and days of investigation (and a lot of collaboration among several teams) to lock down.  In that investigation, I encountered the blunt truths about performance:  there is no perfect solution to a general performance problem, and also that you are never truly done tuning your product, because other dependent code can and will change around you. 

Which brings us to 2014…

Now, in the intervening 14 years, the tools to evaluate performance have of course become more powerful, and we can find and address issues far faster than in days of yore, when code inspection & stopwatch timing was roughly 75% of the job.  At the same time, however, the applications themselves have become so complex (either internally or with respect to the environment in which they run) that solving problems after the fact still creates a big challenge.  In fact, it’s become even more imperative to design for performance up front, because there are more ways than ever to get whammied.  During my recent stint in XBOX, for example, my team over there worked hard to generate performant code for the back end of SmartGlass, only to discover near the end that we hadn’t accounted for the inherent latency of using SSL between us and the data store – it was not a code issue per se, but a limitation of the environment that we hadn’t properly designed for.  (Fortunately, our design was modular enough that we were able to put in some caching at relatively low cost to the project and still meet our performance goals on schedule!)

As we all know and as I allude to above, you’ll save a lot of time and effort if you design for performance in the first place.  That’s always been a Microsoft tenet (indeed, our interview questions often touch upon generating performant code), and we take it very seriously on the Managed Languages team.  But, since some performance issues will slip through just due to human nature, and since designs which seemed good at first may prove to be problematic afterwards, ongoing vigilance is paramount – constant monitoring is the key to success. 

Performance and Roslyn

With Roslyn, therefore, we treat performance exactly as if it was a feature area which plans for specific work and which has progress presented to the team at each end-of-sprint showcase.  It was designed for performance up-front, and during development we’ve constantly re-assessed & re-tuned the architecture to make it adhere to the goals that we’ve set for it.  We have a performance lead (Paul) who runs a performance “v-team” (virtual team) drawn from the ranks of Managed Languages engineers as needed, and who works with a “performance champ” (Murad), telemetry champ (Kevin), and perf PM (Alex) to oversee the state of our performance on a daily basis. 

This performance v-team has goals that it needs to meet and/or maintain, and these goals are drawn from the metrics of the most recently shipped product.  This v-team is directly accountable to me, Manish, and Devindra (the latter two are our test manager and group program manager, respectively), and the three of us meet with the v-team every week to assess the previous week’s performance efforts and to create goals for the upcoming week.  (We then are furthermore accountable to our upper management for meeting goals – and believe me, they are very serious about it!)  The v-team also work with other teams in Visual Studio to find “wins” that improve both sides, and have been very successful at this.

As with any other product, performance is assessed with respect to two main categories: speed of operation and usage of memory.  Trading off between the two is sometimes a tough challenge (I have to admit that more than once we’ve all thought “Hmm, can’t we just ship some RAM with our product?” :-)), and so we have track a number of key scenarios to help us fine-tune our deliverables.  These include (but are not limited to):

  • Build timing of small, medium, and (very) large solutions
  • Typing speed when working in the above solutions, including “goldilocks” tests where we slow the typing entry to the speed of a human being
  • IDE feature speed (navigation, rename, formatting, pasting, find all references, etc…)
  • Peak memory usage for the above solutions
  • All of the above for multiple configurations of CPU cores and available memory

These are all assessed & reported daily, so that we can identify & repair any check-in that introduced a regression as soon as possible, before it becomes entrenched.  Additionally, we don’t just check for the average time elapsed on a given metric; we also assess the 98th & 99.9th percentiles, because we want good performance all of the time, not just some of the time.

We also use real-world telemetry to check our performance, both from internal Microsoft users as well as from customers.  While automated metrics are all well and good, and very necessary for getting a day-to-day check on the performance of the project, “real world use” data is very useful for understanding how the product is actually running for folks.  When the metric values conflict (for example, on typing), this leads us to improve the automated tests, which in turn makes it easier for us to reliably reproduce any problems and fix them. So, whenever you check that box that allows Visual Studio to send data to us, you are directly helping us to improve the product!

So, hopefully this gives you a bit of an insight into the performance aspects of our work.  In the next post in a couple of weeks, I’ll talk a bit about how language planning works.

‘Til next time,


Author: "CSharpFAQ" Tags: "roslyn, performance"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 20 Dec 2013 17:33

As I mentioned in my previous blog post, we ended up with a little too much time between previews, to our subsequent embarrassment. In fact, it came to our attention recently that the licensing for the most “recent” CTP (and admittedly I use the term “recent” loosely, given that it was released in September 2012) is set to expire on January 1st, 2014.   

We don’t really want to reopen a 15-month-old deliverable to update the license, particularly when the code involved is completely out-of-date and we’re working on a plan to resume previews anyway (as I also mentioned in the earlier blog).  But, we know that some of you are still using it (it being the only game in town for the moment).  So, we’ve worked with our legal eagles to craft a new license which you can download separately in order to continue using the preview legally after the turn of the New Year, and you can find it at http://www.microsoft.com/en-us/download/details.aspx?id=41551.

However, I want to add that the intent of this post is not to introduce new users to the old preview.  Frankly, that code is so old and divergent from the current code that there’s minimal insight to be gained by perusing it (and any feedback on it will be nearly useless to us as well).  Its value is primarily only to those who have some ongoing experiments that they aren’t prepared to shut down yet.  So, if you haven’t jumped on the Roslyn train yet, I’d consider holding off from downloading that old September 2012 preview, and waiting a little longer.  Yeah, I know that’s big talk coming from a team which hasn’t uploaded a new preview in ages, but we’re committed to getting these going again.  Subsequent previews will be way cooler, way more useful, and far more relevant from a feedback point of view.

(I’m heading out on holidays right after I push “post” on this, but will check comments when I’m back in a couple of weeks.)

‘Til next time,


Author: "CSharpFAQ" Tags: "roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 16 Dec 2013 19:37

So, the entryway to my house has eight light switches along the wall.  Two of them control the porch lights, and another two work the same entryway light (despite the switches being only a couple of feet apart).  I haven’t the foggiest idea what the rest of the switches do.  I’ve been scared to try them out, actually.  (I worry that one day I’ll accidentally throw one of them and find out later that my couch is missing or something odd like that.)

However, I am pleased to announce that we’ve turned on quite a different switch here on the Managed Languages team, with very successful results!  As many of you know, we’ve been diligently working on a replacement for our VB & C# compilers (and certain IDE pieces that leverage them) which is code-named “Roslyn.”  Roslyn introduces a far more open model for compilation, which will allow developers to reach inside the compiler itself and see the world (or, at least, solutions and projects) as it does; this, in turn, will lead to far richer IDE and diagnostics being able to be developed at considerably reduced effort and cost. 

And now, we’ve turned on The Big Switch in the Visual Studio organization and turned on Roslyn!

The Big Leap Forward

Specifically, I’m pleased to announce that everyone in the Visual Studio organization is using Roslyn in their daily work now.  In fact, the daily builds of VS are now compiled using Roslyn, all as part of a process that we refer to in the biz as “dogfooding.” 

Now, this change wasn’t trivial and, as with the mysterious light switches in my entryway, there was a lot of caution involved before we got to the point where Anders ceremoniously turned on the switch and enabled Roslyn for the division.  Although we are part of the Visual Studio org, in many ways the rest of the VS org is like a customer to us as well, and so we had to be really careful not to derail any teams in our enthusiasm to reach this milestone.  (For some reason, the other teams feel that their work is important, too… go figure.) 

So, earlier this year, we engaged the toughest bunch of critics we could find (that is, the other VS test teams), and asked them to do several weeks of hard-core tests against their code – essentially, every test that they already had plus new ones specifically designed for this situation.  At the same time, we ran and re-ran all sorts of performance tests to ensure that we wouldn’t be slowing down either developers or our build lab.  We did a walking tour of the rest of the org and got them educated on the changes that Roslyn would bring.  We compiled & assessed over 60,000 projects, large and small, both internal and external to Microsoft (including flagship Microsoft products).  We fixed whatever blocking bugs we found as a result of all of that and then, at the end of October, we switched the entire division to using Roslyn bits.  I’m happy to say that all that prep work set up us well – since The Big Switch, we’ve run into no major issues! 

So… you’re done?

Not quite.  “Dogfooding” is a prelude to being done, but there’s still a bit of polish to put on before the new code is truly complete.  Nevertheless, we are at the state where Roslyn is highly usable for daily work.  It’s a huge milestone and essentially says that we’ve turned the corner.  There’s no going back now!

So, then, when can we see it?

As you may know, our last generally-available preview for Roslyn was September 2012.  No, that year is not a typo.  Yeah, we do feel a bit embarrassed about that.  Yes, we’ve been a little quiet.  No, there was nothing wrong going on here, things were actually going extremely well, it’s just that we’ve just been really heads’ down and focused on The Big Switch and…

Oh, to heck with the excuses, and let me just tell you what we’re doing. 

Now, of course, I can’t ever reveal shipping plans in a casual blog post like this, because I want to keep my job that’s someone else’s story to tell.  However, if you can keep a secret, I’ll tell you this much:  we’re now actively working through the details on starting up regular previews again.  The code is in a really nice state these days, and we can hardly wait to show you what we’ve been up to as we’ve been solidifying Roslyn!  (But don’t tell anyone that I told you.  This is just between you and me.) 


We wish you all the best for the New Year – 2014 is going to be an exciting year for us all vis-à-vis Roslyn.  We’re delighted to have you along with us on the journey! 

‘Til next time,


Author: "CSharpFAQ" Tags: "roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 17 Jul 2013 21:39

As you can see in the VS2013 Preview, we have not added new language features to C# and Visual Basic in the next version of Visual Studio. I’d like to share our thinking on this. There are essentially two main reasons why we chose not to evolve the languages this time around.

The most important is that we just shipped new versions of these two languages less than a year ago, with support for asynchrony being a major new and impactful language feature in both. Developers are still learning how to integrate and benefit from the asynchrony shift in languages and APIs. We are very excited about the quicker pace of release for VS, but we believe from experience that language versions need a little more time to settle in. Our current thinking therefore is that C# and Visual Basic should stay closer to the pace they have been on for the past decade. It’s a balance between providing stability and new value, and we feel like we already have that balance about right.

There is a more tactical reason for us as well, which is that we are nearly done reimplementing the compilers and language services for C# and Visual Basic from the ground up. You may have heard of this effort as the Roslyn project, and there will be many end user benefits to this work when it ships. From our internal perspective on the language team, the new infrastructure makes it vastly easier to implement and test new language features with confidence, quality and great tooling. While the old compiler infrastructure is rock solid and supports VS 2013 beautifully, any effort we spend implementing new language features on it takes away from investing in the tooling, language features and compiler APIs that will power the future.

We are actively working on the next versions of C# and Visual Basic. The language design team is in full gear, led by Anders Hejlsberg as usual, and we are considering lots of new language features, big and small. We are looking very much forward to sharing more details about this work as the ideas mature, and to ultimately ship these new language features in a future version of Visual Studio.

In the meantime, do enjoy VS 2013, and not least the improved async debugging!

Mads Torgersen

About the Author

Mads Torgersen is the program manager for the C# language design and specification, and is also on the VB and TypeScript language design teams.

Author: "CSharpFAQ" Tags: "C#, Visual Basic, Language Features, VB"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 17 Sep 2012 16:02

Following last Wednesday’s official launch of Visual Studio 2012, we’re excited to announce that the Roslyn September 2012 CTP is now available for download and provides support for VS 2012 RTM. Please note that Visual Studio 2010 is no longer supported by this CTP.

We’ve been hard at work since the first public release of Roslyn adding support for new language features and improving our APIs. In addition, we’ve also updated our NuGet packages to match the September 2012 CTP.

As always, your feedback is critical! Please get involved in the discussion on the Roslyn forum, file bugs on Connect, or just give us a shout-out on Twitter @ #RoslynCTP!



Dustin Campbell


About the Author

Dustin Campbell is a Program Manager responsible for the C# and VB language experiences on the Roslyn project.

Author: "CSharpFAQ" Tags: "IDE, C#, C# compiler, roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 26 Jun 2012 16:00

by Alan Berman

The Async feature in Visual Studio 2012 RC makes it easy to invoke asynchronous methods.

If you mark a method with or async modifier, you can use the await operator in the method. When control reaches an await expression in the async method, control returns to the caller, and progress in the method is suspended until the awaited task completes. When the task is complete, execution can resume in the method.

Using asynchronous methods instead of synchronous methods can provide benefits.  Asynchrony makes UI applications more responsive because the UI thread that launches that operation can perform other work.  Asynchrony also improves the scalability of server-based application by reducing the need for threads.

This blog provides a simple async example and describes what occurs when it runs. It also provides an example of exception handling for a call to an async method.

Running the Examples

To run the examples in this blog, you can do the following:

  1. Install Visual Studio 2012 RC, which can be accessed from Visual Studio Asynchronous Programming.
  2. Create WPF Application or Windows Forms Application.
  3. In your project, add a reference to System.Net.Http.  This allows you to use the HttpClient class in the first example,
  4. Add a Button to the application.  Modify the Button_Click event handler to add the async modifier.  The Button_Click event handlers in the examples are from a WPF Application, however they can be modified for a Windows Form Application.
  5. Include the following using statements.

    using System.Diagnostics;
    using System.Net.Http;
    using System.Threading.Tasks;


Example of async and await

The following example illustrates use of the async modifier and the await operator.  An explanation is provided below.  Note that startButton_Click is marked with the async modifier

    private async void startButton_Click(object sender, RoutedEventArgs e)
        Task<string> getWebPageTask = GetWebPageAsync("

        Debug.WriteLine("In startButton_Click before await");
        string webText = await getWebPageTask;
        Debug.WriteLine("Characters received: " + webText.Length.ToString());

    private async Task<string> GetWebPageAsync(string url)
        // Start an async task.
        Task<string> getStringTask = (new HttpClient()).GetStringAsync(url);

        // Await the task. This is what happens:
        // 1. Execution immediately returns to the calling method, returning a
        //    different task from the task created in the previous statement.
        //    Execution in this method is suspended.
        // 2. When the task created in the previous statement completes, the
        //    result from the GetStringAsync method is produced by the Await
        //    statement, and execution continues within this method.
        Debug.WriteLine("In GetWebPageAsync before await");
        string webText = await getStringTask;
        Debug.WriteLine("In GetWebPageAsync after await");

        return webText;

    // Output:
    //   In GetWebPageAsync before await
    //   In startButton_Click before await
    //   In GetWebPageAsync after await
    //   Characters received: 44306

Control Flow in Example

In the above example, the startButton_Click method calls the GetWebPageAsync method.  In the GetWebPageAsync method, the following occurs:

  1. The GetWebPageAsync method calls the GetStringAsync method, which returns a task.
  2. The “await getStringTask” expression causes the GetWebPageAsync method to immediately exit and return a different task.  Execution in the GetWebPageAsync method is suspended.
  3. When the awaited task (getStringTask) completes at a later time, processing resumes after the await statement in the GetWebPageAsync method.

The startButton_Click method also contains an await expression, which is “await getWebPageTask”.  Because GetWebPageAsync is an async method, the task for the call to GetWebPageAsync needs to be awaited.  startButton_Click needs to be defined with the async modifier because it has an await expression.

Return Types in Example

In the above example, the GetWebPageAsync method has a return statement that returns a string.  Therefore, the method declaration of GetWebPageAsync has a return type of Task<string>.  Because the return type is Task<string>, the evaluation of the await expression in startButton_Click produces a string, as the following statement demonstrates:  string webText = await getWebPageTask; .

Similarly, the GetWebPageAsync method calls the GetStringAsync method, which is defined with a return type of Task<string>. The call to GetStringAsync returns a Task<string> and the evaluation of the await expression produces a string.

The startButton_Click method has a return type of void.

Note:  An async method can have a return type of Task<TResult>, Task, or void.   The void return type is used primarily to define event handlers, where a void return type is required. An async method that returns void can't be awaited, and the caller of a void-returning method can't catch exceptions that are thrown by the method.

Simplified Code

In the above example, the GetWebPageAsync method includes the following two statements:

    Task<string> getStringTask = (new HttpClient()).GetStringAsync(url);
    string webText = await getStringTask;

The above two statements can be condensed into one statement, as follows:

    string webText = await (new HttpClient()).GetStringAsync(url);

The condensed statement also returns a task and awaits the task, however the task is not stored in a variable. While the condensed statement is more concise, the uncondensed code facilitates a greater understanding of the control flow of your code, and of the associated tasks.


Exception Handling

The following example illustrates exception handling for an async method. To catch an exception that applies to an async task, the await expression is in a try block, and the exception is caught in a catch block.

Uncomment the “throw new Exception” line in the example to demonstrate exception handling. The exception is caught in the catch block, and the task's IsFaulted property is set to true, and the task's Exception.InnerException property is set to the exception.

Uncomment the “throw new OperationCancelledException” line to demonstrate what happens when you cancel an asynchronous process. The exception is caught in the catch block and the task's IsCanceled property is set to true. Under some conditions that don't apply to this example, IsFaulted is set to true and IsCanceled is set to false.

    private async void testExceptionButton_Click(object sender, RoutedEventArgs e)
        Task<string> theTask = DelayAsync();

            string result = await theTask; 
            Debug.WriteLine("Result: " + result); 
        catch (Exception ex) 
            Debug.WriteLine("Exception Message: " + ex.Message); 
        Debug.WriteLine("Task IsCanceled: " + theTask.IsCanceled); 
        Debug.WriteLine("Task IsFaulted:  " + theTask.IsFaulted); 
        if (theTask.Exception != null) 
            Debug.WriteLine("Task Exception Message: " 
                + theTask.Exception.Message); 
            Debug.WriteLine("Task Inner Exception Message: " 
                + theTask.Exception.InnerException.Message); 

    private async Task<string> DelayAsync()
        await Task.Delay(100);

        // Uncomment each of the following lines to
        // demonstrate exception handling.

        //throw new OperationCanceledException("canceled");
        //throw new Exception("Something happened.");
        return "Done";

    // Output when no exception is thrown in the awaited method:
    //   Result: Done
    //   Task IsCanceled: False
    //   Task IsFaulted:  False

    // Output when an Exception is thrown in the awaited method:
    //   Exception Message: Something happened.
    //   Task IsCanceled: False
    //   Task IsFaulted:  True
    //   Task Exception Message: One or more errors occurred.
    //   Task Inner Exception Message: Something happened.

    // Output when a OperationCanceledException or TaskCanceledException
    // is thrown in the awaited method:
    //   Exception Message: canceled
    //   Task IsCanceled: True
    //   Task IsFaulted:  False


See Also


Author: "CSharpFAQ" Tags: "async, await, asynchronous programming, ..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 05 Jun 2012 19:54

Today, we're excited to announce that the Roslyn June 2012 CTP is now available for download!

Since the first public release of Roslyn, we’ve been hard at work implementing new language features, addressing top customer feedback from the Oct CTP, iterating on our API design and improving performance across our IDE and compiler scenarios.  With the recent release of Visual Studio 2012 RC, we have updated the Roslyn CTP to work with Visual Studio 2012 RC, in addition to Visual Studio 2010 SP1.  There’s never been a better time to grab the VS 2012 RC and the Roslyn CTP and start exploring with the new Roslyn Interactive window!

You can find an in-depth look at what’s new in the Roslyn June 2012 CTP on Jason Zander’s blog and the Visual Studio blog.  The CTP ships with a number of documents that provide an excellent way to get started – start with the overview document, and then move on to the walkthroughs.  We also encourage you to check out our previous series on how to use the Roslyn APIs – the syntax visualizer is an invaluable tool, the Syntax API, the Symbol API, the Scripting API, and how to write a code action

Feedback is a critical part of our design process!  Because it’s early in the project, we’re most interested in feedback around the API and understanding what scenarios you’d like to accomplish. Please get involved in the discussion about Roslyn on our forums. You can also file bugs on our Connect site. Some of the team members are also on Twitter, and will be keeping an eye on the #RoslynCTP hashtag.


Happy Coding!

Karen Ng


About the Author

Karen Ng is the Lead Program Manager responsible for the compilers, IDEs, and Languages for C#, Visual Basic, and F# at Microsoft.  Karen works on both the Visual Studio 2012 release and the Roslyn project.

Author: "CSharpFAQ" Tags: "IDE, C#, C# compiler, roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 26 Apr 2012 20:39

If you’ve held off on trying Visual Studio 11 Beta because your .NET 4 or Silverlight 5 app uses the Async CTP, your wait is over!  Today we’ve published the Async Targeting Pack for Visual Studio 11, a NuGet package that lets your Visual Studio 11 projects target .NET 4 and Silverlight 5 while taking advantage of C#’s new await keyword.  While Visual Studio 11 provides built-in support for await in projects that target .NET 4.5 or .NET for Metro style apps, this targeting pack provides the API support to expand the set of target platforms to include .NET 4 and Silverlight 5 as well.

Check out our release notes for more details on how to install NuGet and add the package reference in Visual Studio 11 Beta.

Happy testing!

Alex Turner
Program Manager, VB/C# Compilers

Author: "CSharpFAQ" Tags: ".NET Framework 4, async, await, asynchro..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 29 Feb 2012 14:55

As you may have seen in Jason’s blog, Visual Studio 11 Beta is available for download today, including the Beta version of C# 5.0!  If you’ve tried out the Visual Studio 11 Developer Preview, you already know that this is an exciting release, with two huge new features for C# developers: async methods and support for creating Windows 8 Metro style apps.  However, with Beta comes even more goodness, with support for caller info attributes, as well as a host of async perf improvements and async unit-testing support.

The best way to see what’s new in Visual Studio 11 is to dive in and try it yourself.  However, if you’re curious to know what you’re getting, read on!

Async methods (the await keyword)

As you migrate your desktop applications to mobile phones and tablets, you’re increasingly faced with the realities of network latency, especially given a reliance on cloud services running in distant datacenters.  At the same time, your users expect far more responsiveness from these applications, with the bar set by smooth touch UIs that never drop a frame.

The way out of this conundrum up to now has been asynchronous programming and the use of callbacks.  However, while callbacks can work for very simple methods, you quickly fall into the pit of despair for code that’s of any reasonable length or complexity, giving up the core control flow constructs you’ve trusted for years – chained callback methods and for loops don’t mix!

There has to be a way out of this mess, and there is – async methods in C# 5.0, powered by the await keyword:

public async Task<int?> SumPageSizesAsync(IList<Uri> uris) {
    try {
        int total = 0;
        var client = new HttpClient();
        client.MaxResponseContentBufferSize = 10000000;
        foreach (var uri in uris) {
            statusText.Text = string.Format("Found {0} bytes ...", total);
            var data = await client.GetByteArrayAsync(uri);
            total += data.Length;
        statusText.Text = string.Format("Found {0} bytes total", total);
        return total;
    catch (Exception) {
        statusText.Text = "Error!";
        return null;

By marking your method with the async keyword, the C# compiler transforms it into a resumable async method that can pause execution whenever it sees the await keyword by returning control to the caller.

  • If this is a client app, control returns to your caller at each await, and then to its caller, and so on, until you’ve freed up the UI thread, which keeps your app responsive.
  • If you’re writing a server, returning to the caller frees up the thread handling the current request, ensuring that thread is available to process other requests and increasing your scalability.

In either case, once the operation you’re awaiting completes, your method wakes up, resuming execution right where it left off, even if you were within a foreach loop or a try-catch block.  When execution is paused, you can even hit F10 to Step Over at the await, with the debugger returning you to the following line after the awaited operation completes.

This is just a brief peek at Async – if you’ve yet to try it, be sure to check out the Asynchronous Programming Developer Center for samples, videos and more to get started.  However, if you have been using Async for a while now through our previous preview releases, you’ll be excited to see what’s new in Beta!

Since the Developer Preview, we’ve done work to further improve the perf of async methods, reducing allocations to ensure you can feel comfortable using async methods throughout your application, wherever you need them.  However, such comfort also requires that you can trust your async methods to continue working as expected as you continue to make changes elsewhere in your app.  To this end, MSTest and xUnit.net now support async methods directly, ensuring that the test runner waits for the async method to fully complete:

public async Task Test1() {
    var x = await Engine.GetSevenAsync();
    Assert.AreEqual(x, 6);

public async Task Test2() {
    var y = await Engine.GetSevenAsync();
    Assert.AreEqual(x, 6);

Caller Info Attributes

One language feature that’s making its debut in Visual Studio 11 Beta is caller info attributes.  These attributes let a method accept implicit optional parameters intended to receive a line number, a file path or a member name.  Then, at the call site, the compiler will know to automatically fill in those argument values, based on the exact location where that method was called.

One great use for caller info attributes is for logging methods.  The code below defines a LogMessage method that accepts 4 parameters to output a structured log message.  However, when we call LogMessage within ProcessItem, we only need to specify one argument, message – the compiler will do the work for us to pass in the name of the method calling LogMessage, along with the file name and line number of that call site.  Even better, if ProcessItem moves around in the file, changes files, or is renamed, the log message will be updated automatically.

public void LogMessage(string message = "",
                       [CallerMemberName] string member = "",
                       [CallerFilePath] string file = "",
                       [CallerLineNumber] int line = 0)
    var s = String.Format("{1} ({2}:{3}) - {0}", message, member, file, line);

public void ProcessItem(int index) {
    LogMessage(String.Format("Processing item {0}", index));


Another benefit is when you’re implementing INotifyPropertyChanged.  Today, it’s common to write a helper method that invokes the PropertyChanged event, to which you pass the name of the property being set.  However, you must then pass that property name as a string argument within each property setter.  This adds risk when refactoring inside such classes – if you use VS to change the name of the property and all its references, you’ll have to manually update that string.

With caller info attributes, you can just call your NotifyPropertyChanged helper as below, without arguments.  The compiler will pass in the name of the property for you, which will always be up to date, even if the property is renamed:

public class Widget : INotifyPropertyChanged
    private string statusText;
    public string StatusText
        get { return statusText; }
        set { statusText = value; NotifyPropertyChanged(); }

    public void NotifyPropertyChanged([CallerMemberName] string property = null)
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(property));
   public event PropertyChangedEventHandler PropertyChanged;

Call to Action

If you’re excited to try out Metro style app development, async methods, caller info attributes and all the other performance and productivity improvements in Visual Studio 11 Beta, there’s a set of great resources available to explore:

  1. Get the bits!  The first step is to download Visual Studio 11 Beta – this page also has links to download Team Foundation Server 11 Beta and .NET Framework 4.5 Beta.  You can install Visual Studio 11 Beta on Windows 7 to get up and running quickly, or set it up on top of the Windows 8 Consumer Preview to start writing Metro style apps.
  2. Learn and explore!  Check out Jason's blog post on Visual Studio 11 Beta and .NET Framework 4.5 Beta, and then dig deeper into what’s new in Visual Studio 11 Beta.  To explore what’s new in Windows 8, first read the Building Windows 8 blog post announcing the Windows 8 Consumer Preview, and then browse the new Windows 8 app developer blog.
  3. Share your feedback!  As you build apps in Visual Studio 11 Beta, let us know what you think!  Discuss what’s working well and what could be better on the Visual Studio and Windows 8 forums, and be sure to file any bugs you find through the Visual Studio, LightSwitch, and Blend Connect sites.  Also, vote on the features you’d like to see in Visual Studio moving forward on our UserVoice site.

Most importantly, have fun with the Beta and build some awesome apps!

Alex Turner
Program Manager, VB/C# Compilers

Author: "CSharpFAQ" Tags: "async, await, asynchronous programming, ..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 06 Feb 2012 16:38

 By Brian Rasmussen

The Roslyn Services API makes it easy to implement extensions that detect and fix code issues directly in Visual Studio. The Roslyn Services API is available as part of the Roslyn CTP.

In this post we implement a Visual Studio extension that identifies calls to the extension method Count() on Enumerable, where the result is compared to greater than zero, e.g. someSequence.Count() > 0. The problem, with that code construct, is that Count() may have to enumerate the entire sequence to evaluate the result. A much better approach in this case is to call Enumerable.Any() instead.

To address this we implement a CodeIssueProvider, which detects the problem and a CodeAction, which replaces the condition with a call to Enumerable.Any() as appropriate. E.g. our code action will change someSequence.Count() > 0 to someSequence.Any().

There are a couple additional scenarios, we want to handle as well: First of all, the expression could be reversed and written like 0 < someSequence.Count(). The other special case is that the comparison could be >= 1 instead of > 0, which is essentially the same comparison as before. We want the extension to be able to handle both of these cases.

Obviously we do not want to change calls to methods called Count() unless they bind to the IEnumerable<T> extension method defined on Enumerable.

Getting Started

The Roslyn CTP ships with a number of templates designed to make it easy to get started using the Roslyn APIs. To get started we create a new project and select Code Issue from the Roslyn templates under the Visual C# section. Let’s call the project ReplaceCountWithAny.

The template generates a small, working code issue provider that will highlight words with the letter “a”. To see the sample in action let’s build and run the project created by the template. This launches a new instance of Visual Studio with the extension enabled. From the newly launched Visual Studio we create a console application and notice how the namespace and class keywords and so on are underlined by our extension.

While the sample may not be very useful as an extension to Visual Studio, it neatly sets up everything we need to get started implementing our own extension. All we have to do is replace the contents of the generated GetIssues method. Notice that there are three overloads for GetIssues. We’ll implement the overload that takes a CommonSyntaxNode as input. The remaining two overloads can be left as they are in this case.

The generated CodeIssueProvider class implements ICodeIssueProvider and is decorated with the ExportSyntaxNodeCodeIssueProvider attribute. This allows Visual Studio to import this type as an extension, which will handle the contract established by the ICodeIssueProvider interface.

Implementing GetIssues

Our GetIssues method will be invoked for every syntax node, so the first thing we need to do is filter out all the nodes we don’t want to handle. Since we are looking for expressions like someSequence.Count() > 0, we’re only interested in nodes of the type BinaryExpressionSyntax. We can instruct Visual Studio to only invoke our provider for nodes of specific type(s) by providing a list of types through the ExportSyntaxNodeCodeIssueProvider attribute. Let’s update the attribute as follows:

LanguageNames.CSharp, typeof(BinaryExpressionSyntax))]
class CodeIssueProvider : ICodeIssueProvider ...

This allows us to safely cast the provided CommonSyntaxNode to BinaryExpressionSyntax in GetIssues.

To identify the cases we want to handle we have to figure out if one part of the expression is a call to Enumerable.Count() and the other part is a relevant comparison. We’ll abstract those checks into a couple helper methods, so with that our implementation of GetIssues looks as follows.

public IEnumerable<CodeIssue> GetIssues(IDocument document, 
    CommonSyntaxNode node, CancellationToken cancellationToken)
    var binaryExpression = (BinaryExpressionSyntax)node;
    var left = binaryExpression.Left;
    var right = binaryExpression.Right;
    var kind = binaryExpression.Kind;
    if (IsCallToEnumerableCount(document, left, cancellationToken) && 
        IsRelevantRightSideComparison(document, right, kind, cancellationToken) ||
        IsCallToEnumerableCount(document, right, cancellationToken) && 
        IsRelevantLeftSideComparison(document, left, kind, cancellationToken))
        yield return new CodeIssue(CodeIssue.Severity.Info, binaryExpression.Span,
            string.Format("Change {0} to use Any() instead of Count() to avoid " +
                          "possible enumeration of entire sequence.", 

The instance of CodeIssue we return specifies a severity level, which can be Error, Warning or Info, a span, which is used to highlight the part of the source code the issue applies to, and a text describing the identified issue to the user.

Helper Methods

Let’s turn our attention to the helper methods used in GetIssues. IsCallToEnumerableCount returns true if the part of the expression we’re looking at is in fact a call to Count() on some sequence. Once again we’ll start by filtering the undesired expressions.

First of all the expression must be an invocation. If that’s the case, we’ll get the actual method call from the Expression property of the invocation. So if the expression we’re looking at is someSequence.Count() > 0 we now have the Count() part, but how do we figure out if this binds to the Enumerable type?

To answer questions like that we need to query the semantic model. Fortunately part of the input to GetIssues is an IDocument, which represents a single document in a project and solution. We can get the semantic model via the document and from there we can get the SymbolInfo we need.

With the SymbolInfo present we can check if our call binds to the desired method. Because Count() is an extension method we’ll need to handle it a bit differently. Recall that C# allows extension methods to be called as if they were part of the calling type. The semantic model represents this as a MethodSymbol with a ConstructedFrom property set to the original type. This could possibly be handled slightly better, so look out for changes in the API here.

All that remains is to figure out the declaring type for our constructed extension method. If that matches Enumerable we have found an invocation of Enumerable.Count().

The implementation looks like this: 

private bool IsCallToEnumerableCount(IDocument document, 
    ExpressionSyntax expression, CancellationToken cancellationToken)
    var invocation = expression as InvocationExpressionSyntax;
    if (invocation == null)
        return false;
    var call = invocation.Expression as MemberAccessExpressionSyntax;
    if (call == null)
        return false;
    var semanticModel = document.GetSemanticModel(cancellationToken);
    var methodSymbol = semanticModel.GetSemanticInfo(call, cancellationToken).Symbol 
        as MethodSymbol;
    if (methodSymbol == null || 
        methodSymbol.Name != "Count" || 
        methodSymbol.ConstructedFrom == null)
        return false;
    var enumerable = semanticModel.Compilation.GetTypeByMetadataName(
    if (enumerable == null || 
        return false;
    return true;

With that settled the next thing we need to look for is a relevant comparison on the other side of the binary expression and that’s the job of our IsRelevantRightSideComparison and IsRelevantLeftSideComparison helper methods.

Here are the implementations for those:

private bool IsRelevantRightSideComparison(IDocument document, 
    ExpressionSyntax expression, SyntaxKind kind, 
    CancellationToken cancellationToken)
    var semanticInfo = document.GetSemanticModel(cancellationToken).
    int? value;
    if (!semanticInfo.IsCompileTimeConstant || 
        (value = semanticInfo.ConstantValue as int?) == null)
        return false;
    if (kind == SyntaxKind.GreaterThanExpression && value == 0 ||
        kind == SyntaxKind.GreaterThanOrEqualExpression && value == 1)
        return true;
    return false;
private bool IsRelevantLeftSideComparison(IDocument document, 
    ExpressionSyntax expression, SyntaxKind kind, 
    CancellationToken cancellationToken)
    var semanticInfo = document.GetSemanticModel(cancellationToken).
    int? value;
    if (!semanticInfo.IsCompileTimeConstant ||
        (value = semanticInfo.ConstantValue as int?) == null)
        return false;
    if (kind == SyntaxKind.LessThanExpression && value == 0 ||
        kind == SyntaxKind.LessThanOrEqualExpression && value == 1)
        return true;
    return false;

 They are almost identical, but it is important that we get the both the comparison and the value correct so we don’t highlight something like Count() >= 0.

Testing the CodeIssueProvider

At this point our code issue provider can detect the issues we’re interested in handling. Compile and run the project to launch a new instance of Visual Studio with our extension enabled. Add some code and notice that calls to Enumerable.Count() are correctly underlined while method calls to other methods named Count() are not.

The next step is to provide a code action for our code issue.


To implement a code action we need a type which implements ICodeAction. ICodeAction is a simple interface that defines a description and an icon for the action and a single method called GetEdit, which returns an edit that will transform the current syntax tree. Let’s start by looking at the constructor for our CodeAction class.

public CodeAction(ICodeActionEditFactory editFactory, 
    IDocument document, BinaryExpressionSyntax binaryExpression)
    this.editFactory = editFactory;
    this.document = document;
    this.binaryExpression = binaryExpression;

An instance of CodeAction will be created for every code issue identified, so for convenience sake we just pass the arguments we need to implement the change to the constructor itself. We need an ICodeActionEditFactory to create a transformation for our newly created syntax tree. As syntax trees are immutable in Roslyn, returning a new tree is the only way we can make any changes. Fortunately, Roslyn will reuse as much of the original tree as possible and thus avoid creating unnecessary nodes.  

Furthermore we need a document to let us access both the syntax tree and the project and solution for our source code and a reference to the syntax node we want to replace.

This brings us to the GetEdit method. This is where we create a transformation, which will replace the identified binary expression node with a newly created invocation node for the call to Any(). The creation of the new node is handled by a small helper method called GetNewNode. Both are listed below.

public ICodeActionEdit GetEdit(CancellationToken cancellationToken)
    var syntaxTree = (SyntaxTree)document.GetSyntaxTree(cancellationToken);
    var newExpression = GetNewNode(binaryExpression).
    var newRoot = syntaxTree.Root.ReplaceNode(binaryExpression, newExpression);
    return editFactory.CreateTreeTransformEdit(
        cancellationToken: cancellationToken);
private ExpressionSyntax GetNewNode(BinaryExpressionSyntax node)
    var invocation = node.DescendentNodes().
    var caller = invocation.DescendentNodes().
    return invocation.Update(

The Roslyn syntax tree maintains full fidelity with the original source code, so each node in the tree may have both leading and trailing trivia representing white space and comments. I.e. we need to preserve the trivia from the original node to maintain comments and layout of the code when we exchange the nodes. We call the WithLeadingTrivia and WithTrailingTrivia extension methods to handle that.

Also, notice that GetNewNode preserves the argument list from Count(), so if the extension method was invoked with a lambda to count specific items in the sequence so will Any().

Wrapping Up

To enable our code action we need to update GetIssues in our CodeIssueProvider to return a CodeAction with each CodeIssue. Each code issue may provide a number of code actions to let the user pick between different resolutions. In this case we will just return a single code action as outlined above.

The updated part of GetIssues looks like this:

yield return new CodeIssue(CodeIssue.Severity.Info, binaryExpression.Span,
    string.Format("Change {0} to use Any() instead of Count() to avoid " +
                  "possible enumeration of entire sequence.", binaryExpression),
    new CodeAction(editFactory, document, binaryExpression));

Rebuild and run the project to launch a new instance of Visual Studio with our extension loaded. Notice that the code issue now provides a drop down with the option to invoke our code action to fix the issue.

We have implemented an extension to Visual Studio that will help us improve our code.

About the author

Brian is a Senior SDET at Microsoft working on the C# and VB language services in Roslyn. Before joining Microsoft Brian was a Microsoft MVP for Visual C# for four years. Brian can be found on Twitter (@kodehoved).

Author: "CSharpFAQ" Tags: "C#, Visual Studio, roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 06 Feb 2012 15:00

by Alan Berman

I'm intrigued by all the interesting industry apps being developed for the Kinect.  I started wondering how easy it is to start programming the Kinect using Visual Studio on a PC.  It is very easy to get started, especially since the Kinect SDK has sample applications with sample code.

Because I had bought a Kinect bundled with my Xbox and not a standalone Kinect, I needed to buy a Kinect Sensor Power Supply, which can be purchased online.  This product has a cable with a USB connector that can be plugged into a PC.

I downloaded the Kinect SDK from the Kinect for Windows download site.  After installation of the Kinect SDK, this appears in Start / All Programs.

When you choose "Kinect SDK Sample Browser", the following Sample Browser window appears.  You can run the samples and download the associated C# projects from the window.

Here's what the Kinect Explorer looks like.

In the above window, the image at the left demonstrates skeletal tracking. The same image also shows Norm Estabrook as seen from the RGB camera.  For the image at the right, depth camera data with the distance from the Kinect is translated into an image with different colors.

You can change settings by clicking the arrow at the lower left.

Here's what the Shape Game looks like.  Norm is trying to change the direction of shapes falling from the sky.  The app also supports vocal commands.

The Kinect Audio Demo looks like this.  It shows the direction of the sound source and recognizes spoken colors.

The Kinect SDK includes the C# code for these sample apps, which will help you start coding.

Another important resource is the phenomenal Getting Started videos at the Kinect for Windows Quickstart Series.  Happy coding!

Author: "CSharpFAQ" Tags: "Visual Studio 2010, C#, Kinect"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 31 Jan 2012 00:22


There's been a lot of posts on using the Roslyn CTP APIs for syntax trees, semantic binding, and IDE smart editor features. The Roslyn CTP also introduces a set of features for C# we refer to as "Interactive". These features won't be new to VB, but we plan to bring the same feature set to VB. Interactive features comprise three goals:

· Read-eval-print loop (long known as a REPL) -- to support exploring code, learning about APIs, and iterative development

· Keep simple programs simple -- just write some top-level variable declarations, statements, and function declarations, then run the code as a text-based asset without needing a solution, project, class, Main, etc.

· Roslyn Scripting APIs -- to support .NET apps hosting a C# engine to execute snippets or files of code to script the application

This post talks about the Interactive features in the Roslyn CTP, which is only supported for C# right now, but we are working on VB support for a future release.

Interactive code is a set of language and tooling features that enable customers to interactively explore and discover C# and VB readily. You do not have to create a solution, then a project, then a class, then a Main method and finally then get to write the few lines you care about. Users can open a tool window in VS and start typing code snippets to see what they do. You can build up execution context cumulatively by defining variables and functions, executing statement, defining types, and building up data structures. You can also seed the REPL's execution context from a project so that you can explore instantiating types from the project and trying out new snippets of code or develop a new function or integrity check on the data structures used in the project. This sort of development has been a hallmark of dynamic languages for decades and considered to be one of the most productive features related to dynamic languages.

Some getting started walkthroughs:

Executing Code in the Interactive Window

Seeding the Interactive Window from a WPF Project

For a quick example, using View->Other Windows->C# Interactive and starting to type a reference, you get completion:


After finishing the previous input and hitting enter to execute it, if you start to type MessageBox, you get a quick fix for inserting the 'using' and then completion to help with enter a call to Show().


When using the REPL to iteratively develop code, you may start with simple expression or statement snippets of code. You might be just checking how to call a .NET function correctly, or making a change to live code and data structures, then writing a snippet to check whether the change occurred as expected. You might build up helper functions that, for example, either help you recreate execution context for experimenting in another REPL session or help you repeat integrity checks as you experiment with an algorithm. You can save helper code away in .csx files or in your project for later evaluation and use in the REPL. Your code snippets might grow into a little program or utility that you want to run now and then, which you can save in a .csx file. You can #load .csx files in the REPL to re-execute the same code at a later time.

An important aspect of the Interactive feature set is enabling you to keep simple programs simple. If you have a quick, one-off task that just needs, say, 10-20 lines of code to open a file, manipulate some data, or test some code, you can open a .csx file and write the code you need. Then run the code with csi.exe. You do not have to jump through the VS ceremonial hoops to create a program, compile it, then execute the resulting .exe. By default, csi.exe uses the same references and 'using's that a console application uses, but you can use #r to add other references in your script file. A script file is a self-contained simple program that may have started as little snippets of code in the REPL. When you invoke csi.exe, you can pass multiple .csx files (and even .cs files) on the command line which is useful if you have a library of top-level functions you commonly use with different main scripts that use the library. The whole idea is to let you work in a simple way when simple text-based code assets are easy to manage or execute as part of a build script, file utility, etc.

Lastly, with the ability to execute snippets of code and cumulatively build up execution context, it is very natural to want to host the C# execution engine as a way to enable scripting of your .NET applications. You can then take snippets of code or files from users and execute them in a context where free identifiers are bound to public members on a host object model instance. The host application can decide what to expose to user script code for controlling the application, adding commands, or hooking events.

Scripting walkthroughs:

Introduction to Scripting

Scripting a Paint-like Application

You can download the “Roslyn” CTP and try it out today!  The REPL installs as a new tool window in VS 2010.

Author: "CSharpFAQ" Tags: "C#, roslyn, REPL"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 23 Jan 2012 17:00

by Alan Berman

The new Async feature in Visual Studio makes it easy to code asynchronous method calls. To make synchronous code asynchronous, you can simply call an asynchronous method instead of a synchronous method and add a few keywords to the code, as shown in the examples below.  You no longer need to define continuations to capture what happens when the asynchronous operation finishes, which can otherwise complicate the code.

Even with the simplicity, why make file access calls asynchronous?  Aren't they fast enough already?  Here are reasons to consider:

  • Asynchrony makes UI applications more responsive. It allows the UI thread that launches the operation to be used for other things. If the UI thread is blocked by executing code that takes a long time (i.e. more than, say, 50 milliseconds), the UI may freeze until the I/O is complete and the UI thread is again able to process keyboard and mouse input and other events.
  • Asynchrony improves the scalability of ASP.NET and other server-based applications by reducing the need for threads.  If file operations are synchronous and a hundred file access operations are happening at once, then a hundred threads are needed.  Asynchronous operations often do not require use of a thread during the wait.  They use the existing I/O completion thread briefly at the end.
  • Even though a file access operation has very low latency now, it's possible that latency may greatly increase in the future. For example, a file may later be moved to a server that's across the world.
  • The added overhead of using the Async feature is small.
  • Asynchronous tasks can easily be run in parallel.

Running the Examples

Note: The examples in this blog do not apply to Metro style apps, which are Windows 8 applications that are tailored for touch interaction and are full screen.  For information on using Async for file access in Metro style apps, see .NET for Metro style apps overview and File and Stream I/O.  For some good examples of Metro file I/O, you can download the File Access Sample provided on the Dev Center.

The examples below run in either Visual Studio 11 Developer Preview or the Async CTP for Visual Studio 2010 SP1.  Both can be accessed from Visual Studio Asynchronous Programming. If you use the Async CTP for Visual Studio 2010, add a reference to AsyncCtpLibrary.dll, which is in My Documents\Microsoft Visual Studio Async CTP\Samples.

Include the following using statements in the console examples below.

using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Threading.Tasks;

Use of the FileStream Class

The examples below use the FileStream class, which has an option that causes asynchronous I/O to occur at the operating system level.  In many cases, this will avoid blocking a ThreadPool thread.  To enable this option, you must specify the useAsync=true or options=FileOptions.Asynchronous argument in the constructor call.

StreamReader and StreamWriter do not have this option if you open them directly by specifying a file path. StreamReader/Writer do have this option if you provide them a Stream that was opened by the FileStream class. Note that asynchrony provides a responsiveness advantage in UI apps even if a thread pool thread is blocked, since the UI thread is not blocked during the wait.

Writing Text

The following example writes text to a file.  At each await statement, the method immediately exits.  When the file I/O is complete, the method resumes at the statement following the await statement.  Note that the async modifier is in the definition of methods that use the await statement.

static void Main(string[] args)
    Console.Write("Done ");

static Task ProcessWrite()
    string filePath = @"c:\temp2\temp2.txt";
    string text = "Hello World\r\n";

    return WriteTextAsync(filePath, text);

static async Task WriteTextAsync(string filePath, string text)
    byte[] encodedText = Encoding.Unicode.GetBytes(text);

    using (FileStream sourceStream = new FileStream(filePath,
        FileMode.Append, FileAccess.Write, FileShare.None,
        bufferSize: 4096, useAsync: true))
        await sourceStream.WriteAsync(encodedText, 0, encodedText.Length);

Reading Text

The following example reads text from a file.  The text is buffered and, in this case, placed into a StringBuilder.  Unlike in the previous example, the evaluation of the await produces a value.  The ReadAsync method returns a Task<Int32>, so the evaluation of the await produces an Int32 value (numRead) that is returned after the operation completes..

static void Main(string[] args)
    Console.Write("Done ");

static async Task ProcessRead()
    string filePath = @"c:\temp2\temp2.txt";

    if (File.Exists(filePath) == false)
        Console.WriteLine("file not found: " + filePath);
    else {
        try {
            string text = await ReadTextAsync(filePath);
        catch (Exception ex)

static async Task<string> ReadTextAsync(string filePath)
    using (FileStream sourceStream = new FileStream(filePath,
        FileMode.Open, FileAccess.Read, FileShare.Read,
        bufferSize: 4096, useAsync: true))
        StringBuilder sb = new StringBuilder();

        byte[] buffer = new byte[0x1000];
        int numRead;
        while ((numRead = await sourceStream.ReadAsync(buffer, 0, buffer.Length)) != 0)
            string text = Encoding.Unicode.GetString(buffer, 0, numRead);

        return sb.ToString();

Control Flow

While it's easy to make method calls asynchronous, it helps to know what actually happens when the program reaches an await statement.

The original example had the statement "await sourceStream.WriteAsync...".  That's a contraction of  these two statements:  "Task theTask = sourceStream.WriteAsync…" and "await theTask".  The first statement causes a task to be returned and file processing to start.  The second statement with the await causes the method to immediately exit (returning a different task).  When the file processing later completes, execution returns to the statement following the await.

The following example does the same thing as the "Writing Text" example, however it splits the await statement into two statements and adds console output to assist in understanding the sequence.

static void Main(string[] args)
    Console.Write("Done ");

static Task ProcessWrite2()
    string filePath = @"c:\temp2\temp2.txt";
    string text = "Hello World\r\n";

    Task theTask = WriteTextAsync2(filePath, text);

    ShowInfo(theTask, "In ProcessWrite2 before wait");
    return theTask;

static async Task WriteTextAsync2(string filePath, string text)
    byte[] encodedText = Encoding.Unicode.GetBytes(text);

    using (FileStream sourceStream = new FileStream(filePath,
        FileMode.Append, FileAccess.Write, FileShare.None,
        bufferSize: 4096, useAsync: true))
        Task theTask = sourceStream.WriteAsync(encodedText, 0, encodedText.Length);

        ShowInfo(theTask, "In WriteTextAsync2 before await");
        await theTask;
        ShowInfo(theTask, "In WriteTextAsync2 after await");

static void ShowInfo(Task theTask, string message)
    Console.Write(message.PadRight(32) + " ");
    Console.Write("task " + theTask.Id.ToString() + " ");

// Console output:
// In WriteTextAsync2 before await task 1
// In ProcessWrite2 before wait task 2
// In WriteTextAsync2 after await task 1
// Done


Parallel Asynchronous I/O

The following example demonstrates parallel processing by writing 10 text files.  For each file, the WriteAsync method returns a task.  Each task is added to a list of tasks.  The "await Task.WhenAll(tasks)" statement exits the method and resumes within the method when file processing is complete for all of the tasks.

For the Visual Studio 2010 Async CTP, use TaskEx.WhenAll instead of Task.WhenAll.

The example closes all FileStream instances in a finally block after the tasks are complete. If each FileStream was instead created in a using statement, the FileStream might be disposed of before the task was complete.

Note that any speedup is almost entirely from the parallel processing and not the asynchronous processing.  The advantages of asynchrony are that it does not tie up multiple threads, and that it does not tie up the user interface thread.

static void Main(string[] args)
    Console.Write("Done ");

static async Task ProcessWriteMult()
    string folder = @"c:\temp2\";
    List<Task> tasks = new List<Task>();
    List<FileStream> sourceStreams = new List<FileStream>();

    try {
        for (int index = 1; index <= 10; index++)
            string text = "In file " + index.ToString() + "\r\n";

            string fileName = "thefile" + index.ToString("00") + ".txt";
            string filePath = folder + fileName;

            byte[] encodedText = Encoding.Unicode.GetBytes(text);

            FileStream sourceStream = new FileStream(filePath,
                FileMode.Append, FileAccess.Write, FileShare.None,
                bufferSize: 4096, useAsync: true);

            Task theTask = sourceStream.WriteAsync(encodedText, 0, encodedText.Length);

        await Task.WhenAll(tasks);

    finally {
        foreach (FileStream sourceStream in sourceStreams)

The WriteAsync and ReadAsync methods allow you to specify a CancellationToken, which can be used to cancel the operation mid-stream.  The Simultaneous Async Tasks blog has an example of cancellation.  Additional information is provided in the Cancellation topic.

Thanks to Stephen Toub for providing technical guidance.

See Also 


Author: "CSharpFAQ" Tags: ".NET Framework, C#, parallel-programming..."
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader