• 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: 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:

clip_image001_thumb[2]

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

clip_image002_thumb[1]

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.

clip_image003_thumb[2]

(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:

clip_image004_thumb[1]

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).

clip_image005_thumb[1]

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))
            {
                Console.WriteLine(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))
            {
                Console.WriteLine(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.

clip_image006_thumb[2]

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.)

clip_image007_thumb[1]

  • 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:

clip_image008_thumb[1]

  • 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:

clip_image009_thumb[1]

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:

clip_image011_thumb[1]

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

clip_image012_thumb[1]

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.)

ADVANCED USAGE

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);
                   break;

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 == '«')
            {
                TextWindow.AdvanceChar();
 

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 == '«'))
                    {
                        TextWindow.AdvanceChar();
                        break;
                    }

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();
             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:

clip_image013_thumb

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:

clip_image014_thumb

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:

clip_image015_thumb

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,

  --Matt--*

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,

 --Matt--*

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.) 

Onward!

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,

  --Matt--*

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!

 

Enjoy!

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("
http://msdn.microsoft.com");

        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();

        try 
        { 
            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

Resources

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:

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

[Xunit.Fact]
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);
    Debug.WriteLine(s);
}

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

   
DoSomeWork();
}

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:

[ExportSyntaxNodeCodeIssueProvider("ReplaceCountWithAny"
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.", 
                          binaryExpression));
    }
}
 

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(
        typeof(Enumerable).FullName);
 
    if (enumerable == null || 
        !methodSymbol.ConstructedFrom.ContainingType.Equals(enumerable))
    {
        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).
        GetSemanticInfo(expression);
 
    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).
        GetSemanticInfo(expression);
 
    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.

CodeAction

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).
        WithLeadingTrivia(binaryExpression.GetLeadingTrivia()).
        WithTrailingTrivia(binaryExpression.GetTrailingTrivia());
    var newRoot = syntaxTree.Root.ReplaceNode(binaryExpression, newExpression);
 
    return editFactory.CreateTreeTransformEdit(
        document.Project.Solution,
        syntaxTree,
        newRoot,
        cancellationToken: cancellationToken);
}
 
private ExpressionSyntax GetNewNode(BinaryExpressionSyntax node)
{
    var invocation = node.DescendentNodes().
        OfType<InvocationExpressionSyntax>().Single();
    var caller = invocation.DescendentNodes().
        OfType<MemberAccessExpressionSyntax>().Single();
    return invocation.Update(
        caller.Update(caller.Expression, 
        caller.OperatorToken, 
        Syntax.IdentifierName("Any")),
        invocation.ArgumentList);
}

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:

clip_image002

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().

clip_image004

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)
{
    ProcessWrite().Wait();
    Console.Write("Done ");
    Console.ReadKey();
}

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)
{
    ProcessRead().Wait();
    Console.Write("Done ");
    Console.ReadKey();
}

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);
            Console.WriteLine(text);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}

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);
            sb.Append(text);
        }

        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)
{
    ProcessWrite2().Wait();
    Console.Write("Done ");
    Console.ReadKey();
}

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.Write("\n");
}

// 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)
{
    ProcessWriteMult().Wait();
    Console.Write("Done ");
    Console.ReadKey();
}

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);
            sourceStreams.Add(sourceStream);

            tasks.Add(theTask);
       }
    
        await Task.WhenAll(tasks);
    }

    finally {
        foreach (FileStream sourceStream in sourceStreams)
        {
            sourceStream.Close();
        }
    }
}

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 

Resources

Author: "CSharpFAQ" Tags: ".NET Framework, C#, parallel-programming..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 02 Dec 2011 20:56

by Brian Rasmussen

In this post we take a look at how the Roslyn Scripting API can enable applications to evaluate code at runtime. While this has been possible since the dawn of .NET through the use of Reflection, Lightweight Code Generation, CodeDom, etc., it has never been particularly easy. All of these mechanisms are either hard to use, require MSIL knowledge, or just have inherent limitations.

Roslyn not only makes dynamic code evaluation a lot easier, it also provides the necessary APIs to implement a fully featured scripting experience. This post covers the basics of the Scripting API in Roslyn. For an example of how Roslyn can be used to implement a rich environment for entering and executing code at runtime take a look at the C# Interactive window implemented in the Roslyn CTP. The C# Interactive window provides syntax highlighting, intellisense, and even refactoring for code supplied at runtime.

This post uses C# as an example because that is what Roslyn supports for scripting in this first CTP. 

The Basics

Let’s start by looking at a very simple example. Let’s just execute some code dynamically. To do that all we need is an instance of the ScriptEngine class. Specifically we need the C# version defined in Roslyn.Scripting.CSharp. All we have to do is create an instance of ScriptEngine and call the Execute method with the code to be evaluated. The Roslyn scripting version of Hello World is as simple as:

using Roslyn.Scripting.CSharp;
 
namespace RoslynScriptingDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            var engine = new ScriptEngine();
            engine.Execute(@"System.Console.WriteLine(""Hello Roslyn"");");
        }
    }
}

The solution needs references to Roslyn.Compilers and Roslyn.Compilers.CSharp.

Notice, we did not have to use APIs that take MSIL or that carefully build up a tree of code that then needs to be compiled and executed. We can simply send the ScriptEngine text snippets of the code we write all the time. The ScriptEngine takes care of the rest to execute it.

Execution Context

Unfortunately the code above does have a few limitations. The first of which is that there’s no cumulative execution context, so if we define a variable as part of one code snippet and then try to access the variable from another code snippet, we will get an exception. For example, if we change the body of Main to something like this:

var engine = new ScriptEngine();
 
engine.Execute(@"var a = 42;");
engine.Execute(@"System.Console.WriteLine(a);");

We will get a compilation error from the scripting engine as the statements are treated as separate compilations. Fortunately, the Scripting API provides the Session type that can be used as an execution context when calling Execute. A session stores the context of a series of submissions, so by providing a session we can execute the code above and get the expected result.

using Roslyn.Scripting.CSharp;
using Roslyn.Scripting;
 
namespace RoslynScriptingDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            var engine = new ScriptEngine();
            var session = Session.Create();
 
            engine.Execute(@"var a = 42;", session);
            engine.Execute(@"System.Console.WriteLine(a);", session);
        }
    }
}

We can even define a new method, store it in the session, and then invoke it like this.

engine.Execute(@"void Foo() { System.Console.WriteLine(""Foo""); }", session);
engine.Execute(@"Foo();", session);

Interacting with the Host Application

However, we still cannot interact with the hosting application. Obviously scripting is of limited use if the user supplied code cannot interact with the application somehow. To address this we need to provide a host object to the session.

The code submissions will automatically have access to any public members of the host object. To supply a host object, we pass in an instance of any type we would like to use as an interface between the host application and the session. Furthermore, we have to make the ScriptEngine aware of this type as well. To do that we pass in a reference to the assembly defining our host object type. With that the setup code now looks as follows:

var hostObject = new HostObject();
var engine = new ScriptEngine(new[] { hostObject.GetType().Assembly.Location });
var session = Session.Create(hostObject);

The host object can be of any type. The ScriptEngine binds any free identifier to public members of the type, as if the type's member names were globally accessible from the script. For the sake of this demo, let’s just make it as simple as possible.

public class HostObject
{
    public int Value = 0;
}

With the code above, we can now access the Value field on our hostObject instance like this:

engine.Execute(@"Value = 42;", session);
engine.Execute(@"System.Console.WriteLine(Value);", session);

Notice how the instance's members are implicitly available within the session. We simply access any public member on the instance.

The examples we have been looking at so far are really simple, so let’s round off this introduction by adding some functionality that resembles what an application might do with the scripting API. Imagine we have a Report type like the one listed below.

// This will act as our host object
public class Report
{
    // Internal state
    private readonly List<int> values = new List<int>();
    private int result;
 
    // Encapsulate the internal data structure
    public void AddValue(int value)
    {
        values.Add(value);
    }
 
    // Allow read-only enumeration of values
    public IEnumerable<int> Values { get { return values; } }
 
    // User code will provide the implementation for these methods
    public Action GetValues;
    public Func<int> CalculateResult;
 
    // This method may be called by both the host application and the user code
    public void PrintResult()
    {
        var get = GetValues;
        if (get != null)
        {
            get();
        }
 
        var calc = CalculateResult;
        if (calc != null)
        {
            result = calc();
        }
 
        Console.WriteLine("The result of the calculation is {0}", result);
    }
}

The class stores an internal list of numbers and a result. It provides an AddValue method to populate the list and a read-only iterator. The result can be printed by calling the PrintResult method. User-supplied code determines how the list is actually populated and how the result is calculated.

The Report class exposes two delegate types, GetValues and CalculateResult for this purpose. When PrintResult is called it invokes the delegates to populate the list of values and calculate the result. Our simple application may look something like this:

static void Main(string[] args)
{
    var report = new Report();
    var engine = new ScriptEngine(new[] { 
        "System.Core", report.GetType().Assembly.Location });
    var session = Session.Create(report);
 
    engine.Execute(@"using System.Linq;", session);
    engine.Execute(
        @"GetValues = () => { for(int i = 1; i <= 3; i++) AddValue(i); };",
        session);
    engine.Execute(@"CalculateResult = () => Values.Sum();", session);
 
    report.PrintResult();
}

Admittedly this is still a simple example, but it does illustrate how script code can be used to customize our host application.

Notice how we can assign anonymous methods to the delegate members, and the host application can call them. Also, notice how we can access the LINQ extension method Sum in the user supplied code. To enable this we need to let ScriptEngine reference System.Core and import the System.Linq namespace.

That completes the overview of how to use Roslyn to add scripting support to an application. For more information on the Roslyn Scripting API please see the walkthroughs and The Roslyn Project Overview.

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#, roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 23 Nov 2011 23:10

by Kevin Pilch-Bisson

I’m back again, to move along to the next stage of the compiler pipeline, and take a look at working with Symbols in the using the Roslyn CTP.

The Roslyn CTP’s symbol API provides a top-down view of all the symbols available. Before we get to symbols though, we need to start looking at how to give the compiler enough context to tell us about symbols. While syntax trees are mostly context free and can stand on their own, in order to learn about symbols we need to have a collection of syntax trees, the references passed to the compiler, and any options in effect. In Roslyn, we use the Compilation type to group these things together. Conceptually, a Compilation represents one invocation of the csc.exe command line, or a single project in Visual Studio.

Let’s start by creating a compilation that includes something like the simple file we used last time when talking about syntax trees:

using System;
using System.IO;
using System.Linq;
using Roslyn.Compilers;
using Roslyn.Compilers.CSharp;

class Program
{
    static void Main(string[] args)
    {
        var syntaxTree = SyntaxTree.ParseCompilationUnit(@"
class C
{
    static void Main()
    {
        if (true)
            Console.WriteLine(""Hello, World!"");
    }
}");

        var compilation = Compilation.Create("test.dll",
            syntaxTrees: new[] { syntaxTree },
            references: new []
                {
                    new AssemblyFileReference(typeof(object).Assembly.Location),
                    new AssemblyFileReference(typeof(Enumerable).Assembly.Location),
                });
    }
}
        

Aside: You’ll find that many parts of the Roslyn APIs use optional arguments, and it’s convenient to call them with named parameters. The reason for this is that we’re exposing an immutable API, so we want to allow you to specify all the options right at creation time, but we don’t want to force you to type them all. In a mutable model, we’d probably leave many of these things out of the constructors/factory methods and allow you to set them via properties.

Now that we’ve got a Compilation, what are the interesting things to do with it? Well, there are a few.

“Change” it

Like SyntaxTrees and many other parts of the Roslyn API, Compilations are immutable, so we can’t really change them. However, there are methods like AddReferences() and RemoveSyntaxTrees(), that will return a new Compilation object with those changes (just like string.Append)

Find errors and warnings

The Compilation object makes it possible for us to programmatically determine what errors and warnings exist in a piece of code. There are two different APIs for this on the Compilation object. First of all you can call GetDiagnostics, which returns all of the errors for the Compilation. This requires doing a significant amount of work (almost as much as just compiling), so it can take a while.

In addition to GetDiagnostics, the Compilation has a method named “GetDeclarationDiagnostics”. This is meant to be a somewhat less expensive call, and one that doesn’t throw away the results of its work. You can think of the declaration diagnostics as all the errors that happen outside the curly braces of method bodies and property accessors. Finding them requires completely filling out the symbol table of the Compilation, but it doesn’t require looking at method bodies. In contrast, GetDiagnostics first calculates the declaration diagnostics, and then binds each method body in turn. Keeping the fully bound form of every method would take a lot of memory for a large Compilation, and so the bound information is released once the diagnostics have been collected.

var diagnostics = compilation.GetDiagnostics();
foreach (var d in diagnostics)
{
    var lineSpan = d.Location.GetLineSpan(usePreprocessorDirectives: true);
    var startLine = lineSpan.StartLinePosition.Line;
    Console.WriteLine("Line {0}: {1}", startLine, d.Info.GetMessage());
}

Compile it!

We can write out the bytes to an assembly using Emit(). In case we want to Emit if possible, and display diagnostics if not, the Emit call returns a result that includes the diagnostics. This means that we can skip a call to GetDiagnostics before trying Emit, which means that nothing has to look at each method body twice.

using (var file = new FileStream("test.dll", FileMode.Create))
{
    var result = compilation.Emit(file);
}
        

Examine the symbol table

One of the most interesting things we can do is look at the symbol table and examine the types and members inside of it, sort of the way you would do with Reflection.

To examine every type in the Compilation, you can start with the GlobalNamespace property of the Compilation. One thing to note is that the Compilation’s GlobalNamespace is what the compiler uses when doing lookups, so it includes everything defined in the Compilation and in its references. If you want to see only things that are actually defined in the Compilation, you can look at the “Assembly.GlobalNamespace” instead. Let’s look at an example where we find every member that contains the letter “a” in its name:

ReportMethods(compilation.Assembly.GlobalNamespace);
        

and

private static void ReportMethods(NamespaceSymbol namespaceSymbol)
{
    foreach (var type in namespaceSymbol.GetTypeMembers())
    {
        ReportMethods(type);
    }

    foreach (var childNs in namespaceSymbol.GetNamespaceMembers())
    {
        ReportMethods(childNs);
    }
}

private static void ReportMethods(NamedTypeSymbol type)
{
    foreach (var member in type.GetMembers())
    {
        if (member.CanBeReferencedByName &&
            member.Name.Contains("a"))
        {
            Console.WriteLine("Found {0}", member.ToDisplayString());
        }
    }

    foreach (var nested in type.GetTypeMembers())
    {
        ReportMethods(nested);
    }
}
        

Note the handy “CanBeReferencedByName” property, which saves us from including things like accessor methods for a property, that exist in the symbol table, but which users aren’t allowed to actually name. Also, take note of the “ToDisplayString()” extension method, which allows you to generate various forms of symbol names, including some human readable ones.

Alternatively, if there is a specific type you want to find, you can use the GetTypeByMetadataName method. We needed a way to represent fully qualified names type names that include generic arity and nestedness. Rather than define our own format, we decided to use the metadata format, which means that to use this API, you’ll need to use + to separate nested types, and encode the generic arity with `n where n is the number of type arguments. For example, to look up the nested Enumerator type in List<T>, we’d use a string like “System.Collections.Generic.List`1+Enumerator”.

One question we get is that if this model is similar to reflection, why isn’t it easier to get to the System.Type for a TypeSymbol? The reason is that the compiler may be targeting a different runtime than the one that your code is running on – consider a compilation for a Silverlight project for example. There is no way to load a System.Type for some type in the reference assembly to mscorlib.dll. At best you would find the corresponding System.Type in the desktop CLR, which may or may not be what you need.

Analyze specific parts of it

It may be interesting to pick a particular expression and see what method is going to be invoked, or similar semantic questions. We’ll look at this in more detail in the next post, but if you want to get a head start, take a look at the GetSemanticModel method on Compilation, and it’s resulting SemanticModel object.

Author: "CSharpFAQ" Tags: "roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 19 Nov 2011 02:20

Hi All! A few weeks ago, we announced the Microsoft "Roslyn" CTP. I hope many of you have had a chance to download the CTP and take it for a spin :) If you haven’t, do give it a try.

To recap – in the Roslyn CTP, we are previewing a powerful set of language services APIs that you can use within your apps to reason about C# and VB code. We are also previewing IDE extensibility points for C# and VB that will allow you to build rich code refactorings, quick fixes etc. that run inside Visual Studio.

In this post, I just wanted to point out a couple of tools that you may be interested in if you are working with the CTP – the Roslyn Syntax Visualizers. You can read more about these visualizers and how to install and use them on the following blog post – http://blogs.msdn.com/b/visualstudio/archive/2011/10/19/roslyn-syntax-visualizers.aspx

The visualizers ship as samples in the CTP and allow you to visually inspect and explore Roslyn Syntax Trees (below screenshot shows an example). You can use these visualizers as debugging aids when you develop your own applications / code refactorings using the Roslyn APIs.

image

Happy Coding! :)

Shyam Namboodiripad
Software Development Engineer in Test (Roslyn Compilers Team)

Author: "CSharpFAQ" Tags: "C#, Visual Studio, C# compiler, roslyn, ..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 03 Nov 2011 21:51

By Kevin Pilch-Bisson

As promised back when we released the Roslyn CTP, here is the first of a series of blog posts that help explain the various parts of the Roslyn API. If you don’t have the Roslyn CTP, you can get it from our MSDN page, and install it on top of Visual Studio SP1 and the VSSDK. If you want to get into using the Roslyn CTP seriously, I highly recommend taking a look at the overview document, and the various walkthroughs that we’ve put together.

Properties

The Syntax API in Roslyn has three two key properties. First, it is a full-fidelity model. Every character of a source file is represented in the API, which means that it also round trips. You can parse a source file, call ToString on the resulting SyntaxTree and get the original file text back.

Key Types

The key types in the Syntax API of the Roslyn CTP are: SyntaxNode, SyntaxToken and SyntaxTrivia. SyntaxNode represents a non-terminal node in the language grammar, and is an immutable object. There are a variety of different derived types for different language elements, and also a Kind property that identifies what a particular SyntaxNode represents. SyntaxNodes are arranged into a tree, connected by the Parent and ChildNodes properties. Each type derived from SyntaxNode also includes named properties for element of that particular node type. For example, an IfStatementSyntax has properties for the IfToken, OpenParenToken, Condition, CloseParenToken, Statement, and ElseClauseOpt.

SyntaxToken objects represet the terminals of the language grammar. They never have children, but do have a Parent property that is always a SyntaxNode. For performance reasons, SyntaxToken is a struct type. You can use the Kind property to determine what sort of token something is.

Finally, things like whitespace and comments that can appear anywhere in a source file are represented as SyntaxTrivia. Each SyntaxTrivia is attached to a single token, as either LeadingTrivia or TrailingTrivia. SyntaxTrivia does not have a parent property, but it is possible to get the associated token via the Token property. Like SyntaxToken, SyntaxTrivia is a struct for performance reasons.

Parsing

Okay, enough talk, let’s see some code. First off, let’s see how we can get a hold of the SyntaxTree, and what it looks like. To start off with, you can parse some text using SyntaxTree.ParseCompilationUnit:

using System;
using System.Linq;
using Roslyn.Compilers;
using Roslyn.Compilers.CSharp;

class Program
{
    static void Main(string[] args)
    {
        var syntaxTree = SyntaxTree.ParseCompilationUnit(@"
using System;
class C
{
    static void M()
    {
        if (true)
            Console.WriteLine(""Hello, World!"");
    }
}");
        var ifStatement = (IfStatementSyntax)syntaxTree.
            Root.
            DescendentNodes().
            First(n => n.Kind == SyntaxKind.IfStatement);
        Console.WriteLine("Condition is '{0}'.", ifStatement.Statement);
    }
}
        

In this example, we parse some simple text and look at the resulting SyntaxTree. In this case, we search through the syntax tree looking for IfStatements and grab the first one we find. We cast that the the more strongly typed IfStatementSyntax type, and then we can look at the properties specific to if statements. In this case, we looked at “Statement” which is a SyntaxNode that represents the statement to execute if the condition is true.

Construction

Sometimes you don’t want to parse existing source code to build up a SyntaxTree. Instead you want to create brand new SyntaxNodes. The most common case for this is that you want to add or change some existing syntax, and you need the new things to transform to. With the Roslyn CTP, the way you create new SyntaxNode objects is through the set of factory methods on the “Syntax” class.

var newStatement = Syntax.ExpressionStatement(
    Syntax.InvocationExpression(
        Syntax.MemberAccessExpression(
            SyntaxKind.MemberAccessExpression,
            Syntax.IdentifierName("Console"),
            name: Syntax.IdentifierName("WriteLine")),
        Syntax.ArgumentList(
            arguments: Syntax.SeparatedList<ArgumentSyntax>(
                Syntax.Argument(
                    expression: Syntax.LiteralExpression(
                        SyntaxKind.StringLiteralExpression,
                        Syntax.Literal(
                            text: @"""Goodbye everyone!""",
                            value: "Goodbye everyone!")))))));
        

Here, we’re constructing a new statement to represent a call to “Console.WriteLine("Goodbye everyone!");”. As you can see, this involves specifying quite a lot of detail. That’s one of the drawbacks of a full-fidelity model, it also means that you need specify all of those details when you create things. If you look closely, you can also see that in some places I’m using C# 4.0’s named arguments. The reason for this is that many parameters in the Syntax construction APIs are defined to be optional. The reason for optional parameters is that when possible, you don’t need to specify a detail. For example, many tokens are always exactly the same (like keywords, punctuation, etc). If you omit an argument for them, a default version will be constructed for you. If you’d like, you CAN specify every token, including triva for each one.

One thing you can do to reduce the verbosity is to sneak in calls to the various Syntax.Parse?? methods for elements of structure you are building up. This way, you can inline the code you want to have in a string instead of specifying the entire structure.

Rewriting

The next major piece of functionality in the Syntax API is re-writing, or modifying syntax trees. There are two approaches to this. The simplest is to just use one of the Replace APIs on SyntaxNode. The idea is that you get back a new tree, but with one of the descendants replaced.

var newTree = syntaxTree.Root.ReplaceNode(
    ifStatement.Statement,
    newStatement).Format();

Console.WriteLine(newTree);
          
We’ve successfully replace the body of the if statement. Because the trees are immutable, the original “SyntaxTree.Root” is completely unaffected. The newTree variable really is a brand new tree, but under the covers we actually re-use a lot of the data in an invisible fashion to be more efficient both in time and memory. Of note in the sample is the call to “Format()” on the new tree, which will apply a default formatting, and ensure that there is whitespace where there needs to be for the tree to round trip.

In some cases where you want to re-write multiple nodes, you might want more control over how the tree gets changed. To support this, the Roslyn CTP includes an abstract SyntaxRewriter class. I’ll give you a simple example that rewrites the tree above so that “M” is named “Main”, but there are obviously more interesting things that can be done here:

class Rewriter: SyntaxRewriter
{
    protected override SyntaxToken VisitToken(SyntaxToken token)
    {
        if (token.Kind != SyntaxKind.IdentifierToken ||
            token.GetText() != "M")
        {
            return token;
        }

        return Syntax.Identifier("Main");
    }
}
        

And you can use it like this:

var rewriter = new Rewriter();
newTree = rewriter.Visit(newTree);
Console.WriteLine(newTree);
        

In this example, I’ve only used “VisitToken”, but there are actually a TON of “Visit” methods that you can override to rewrite specific types of nodes in a tree.

Closing

We’ve taken a brief look at some of the key concepts and types of the Syntax portion of the API in the Roslyn CTP, including parsing, constructing node from scratch, and rewriting existing nodes. Next time, we’ll move to the next stage of the compilation pipeline, and take a look at how Symbols are exposed in Roslyn.

Author: "CSharpFAQ"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 19 Oct 2011 21:00

By Kevin Pilch-Bisson

As Soma mentioned earlier, today we’ve made a Community Technology Preview (CTP) available for download! The Roslyn project is a forward looking effort to make the wealth of language understanding that the compiler generates available to developers in other scenarios. A number of us have been working hard on getting enough of these pieces put together to have something to share with you, and we’re thrilled to be able to do that today.

The foundation of this work is a new C# compiler, written in C# (and a new VB compiler written in VB too, see the VB Team blog for details). This compiler is written as a library that exposes a rich public API. Next up is a new language service written purely using that public API and exposing its own extensibility points to allow 3rd parties to do amazing things inside Visual Studio with that language understanding.

Resources

The Visual Studio blog gives a good overview of the various pieces that the CTP installs, but I thought I’d use this space to look at a little more code that uses the API.

The Roslyn MSDN page contains pointers to an overview document that explains the basic concepts in the Roslyn API in greater detail. There are also several guided walkthroughs that each dive deeper into a particular area of the API. Finally if you install the CTP, there are numerous samples installed to the “My Documents” folder that you can build, run and experiment with.

Watch this space in the next few weeks for a series of posts that will each explore one bit of the API.

Feedback

We’re very interested in your feedback about the Roslyn project! Because it’s early in the project we’re most interested in feedback about the API and general direction. Please get involved in the discussion about Roslyn on our forums. You can also file bugs on our Connect site. Finally, some of the team members are also on Twitter, and will be keeping an eye on the #RoslynCTP hashtag if that is more convenient for you.

Disclaimer

Please note: This is a technology preview and there are known limitations. While the shape of the public API surface is complete, only a subset of the C# and Visual Basic languages have been implemented at this time in the current CTP.

About the author

Kevin is a Development lead at Microsoft responsible for the C# and VB language services in Roslyn. He’s been at Microsoft for 9 years, and has spent all of it working in the language and IDE space. Kevin is a graduate of the University of Waterloo. He used to blog at http://blogs.msdn.com/b/kevinpilchbisson, but has been spending more time on Twitter (@Pilchie) and on getting Roslyn into your hands lately.

Author: "CSharpFAQ" Tags: "IDE, C#, C# compiler, roslyn"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 01 Sep 2011 00:02

By Emily Gibson

New! C# 2010 Soup to Nuts Series

Explore this webcast series on Visual C# 2010 presented by Developer Evangelist, Bill Steele. Learn about class libraries, operator basics, branching and looping, and more as Bill dives deep into this fantastic language.

Part 1: Introduction

WMV Download | Zune | WMA | MP3

Watch this Entire Series:

Part 1: Introduction
Part 2: Visual C# Express
Part 3: Class Libraries
Part 4: Visual C# Program Structure
Part 5: Language Fundamentals
Part 6: Branching and Looping
Part 7: Classes and Objects
Part 8: Operator Basics
Part 9: Basic Debugging
Part 10: Arrays and Collections

Author: "CSharpFAQ" Tags: "C#"
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