Visual Studio 11 Programming Language Advances

At the BUILD conference in September, we unveiled developer previews of Visual Studio 11, Expression Blend 5, Team Foundation Server 11, and the .NET Framework 4.5.

We’ve been working on these technologies in earnest since we shipped the previous wave of these development tools last year, and we've had the opportunity to make significant enhancements, across the IDE, frameworks, libraries, languages, and services.  Over my next several blog posts, I’ll be sharing with you some of my thoughts on big steps forward we’ve made in various areas of this development tooling, innovations that help to make developers, testers, and anyone involved in the software application lifecycle far more productive in their daily lives.

For this initial post, I’ll be focusing on programming languages and on the enhancements we’ve made both to their expressivity and supporting tooling.  Languages exist at the center of everything developers do.  Developers often pride themselves on the quality, style, maintainability, and efficiency of the code they write, and they achieve their goals using one or more of many supported languages.  As we build our development tools, we keep this mindset front and center, investing heavily in advancing the state of the art for language tooling and expressivity, and enabling developers to achieve their needs with the best code possible.

JavaScript and Interactivity

In Visual Studio 11, JavaScript becomes a first-class language for building Windows and Web applications, all supported by Visual Studio’s best-in-class tooling.  In addition to full language support for ECMAScript 5, significantly improved IntelliSense (including much better performance on large JavaScript files and much improved accuracy), editor support for operations like “Go To Definition,” and the full range of debugger support provided for Visual Studio’s other supported languages, Visual Studio now also provides new integrated debugging windows for interacting with the HTML/JavaScript application being debugged.

The new DOM Explorer window enables digging through the HTML Document Object Model (DOM) to explore and manipulate elements, styles, and more.

And the new JavaScript Console window provides a read-evaluate-print loop (REPL) for JavaScript, integrated directly into Visual Studio.  This provides a live window into the running application, supporting the evaluation of any JavaScript expression.  The results also support visualizers, as shown in the following screenshot:

As the evaluated expressions apply to the current application’s context, you can even define new functions and use those functions directly from the console window:

Of course, in addition to all the work focused on JavaScript in Visual Studio, as I previously blogged about there is a wealth of new support for designing Windows Metro style applications using HTML and JavaScript in Expression Blend 5 Developer Preview.

For more information on these new debugging windows for JavaScript, I recommend Erik Saltwell and Jeff Fisher’s BUILD talk: “Debugging your Metro style apps using HTML”.

C#, Visual Basic, and Asynchrony

Almost a year ago, I blogged about some work done in Developer Division to explore integration of asynchronous programming directly with C# and Visual Basic.  I’m excited to say that in the Visual Studio 11 Developer Preview, this is now a part of  C# 5 and Visual Basic 11.

It’s long been known that asynchronous programming is how one achieves responsive user interfaces and scalable applications, but such techniques have also been difficult to implement.  Such systems remain relatively simple when each operation involves just one asynchronous call, but as our world evolves towards one in which everything is exposed asynchronously, such operations are becoming rare.  Instead, developers are forced to write callback after callback of convoluted code in order to navigate even the most trivial of patterns, like one call being made sequentially after another.  For years, modern languages have provided us with control flow constructs that were largely unusable when writing asynchronous code.  Now, with these new async language features of C# and Visual Basic, developers are able to write asynchronous code as if it were synchronous, all the while using the myriad of control flow constructs provided by these languages, including support for loops, conditionals, short-circuiting, and more.

With these features, we’ve been able to bring Visual Studio’s debugger capabilities along for the ride.  For example, when in the debugger we “step over” (F10) a statement containing an await:

it behaves just as you’d expect it to, moving to the subsequent line in the logical control flow, even though that code is likely part of a continuation callback scheduled asynchronously under the covers.

For more information on asynchronous programming support in C# and Visual Basic, I recommend the following talks from BUILD:

C++ and Parallelism

Our teams have spent considerable energy in this release improving C++ support in Visual Studio.  This includes not only full support for the C++11 standard libraries, improved IDE support (such as reference highlighting and semantic colorization), and support for building fully-native Windows Metro style applications, but also rich new language and library support for parallelism.

I previously blogged about our efforts around C++ AMP.  This is an innovative technology new to Visual C++ in Visual Studio 11 that enables C++ developers to easily write code that leverages massively parallel accelerators (mainly GPUs) as part of their C++ projects.  In regular C++ code, a developer can use the parallel_for_each method to invoke a lambda that’s been annotated with “restrict(direct3d)”, which will cause the compiler to generate for that lambda code that targets a DirectX accelerator.  In the following example, the parallel_for_each is used to iterate through all indices of the output matrix in order to compute the product of the two input matrices

void MatrixMultiply(
    std::vector<float>& vC,
    const std::vector<float>& vA,
    const std::vector<float>& vB, int M, int N, int W)
    array_view<const float,2> a(M, W, vA);
    array_view<const float,2> b(W, N, vB);
    array_view<writeonly<float>,2> c(M, N, vC);

    parallel_for_each(c.grid, [=](index<2> idx) restrict(direct3d)
        int row = idx[0]; int col = idx[1];
        float sum = 0.0f;
        for(int i = 0; i < W; i++)
           sum += a(row, i) * b(i, col);
        c[idx] = sum;

Not only are the C++ AMP sections of code directly integrated into the source files and expressed using standard C++ syntax, Visual Studio also provides complete debugging support for these kernels, enabling basics like breakpoints and stepping, but also full support across debugger windows like Watch, Locals, and Parallel Stacks, along with the new GPU Threads and Parallel Watch windows.

C++ AMP isn’t the only parallelism-focused effort for native code in Visual Studio 11.  The C++ compiler now also automatically vectorizes loops when it determines doing so is valuable. For example, for the following code, the compiler will attempt to utilize SSE instructions on the CPU to run multiple iterations of the for loop as part of a single operation, significantly speeding up the computation: 

float a[1000], b[1000], c[1000];

for(int i=0; i<1000; i++)
    c[i] = a[i] + b[i];

The C++ compiler now also features some auto-parallelization in addition to auto-vectorization.  And the parallelism libraries included with Visual C++ have been significantly expanded, including additional concurrent data structures, parallel algorithms, and an updated tasking model similar to that used by the Task Parallel Library (TPL) in the .NET Framework.

For more information on GPU computing support in Visual C++, I recommend Daniel Moth’s BUILD talk: “Taming GPU compute with C++ AMP”.  And for a look at some of the other innovation in Visual C++, I recommend Herb Sutter’s BUILD talks “Using the Windows Runtime from C++” and “Writing modern C++ code: how C++ has evolved over the years”.

F# and Data Access

Not all languages need to support every domain and every use case equally: if they did so, there would be little need for more than one language.  Often languages end up catering to specific domains and specific styles of development, and I’m particularly excited about our investments in a language that’s a great example of this principle: F#.  With F# 2.0 in Visual Studio 2010, we provided a language focused on accelerating solutions for computationally-complex problems.  With F# 3.0 in Visual Studio 11, we continue the trend of focusing on a particular problem domain by directly integrating support for solving data-complex problems.

F# is a statically-typed language, just as are C# and Visual Basic, and this static typing provides many advantages.  It supports an improved development experience by enabling features such as accurate IntelliSense.  It can yield better performance due to more optimizations available at compile-time. It can also reduce development and testing costs by eliminating some common categories of bugs.

However, there are also times when static typing leads to needing more code than its dynamic counterpart. As a prime example, the world is extremely information rich, something that we’re experiencing more and more in our daily software lives.  All of this data typically enters our programs in a non-strongly-typed way, and it first needs to be parsed and massaged into strongly-typed objects before it’s exposed to the rest of the program.  Rather than a developer coding such import routines manually, this problem has been addressed historically by design-time code generation (e.g. a design-time tool to import a Web service description and generate the necessary proxy code). Unfortunately, there are problems with this approach.  It interacts poorly with the evolving nature of data sources, such as those on the web. It can lead to very bloated client proxies (types are generated to represent the entire schema and metadata, regardless of whether or not the client program uses them).  And it does not have a smooth integration with scripting environments, such as the F# Interactive window in Visual Studio.

With the new Type Provider mechanism in F# 3.0, such data access becomes trivial for F# programs and components. Also, because F# targets the .NET Framework, applications written in C# or Visual Basic (or any other managed language) can utilize this new functionality via an F# component.  Using an extensibility mechanism of the F# compiler, type providers in effect provide data access libraries on demand, yielding a computed space of types and methods at design-time and compile-time in a manner that supports IntelliSense and that is extensible.  F# 3.0’s libraries include type providers for OData, WSDL, and SQL (via both LINQ to SQL and LINQ to Entities), but custom type providers may also be written to target arbitrary data sources, such as SharePoint lists and WMI providers.

As an example, consider a desire to search the Netflix catalogue for a handful of people that share my “S.” moniker.  Netflix exposes an OData feed, which can then be used with the OData type provider:

open Microsoft.FSharp.Data.TypeProviders

type netflixCatalog = ODataService<"">
let netflix = netflixCatalog.GetDataContext()

query {
    for person in netflix.People do
    where (person.Name.StartsWith "S. ")
    sortBy person.Name
    take 5
} |> Seq.iter(fun result -> printfn "%s" result.Name)

Not only are we able to concisely import the relevant metadata and express the query, but we’re also able to see IntelliSense throughout the experience:

And such code can be written not only in an F# application, but also directly in the F# Interactive window:

For more information on type providers, I recommend Don Syme’s BUILD talk: “F# 3.0: data, services, web, cloud, at your fingertips”.

Next Time

As is evident from this glimpse into some of the new language features and associated tooling support in Visual Studio 11, a lot of work has gone into pushing the state of the art for what’s possible in modern development.  In future posts, we’ll explore advances in Visual Studio beyond languages, such as in the Visual Studio environment itself.


Comments (22)

  1. ERIKSSON says:


  2. Steven Bone says:

    It seems that if I add visualizer definitions to the autoexp.dat file in the 11 preview, they do not work. Is this a known issue, or is there some other way to define custom visualizers for 11?

    It appears that the file is identical to the VS 2010 version, so I would expect the visualizers I wrote for 2010 to work in 2011 as well.  The file I am editing is found at "C:Program Files (x86)Microsoft Visual Studio 11.0Common7PackagesDebugger"


  3. Frustrated says:

    Does anyone test this stuff at microsoft and ensure compatibility or do you just release garbage as fast as you write it and patch it later and/or come up with some nonsense workarounds.

    You are yet to fix all the bugs in VS 2008 or VS2010 and now releasing more software.

    I really truly hate your products. Quality is such an after thought at Microsoft here is a thought FIX WHAT YOU HAVE AND GET IT STABLE! M O R O N S

  4. toub says:

    "Steven Bone", thanks for the question.  Someone from the debugger team will be following up here shortly.

    "Frustrated", thank you for the feedback, and I'm sorry to hear of your frustrations with Visual Studio 2008 and Visual Studio 2010.  We welcome your input, and at the same time we'd appreciate it if your future responses could avoid name calling… we love having open discussions and dialogues, but such conversations need to remain respectful. Regarding bugs, are there particular bugs that are concerning and frustrating you?  We have the site specifically so that you can share your feedback on such issues in order to help us improve the technology, and for Visual Studio you can use the site at  We do spend considerable effort on testing and on compatibility for all of our development tools.

  5. Steven Bone says:

    Thanks, Stephen!  One thing I haven't been able to find is the 'official' forum for discussing the Visual Studio 11 preview… Is there a specific place that is better suited for these types of questions/potential issues?

  6. toub says:

    Hi Steven-

    There's no one official forum for all things Visual Studio 11 Developer Preview related.  You can find a bunch of related forums at:…/vsvnext

    If you're interested in Windows Developer Preview, you can use the forums at:…/windowsapps

    Otherwise, for cases where those pages don't list a forum geared towards your particular question, you can just post your question to one of the relevant forums here:…/categories

    and I expect folks there will be happy to assist.

  7. Steven Bone says:

    I posted the autoexp.dat question in the VC forum you pointed me to, thanks.  The link to the question is…/5e847744-aa01-49cd-ac47-fe32da1673a3 in case others find this when searching.

  8. Brad Sullivan says:

    Hi Steven Bone,

    The good news is that we are replacing autoexp.dat with something better.  I've responded in more detail to your question on the VS forum.  I will also respond on that forum as we make more information available.


    Brad Sullivan

    Program Manager – Visual Studio Debugger

  9. Marcello says:

    I think that Microsoft should vigorously pursue to extend the .NET language to support client side scripting, web pages styling and rendering and integrate everything in just a single language: C# , removing all together JavaScript, CSS, and HTML.

    CSS, HTML an JavaScript: these languages will introduce new bugs, lexical differences, logical inconsistencies, to the new programming metaphors, making programs more difficult to develop, maintain and debug.

    It is absolutely necessary, given the increasing influence that these technologies are having today and will have tomorrow, in a wide range of activities( economical, scientific,etc) to converge to a more homogeneous programming context:

    1. One Operating System.

    2. One Programming Language.

    3. One IDE.

    4. One Database.



  10. g@wicks says:

    Any word on compiler as a service for c# & VB

  11. g@wicks – It's great to see the excitment for C# and VB compiler as a service.  We're getting close — stay tuned to Soma's blog for the first announcement.

  12. Zemorango says:

    Visual Studio 2011 so dam slow on a dual core 2, 4gb memory, dammmm…. the designer is so slooooooowwwwww.

  13. Duke Kamstra says:

    This blog post provides trouble shooting guidance for performance issues:…/performance-troubleshooting-article-and-vs2010-sp1-change.aspx

  14. Duke Kamstra says:

    If your comment about Visual Studio performance is in regards to the Visual Studio 11 Developer Preview then please take a look at this blog post:…/an-update-on-visual-studio-performance.aspx.

  15. Chris S says:

    Are there any plans to have more intelligent Javascript dependency checking in VS2011? Right now we have to use /// <reference…> in our JS files, and inside the code infront/views we have to manually add script tags.

    The biggest feature for me would be some kind of background compiler for your Javascript, so you received warnings of possible problems – a bit like JSLint does right now.

  16. @Chris S

    Regarding warnings:

    All syntax errors and strict mode violations (if you're using strict mode) within opened JavaScript files will be reported to the Error List window.

    Regarding intelligent dependency resolution:

    If you open a JavaScript file within a Windows 8 application project, we will look to see whether there are any HTML files within the project that have a reference to it (via a <scrip> tag). If there are, we will gather a list of all other JavaScript files that are also referenced by those same HTML files. That list of JavaScript files will then be automatically referenced for you, which will give you IntelliSense without having to add any explicit <reference> comments to your file.

    Let us know if you have scenarios that aren't properly satisfied by the above features.

    Thanks for the feedback!

  17. Piyush Shah says:

    Is it a Browser specific intellisence? Does it allow to choose target browser and suggest code?

    Many times, when working with JS, developers find lot of issues on specific browser / version. If that feature is included, it would be great. If not all, it should at-least suggest for different IE versions in notmal/compatibility modes.

  18. Matt says:

    You know, I think you guys should work in LINQ capabilities to the immediate window you already have.  Some of these new features are pretty nifty, I admit, but I think making the IDE work with the languages you're already pushing would be a nicer way for us to enjoy the products we spend so much on.

  19. Karen Ng - MSFT says:

    @Matt – Thanks for the feedback regarding better LINQ support in the immediate window.  In general, we see the need to improve language support, especially for LINQ, in all our debug windows and the immediate window.  There are a number of limitations with the immediate window today. For instance, it doesn't allow multi-line statements well, which ends up being pretty key for query experiences and lambdas.  To improve that experience, we're exploring a feature called C# Interactive, which you can download a preview of that work today through the Roslyn CTP at and install for Visual Studio 2010 SP1.  So far, C# Interactive only supports a subset of the C# language, but it does support lambdas and extension methods (not queries yet).  You can use it for design-time exploration, and seed the context from a project (see the Seed Context from Project walkthrough here:…/hh543924).

  20. Novalis says:

    Does C++/CLI intellisense "return back" at 2011?

  21. toub says:

    Novalis, yes, C++/CLI has IntelliSense in Visual Studio 11 Developer Preview.

  22. Rich Steinhart says:

    To Frustrated:

    Maybe you should just get a Mac. You obviously don't have what it takes to be a Windows developer.

Skip to main content