Lucian's VBlog

Async CTP v3 – installation

Lucian Wischik, MSFT — Tue, 01 Nov 2011 00:01:00 GMT

The third version of the Async CTP was released on 31st October 2011.

The reason for releasing v3 is to address installation issues -- a recent Windows Update had conflicted with the Async CTP v2 and stopped it working, or prevented its installation in the first place. The v3 release also contains one small bugfix, to stop intermittent VB IDE crashes.

This post is to help with some common installation issues.

Run Windows Update before installing Async CTP v3, and get all updated (including Optional updates).

The Async CTP v3 can be installed over the top of Async CTP v2 (SP1 Refresh): you don’t need to uninstall it first.

Q. Why do we keep releasing updates of the Async CTP? This is the third version so far:

October 2010 – original Async CTP v1
April 2011 – Async CTP v2 (SP1 Refresh), to make it compatible with SP1 of VS2010 and fix some bugs
October 2011 – Async CTP v3, to make it work with recent product updates

The reason is that Visual Studio and .NET4 keep being updated. The Async CTP is actually a mini-fork of VS2010. Therefore, each time there’s a Windows Update which includes changes to the VB or C# compilers, then the Async CTP gets out of date: the update will break the Async CTP if you have it on your machine, and it’ll block the Async CTP from being installed on top of it. So far these conflicting updates have been coming out about once every six months, and so we’ve had to re-release the Async CTP every six months.

A quick check that the Async CTP is working

If you suspect that something’s wrong with your installation of the Async CTP, then please check the version number of these four files. (Please check all four, even if you’re not doing C# or VB or Phone development).

C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe
C:\Windows\Microsoft.Net\Framework\v4.0.30319\vbc.exe
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\msvbide.dll
My Documents\Microsoft Visual Studio Async CTP\Samples\AsyncCtpLibrary_Phone.dll

If you see the following version numbers, then the Async CTP Refresh has been correctly installed:

	csc.exe	vbc.exe	msvbide.dll	AsyncCTPLibrary_Phone.dll
Async CTP v3	4.0.30319.517	10.0.30319.517	4.0.40219.355	1.1.0.0

Q. How to find those version numbers? A. Right-click on each file and choose Properties; the version number is in the "Details" tab.

If the version numbers are incorrect

Here are some other version numbers you might find

	csc.exe	vbc.exe	msvbide.dll	AsyncCTPLibrary_Phone.dlll
VS2010	4.0.30319.1	10.0.30319.1	10.0.30319.1	absent
Async CTP v1	4.0.30319.326	10.0.30319.326	10.0.30319.326	absent
VS2010 SP1	4.0.30319.1	10.0.30319.225 10.0.30319.431	10.0.40219.1	absent
Windows Update or KB2468871		10.0.30319.233 10.0.30319.450
Async CTP v2 (SP1 Refresh)	4.0.30319.440	10.0.30319.440	10.0.40219.15	1.0.0.0
Async CTP v3	4.0.30319.517	10.0.30319.517	10.0.40219.355	1.1.0.0

I want to stress this: you should check the version numbers of all four files. Even if you think you're not going to use C#, say, you should still check all four files including csc.exe. Any discrepancy in any of the files will indicate your machine is in an incorrect state.

If Visual Studio crashes upon opening a VB/C# project

The issue is that VS2010 SP1 had a bug in NGEN. The Async CTP v3 requires that this bug have already been fixed – either by having Async CTP v2 already on the machine, or by running Windows Update and getting all updates including optional ones, or by manually installing KB2468871.

Alternatively, if you’ve already got Async CTP v3 on your machine, you can fix the bug manually: open a Developer Command Prompt, run the following command in it, and have a nice cup of tea and biscuit because it’s going to take up to an hour:

ngen update /force

Uninstallation

To uninstall Async CTP v3

This is easy: Start > ControlPanel > UninstallPrograms > ViewUpdates, search for all updates with “async” in their title, and uninstall all of them. You might see as many as five different entries that need to be uninstalled.

TIP: Although uninstall order doesn’t matter, it goes easier if you uninstall the “Visual Studio Async” updates first and the “.NET Framework Async” updates next. That’s because the uninstalling the latter will require a reboot.

To uninstall Async CTP v2 (SP1 Refresh)

The uninstall of Async CTP v2 has become broken due to a conflicting Windows Update. If you have v2 on your machine and want to install it, then you actually have to install v3 first.

To uninstall Async CTP v1 (pre-SP1 release)

If anyone still has Async CTP v1 from October 2010: we recommend to uninstall this prior to installing SP1.

If you still have problems

Please post a request for help in the Async Discussion Forums. We do monitor those forums frequently, and we may be able to help.

When you ask for help, PLEASE mention all four version numbers. That will help!

A day in the life of compiler bugfixing

Lucian Wischik, MSFT — Mon, 17 Oct 2011 20:31:18 GMT

The VB/C# team is hard at work on the Async feature... You might already have download the Async CTP yourself, or tried out async in the VS11 Developer Preview, and you might wonder: "The feature seems complete already -- so what are they still working on?" This post is about an example bug that I dealt with last week.

Most programmers trust their compilers. If their program's not behaving right, they think their own code is at fault. Even if they narrow it down to what looks like a compiler bug, they still believe it's their own fault -- maybe they think they misunderstand the language, or aren't using it right. It's a big expectation that we in the compiler team have to live up to.

Here's one bug I worked on last week. I discovered this bug because, as part of unrelated performance investigations, I tested out using "Await" in every possible position allowed by the the VB language.

Module Module1
    Sub Main()
        f().Wait()
    End Sub

    Async Function f() As Task
        Dim c As New C
        Dim t = Task.FromResult(c)

        For (Await t).i = 1 To 10
            Console.WriteLine(c.i)
        Next

        ' WHAT I EXPECT: It should print out the numbers 1 to 10
        ' WHAT I GET: it doesn't print out anything at all, and fails PEVerify
    End Function

    Class C
        Public i As Integer
    End Class
End Module

Loop control variables with side-effects

It looks weird to have an expression as the loop control variable. Nevertheless, as a historical legacy, VB allows it -- it stems from the days when the For loop didn't declare its own local variable and so always had to refer to some pre-existing variable. The important question to ask is when and how often this expression gets executed. Alas the VB language specification (c:\Program Files (x86)\Microsoft Visual Studio 10.0\VB\Specifications\1033) doesn't say. So let's resort to experiment, by making the expression have some observable side-effects:

    Dim c As New C
    Function test() As C
        Console.Write("* ")
        Return c
    End Function

    For test().i = 1 To 2
        Console.Write(c.i & " ")
    Next
    ' WHAT I GET: * 1 * * 2 * *


    Dim min = 1
    Dim max = 2
    For test().i = min To max
        Console.Write(c.i & " ")
    Next
    ' WHAT I GET: * * 1 * * 2 * *

This is unexpected! It's unexpected that the compiler executes the expression so many times, and unexpected that the exact number of times varies depending on whether the loop bounds were constants or not.

Looking at the compiler implementation, what it's doing is at the start of each iteration is it assigns to the loop control variable and then reads from the loop control variable to check whether to do another iteration. Both of these tasks involve evaluating the expression. But in the first code snippet, with constants for minimum and maximum, it knows it can skip that check the first time around.

Another strange thing is that the original code used to work fine in the Async CTP, but stopped working in the VS11 Developer Preview. The reason is that the CTP played fast-and-loose with evaluation order. It basically factored out all "Await" expressions from a statement, did them all and assigned the results to temporary variables, and then performed the rest of the statement. This was a quick-and-dirty hack to get the CTP out as soon as possible. But it results in the wrong evaluation order -- for instance, "Console.WriteLine(f() & Await g())" would evaluate g() first, then Await it, then evaluate f().

The VS11 Developer Preview got correct evaluation order in most cases, but it seems to have missed this edge case of For loops.

Fixing the bug?

It looked like it would take me about 5 days to fix this bug -- which is very long, considering that I'd like to be fixing 2 bugs a day. It would take this long because the loop comparison logic is all in the codegen phase of the compiler, well after the "async transformation". It hardly seemed worth the effort -- no one in their right mind would use this strange corner of the compiler. And VB would probably have been a nicer language if it didn't allow any side effects in its loop control variable expressions.

We can't just leave the bug unfixed. We'll have to add a new paragraph to the language spec and a new error to the compiler to say "You can't use Await in a loop control expression".

The decision to add this new error felt like an easy decision. There was no need to bring it to the "VB-Insiders", a set of elite users under Non-Disclosure Agreements with whom we discuss ideas. There was no need even to bring it to a regular VB Language Design Meeting. My call (as the VB Language Lead) was that it was sufficient just to send an email around the compiler team. Everyone agreed to just add the error.

The next step was to finalize the wording of the error message with the User Experience team, who are also in charge of writing MSDN documentation about the language. They have to pick a wording that's similar to the existing error messages, and one that can be translated into different world languages. They settled on this:

BC37060: 'Await' cannot be used in a loop control variable expression

After this, the VB IDE team asked: should we make a "quick-fix" for this error, i.e. a one-click way to automatically fix the user's code if they wrote this? The answer was "definitely not".

There we have it. Bug fixed in half a day, on schedule.

Talk: What's new in VB10 (VS2010)

Lucian Wischik, MSFT — Wed, 25 May 2011 16:13:00 GMT

Talk: What's new in VB10 (VS2010)

This talk details the new VB language features that arrived in VS2010 --

Implicit Line Continuations - http://www.unemployedunderscores.com/
Array Literals
Collection Initializers
Auto-implemented Properties
Multi-line Sub lambdas (which I used for Silverlight async)
XML-literals, XML-to-schema, LINQ [actually this was already in VS2008, but it's so good I repeated it]
Silverlight interop; responding to events
DLR silverlight interop; writing to HTML DOM
No-PIA - embedding Primary Interop Assemblies for Office interop
Co-evolution

I gave this talk at PDC09 in L.A. on 2009.11.18
- I'd just bought an old used convertible, spent two months restoring it, and for its first trip I drove down from Seattle to LA on the coastal road. This was my first ever road trip and it was fantastic! Neal Gafter put me up one night at his place San Jose, but apart from that I slept rough in a pile of leaves by the roadside each night and cooked dinner in a billy-can. I got to PDC on the morning the conference started, completely dishevelled.
- Watch the talk online
- Download source_code.zip [95k, requires VS2010]
- Download script.txt [8k]
- Download slides.ppt [1.8mb] - actually these are completely useless: it was a code-only talk.
Similar material elsewhere
- Interview with me and Lisa Feigenbaum - watch the interview "What's new in VB10" online on Channel9
- Article by Jonathan Aneja - read article "What's new in VB10" online at MSDN

Talk: How to write an [Async] connected app for Windows Phone 7.1

Lucian Wischik, MSFT — Fri, 20 May 2011 22:04:00 GMT

Talk: How to write an [Async] connected app for Windows Phone 7.1

This talk is all about writing a connected app for the Windows Phone. The talk covered:

(1) Azure/WP7 toolkit for the server-side of the phone app. Most good phone apps will need some kind of server-side component, be it for live tile updates or just to form a social community.
(2) XNA for the phone app itself (a Breakout clone) using the new Mango (7.1) phone tools,
(3) Async language feature which makes it much easier to program how the app communicates with the server -- in this case to download high-score table.

The material here is in VB, but it all works equally well with C#.

I gave a VB-specific version of this talk at TechEd 2010 in Atlanta, Georgia on 2011.06.18
- Download slides.pptx [4.8mb]
- Download script.docx [27k]
- Download source_code.zip [115k], requires VS2010+SP1+WindowsPhone7.1+AsyncCTP
- Session page online. Alas they haven't put up a video of it yet.
- To encourage people to give feedback, I donate to charity for each session eval submitted. In all 22 were submitted and so on May 24th the charity "Doctors Without Borders" got $220, half from me, half from Microsoft. Thank you Atlanta!
Sri Narayanan and I gave a C#-and-VB version of this talk at VSLive2011 in Vegas on 2011.04.19
- The talk covered exactly the same material as above.
- The audience in Vegas filled out 14 evals and so on May 20th 2011 the charity "Doctors Without Borders" got $140, half from me, half from Microsoft. That's the kind of win I like to see at Vegas!

Talk: The [Async] Future of VB and C#

Lucian Wischik, MSFT — Fri, 20 May 2011 18:29:00 GMT

Talk: The [Async] Future of VB and C#

I gave a C#-specific version of this talk at DevConnections in Las Vegas, USA on 2011.11.01

This talk is mainly about Async and goes into considerable technical depth. It also covers the new CallerInfo feature, and includes a Roslyn demo.
Download slides.pptx [3mb]
Download script.docx [29k]
Download source_code.zip [42k, requires VS2010 SP1 and Async CTP v3 and Phone Developer Tools]
To encourage people to give feedback, I donate to charity for each session eval submitted. I'm looking forward to see how many evals the DevConnections audience hand in.

I gave this talk at TechDays11 in Basel, Switzerland on 2011.05.02.
- This talk is mainly about Async, with a little about Roslyn. At PDC 2010, Anders Hejlsberg delivered talk FT09 on the same topics
- Watch the talk online
- Download slides.pptx [6.3mb]
- Download script.docx [22k]
- Download source_code.zip [16k, requires VS2010 SP1 and Async CTP]
- The audience at Basel filled out 89 evals and so on May 20th 2011 the charity "Medecins Sans Frontiers" got $890 half from me and half from Microsoft. Thank you, Basel!
I gave a VB-specific version of this talk at TechEd Europe 2010 in Berlin, Germany on 2010.11.11
- This VB-specific talk covered Iterators in VB, and VB Support for Windows Phone 7, as well as Async above. (The presentation of Async above was better than what I did here...)
- Watch the talk online
- Download slides.pptx [8mb]
- Download source_code.zip for iterators [3k, requires VS2010 SP1 and Async CTP]
- The audience in Berlin filled out 29 evals and so on on November 11th 2010 the charity "Medecins Sans Frontiers" got $290 half from me and half from Microsoft. Thank you, Berlin!

[placeholder] How to write a connected VB phone app

Lucian Wischik, MSFT — Wed, 18 May 2011 12:20:00 GMT

This blog article has been moved and enhanced:

http://blogs.msdn.com/b/lucian/archive/2011/05/20/talk-how-to-write-an-async-connected-app-for-windows-phone-7.aspx

Async CTP Refresh - mitigation strategies

Lucian Wischik, MSFT — Mon, 18 Apr 2011 14:13:00 GMT

Async CTP Refresh - mitigations when using the CTP

The preceding four blog posts have outlined the known and unknown bug areas in the CTP. Now it's time to set out some concrete mitigation strategies.

Use F# instead

F# already shipped in VS2010 with Async support. It is tried, tested, high-quality, supported, and flexible. With F# you can go ahead writing Async code without even worrying about the CTP. F# is also a great language to learn in its own right.

Run PEVerify.exe and unit tests

Running PEVerify has caught about half of the codegen bugs we've found. You should definitely use it too.

Hint: quickly launch the "VS Command Prompt (2010)" from the start menu by typing the word "Command" in the search box and picking it from the results.

And as always, run unit tests. Most of the codegen bugs show up quite clearly even with superficial unit testing. The key bugs we found which didn't (especially the race-condition bugs) have been fixed in the CTP Refresh.

Be careful of synchronization context in async Windows Phone apps

There's a known issue on Windows Phone 7 such that any Await statements will always resume on the UI thread - even if you performed the Await on a background thread. In the CTP, the "AsyncBackgroundThread" sample shows a work-around for this issue.

Avoid complicated nested awaits

A "nested await" is an await expression that occurs as a sub-expression of another expression. A good rule of thumb is this: "If I couldn't easily have rewritten my statement by pulling out all awaits onto the preceding line, then the Async CTP might not have done it right either." For instance

// OK: SIMPLE OPERATORS IN VB+C#:
var s = await f() && await g();
// is probably safe (albeit wrong order), since it can be trusted to behave like this:
var $temp1 = await f();
var $temp2 = await g();
var s = $temp1 && $temp2;

' OK: USING CLAUSES IN VB+C#:
Using x = Await g() : ... : End Using
' is probably safe, since it can be trusted to behave like this:
Dim $temp1 = Await g()
Using x = $temp1 : ... : End Using

' USE WITH CARE, AND VERIFY+TEST: LOOPS IN VB:
While Await g() : ... : End While
' Note that it must have been more complicated than just a simple rewrite:
Dim $temp = Await g()
While temp : ... : End While

// DANGER: OTHER COMPLICATED IDIOMS IN VB+C#:
f(await g()).StructField.x = f(await g()).m(ref y, await t);
// Distrust this kind of code!
// * Avoid "await" on the left hand side of an assignment
// * Avoid combining awaits with ByRef arguments
// * Avoid invoking methods on expressions involving awaits
// * Avoid "await" inside array or object initializers

Miscellaneous

Be careful of For loops in VB, and also Select Case statements. Unit-test them thoroughly and PEVerify.

In particular, non-constant "Steps" in For statements don't work. Thanks to MattMc3 for reporting this.

Async CTP Refresh - what bugs remain in it?

Lucian Wischik, MSFT — Sun, 17 Apr 2011 21:50:00 GMT

Async CTP Refresh - what bugs remain in it?

Q. How many bugs remain in the Async CTP Refresh?

A. That's hard to know. Our QA efforts have been dedicated to testing our async codebase that will be part of the next Visual Studio. We've spent far less time testing the CTP. There might be bugs in the CTP that were never visible in the real codebase. There might be (there were) bugs in the real codebase that never impacted the CTP.

The best I can do is give you an indication of the asyncs compiler bugs we've found, and which aspects of the async feature they're associated with. From this you'll get an idea of which code patterns might be more exposed to bugs.

Here's an overview of the all the async bugs we've logged. The green ones have been fixed in the original Async CTP or in the CTP Refresh. All the rest have remain unaddressed in the CTP Refresh.

Bad codegen bugs

The red segment of the pie chart is where our main codebase has, at some stage in development, produced bad codegen for certain async coding patterns, and hasn't been fixed in the CTP Refresh, and isn't in one of the main "unsupported-for-CTP" areas.

All the bugs we've seen in the red category stem from nested awaits. A 'nested await' is one that appears as a sub-expression of a larger expression. For instance,

var x = await f() + await g();

The CTP uses an incorrect order of evaluation for nested awaits. In particular, the CTP will first evaluate all Awaits in a given statement in order; once it has evaluated them all, then it will evaluate the remainder of the expression.

For the final version of async, which will be shipped in the next Visual Studio, we had to make a major overhaul of the codegen for nested awaits to fix the order of evaluation.

All of the bugs in this red category were associated in some way either with the CTP's treatment of nested awaits, or with the overhaul of them. Even some code patterns that don't use nested awaits (such as VB "Continue" out of a "Do / Loop Until") suffer bugs that come from the CTP's incorrect order of evaluation.

' BUG: VB-only bad behavior in async/iterator methods even without nested awaits.
' SUGGESTION: use PEVerify and run unit-tests
Do
    If True Then Continue Do
Loop Until True

Dim i = 1
For i = 0 To 100
    Console.WriteLine(i)
Next

' BUG: VB-only For loops don't work if you have non-constant "steps"
' SUGGESTION: Rewrite non-constant Steps into While loops.
' (Actually, this is the only bug that's not related to nested awaits...)
Dim s = -1
For i = 10 To 1 Step s
    Yield i
Next

// BUG: VB and C# bugs calling MyBase in async method (especially with generic params)
// SUGGESTION: use PEVerify to catch these
base.Foo<T>();

' BUG: Nested awaits cause VB-only incorrect behavior in flow-control-constructs
' SUGGESTION: Avoid nested awaits in these conditionals
Do
    Console.WriteLine("a")
Loop Until Await f()

Do While Await f()
    Console.WriteLine("a")
Loop

If 11 = Await f(10) Then
    Console.WriteLine("a")
ElseIf 10 = Await f(10) Then
    Console.WriteLine("b")
End If

For i = Await f(1) To Await f(2) Step Await f(3)
    Console.WriteLine(i)
Next

' BUG: Nested awaits are dodgy in both VB and C# in these situations
' SUGGESTION: use PEVerify and unit tests to check you’re getting right behavior
Dim x = New With {.A = Await f(1)}

var c2 = new int[] {await f(1), await f(2) };

Dim s = (Await f()) & Await f()

h(await f(1)); // when passed to a “ParamArray” parameter of h()

Bugs in language/IDE areas unsupported by the CTP

The lower segment of the above pie chart was about areas that are just not supported by the CTP. Here are those areas in detail. They're mostly easy to avoid.

Contextual keywords - the final implementation of Async will treat "async/await" as contextual keywords in C#, and "Async/Await/Iterator/Yield" as contextual keywords in VB. We have had many bugs in this area, but none of them should affect the CTP - since they are all simply reserved words in the CTP.

Overload resolution - the final implementation of Async has a host of new rules for overload resolution and type inference. This was a difficult area to implement and test, and none of the changes have been back-ported to the CTP. When you pass an async or iterator lambda as an argument to a method, the CTP will usually fail to do the correct type inference, and will usually fail to pick the correct overload.

Late-bound await - the final implementation of Async will allow late-bound await, i.e. "Await Object" in VB and "await dynamic" in C#. We had a fair number of bugs in this area. The CTP simply gives an error on these cases, so bypassing all the bugs.

Await in unsafe code - the final implementation of Async will allow async methods to have unsafe code blocks, just so long as await is never itself in an unsafe context. None of this has been back-ported or tested in the CTP. You should avoid mixing await/async with unsafe in the CTP.

Await in expression lambdas - the final implementation of Async will allow expression lambdas. The CTP doesn't.

IDE niceties - the final implementation of Async will have proper intellisense, quick-fixes, GenerateFromUsage, GoToDefinition and so on. None of these are present in the CTP.

Debugger - the final implementation of Async will have debugger support. It is absent in the CTP.

Nicer error messages - We filed many bugs and made lots of effort to improve the quality of error messages for erroneous uses of await. None of this work has been back-ported to the CTP, which remains stuck with rather poor error messages.

Bugs in illegal code - There are many places where the CTP compiler has not yet been hardened against erroneous uses of await. The good news is that if your code is correct, then you won't run into any of these bugs! The bad news is that you may inadvertently write erroneous code, and get VS crashes or PEVerify failures or incorrect codegen. Here are some of the erroneous code that triggers these bugs:

incorrect implementation of the awaiter pattern, or one with constraints
multiple or missing references to AsyncCtpLibrary.dll
async constructors or async Main
ByRef parameters in async/iterator methods
On Error Goto or Resume in async methods
async methods with __refvalue or __argiterator params
await of restricted types such as argiterator/typereference
use of await in attribute arguments
use of yield/await in catch/finally blocks
Also, devious-but-not-illegal implementation of the await pattern may trigger bugs:

' BUG: VB and C#, awaitable pattern with partial/conditional/obsolete pattern methods
' SUGGESTION: implement the pattern straightforwardly
Dim t As MyAwaitable
Await t

Miscellaneous bugs and workitems

Here are the rest of the bugs and workitems. None of these affect the quality of code you produce using the Async CTP.

The few IDE crashes were nebulous and not reproducible. If you run into any, please let us know! The only ones we've been able to pin down were all reported too late to be fixed in the CTP:

VB: Trying to do a late-bound await in a VBCore project
VB: Making a task-returning async event handler
C#: hovering over a named indexer that is awaited and then invoked in one expression

Async CTP Refresh - compiler bug fixes

Lucian Wischik, MSFT — Sat, 16 Apr 2011 17:10:00 GMT

Async CTP Refresh - Compiler Bug fixes

The big news about the Async CTP Refresh is that it enabled development on SP1 and for Windows Phone 7, and came with a new EULA. But there were also a few bug fixes...

We heard about some of these bugs from community feedback. Thank you. Such feedback is enormously useful to us.

This blog post lists the only compiler bugs fixed in the Async CTP Refresh. (In addition there were several library bugs fixed in the dataflow libraries). I want to spell out in detail some of these bugs we've found and fixed. This will give you an idea of how deeply we looked, and the kinds of bugs that arose. I also want to publically thank the users who alerted us to two of these bugs.

Fixed bug: a C# race condition in "finally" blocks

This bug was found by our QA department, and also by a user who emailed us directly, and also by the author of this blog: http://fredrikeriksson.me/post/3276445803/a-subtle-race-condition-in-the-asyncctp

// Bug: in the first CTP, if you had high concurrency, then sometimes the finally
// block would not be executed, and sometimes it would be executed more than once
try { await e; }
finally { Console.WriteLine("f"); }

// The first CTP generated this:

class StateMachine
{
    bool $doFinallyBodies;

    void MoveNext() {
        $doFinallyBodies = true;

        try {
            var $temp = e.GetAwaiter();
            $doFinallyBodies = false;
            if (temp.BeginAwait(cont))
                return;
            cont:
            $doFinallyBodies = true;
            $temp.EndAwait();
        }
        finally {
            if ($doFinallyBodies) {
                Console.WriteLine("f");
            }
        }
    }
}

// The CTP Refresh generates this:

class StateMachine
{

    void MoveNext() {
        bool $doFinallyBodies = true


        ...
        ...
        ...

    }
}

The field "$doFinallyBodies" is used so that, if we had to return early due to an "await" statement, then we'd bypass the finally bodies that the user had written. They should only be executed on normal exit.

The bug was that by accident I'd made $doFinallyBodies a field. It should have been a local. As a field, if there was high concurrency and lots of threads running the same async method, then one thread might overwrite the shared $doFinallyBodies at the wrong time.

VB did not have this bug, since in VB it was already a local.

Fixed bug: another C#/VB race condition in "finally" blocks

This bug was found by user "Soonts" on StackOverflow, http://stackoverflow.com/questions/5032784/async-ctp-and-finally.

' Bug: in the first CTP, this would print "1" then "finally".
' But it's supposed to print "finally" then "1".
Sub Main()
    Console.WriteLine(f().Result)
End Sub

Async Function f() As Task(Of Integer)
    Try
        Await TaskEx.Yield()
        Return 1
    Finally
        Console.WriteLine("finally")
    End Try
End Function

' The first CTP generated this:

Class StateMachine
    Dim $builder As
       AsyncTaskMethodBuilder(Of Integer)

    Sub MoveNext()

        Try
            Await TaskEx.Yield()
            $builder.SetResult(1)

        Catch ex As Exception
            $builder.SetException(ex)

        End Try

    End Sub
End Class

' The CTP Refresh generates this:

Class StateMachine
    Dim $builder As
       AsyncTaskMethodBuilder(Of Integer)

    Sub MoveNext()
        Dim $ReturnVariable As Integer
        Try
            Await TaskEx.Yield()
            $ReturnVariable = 1
            GoTo exit
        Catch ex As Exception
            $builder.SetException(ex)
            Return
        End Try
        exit:
        $builder.SetResult(ReturnVariable)
    End Sub
End Class

Fixed bug: a VB compiler bug with caught exception variables

Use of the exception variable would often have failed PEVerify, and in code like below where you're using the exception variable it would have caused a runtime exception. The root cause was that VB compiler generates IL with a temporary local variable for "ex". In an async method, the temporary local variable had to be lifted into the state machine.

' Bug: in the first CTP, runtime crashes in some uses of the caught exception variable.
' This has been fixed in the CTP Refresh
Async Sub f()
    Try
        Throw New Exception("test")
    Catch ex As Exception
        Dim lambda = Sub()
                         Console.WriteLine(ex) ' crash right here
                     End Sub
        lambda()
    End Try
End Sub

Fixed bug: a VB compiler bug with Select statements in asyncs/iterators

Select Case statements in VB async+iterator methods had a chance of incorrect codegen, depending on the exact types used by the statement and the ranges of the Case clauses. It sometimes failed PEVerify, and more often just picked the wrong Case branch. Once again the problem was one of IL with temporary local variables, this time for the Select Case operand. This bug was hard to track down because VB does aggressive optimization on Select Case statements, and only certain optimizations would expose the bug.

' Bug: in the first CTP, if invoked with "10", this would print ERROR
' This has been fixed in the CTP refresh
Async Sub f(y As Long)
    Select Case y
        Case 8 To 10
            Console.WriteLine("SUCCESS")
        Case Else
            Console.WriteLine("ERROR")
    End Select
End Sub

Fixed bug: a VB compiler bug with late-bound For loops in async/iterators

Late-bound VB For loops in VB async+iterator methods would often have failed PEVerify and crashed at runtime. Once again the problem was one of IL with temporary local variables, this time for the upper bound of the For loop, and the fix was to lift it to be a field in the state machine. You might get the feeling that a lot of our bugs were due to the need to lift temporary local variables. Once we twigged onto this, we systematically tracked down every last case that needed it.

' Bug: in the first CTP, late-bound For loop crashed
' This has been fixed in the CTP Refresh
Async Sub f()
    Dim x As Object = 4
    For i = 1 To x
        Console.WriteLine(i)
    Next
End Sub

Note: on the Async Forums, user MattMc3 pointed out a For loop bug that still exists: if the For loop has a Step that isn't constant, then it won't work. The reason is that (sigh) the CTP fails to lift the "step variable temporary".

Fixed bug: a VB compiler bug with type constraints in asyncs/iterators

Generic constraints in async/iterator methods would have caused problems if they referred to other generic parameters of the async method. This usually manifest as a VS crash; sometimes it failed PEVerify instead. The bug was because, when we lift the method into a state machine class, we have to turn the method's generic parameters into generic parameters of the state machine class, and we have to remember to rewrite the constraints accordingly.

' Bug: in the first CTP, this could would sometimes crash the IDE.
' This has been fixed in the CTP Refresh
Async Sub CreateListElement(Of TElem, TList As {New, List(Of TElem)})()
Dim l2 As New TList()
End Sub

Fixed bug: a pre-existing C# bug with nullables

In C#, a method with nullable equality tests would sometimes evaluate the operands more than once. We seemed to hit this more in our async testing, but we discovered that it was caused by a pre-existing bug in VS2010, one that arose from optimizations in the handling of nullables. This has been fixed in the CTP Refresh.

// Bug: in the first CTP, this would do incorrect codegen
async void g() {
    Task<bool> t = null;
    bool b = new Nullable<bool>(true) == await t;
}

// Bug: in VS2010, this would print "f" twice.
// This has been fixed in the CTP Refresh
void Test() {
    bool b = (new Nullable<bool>(true)) == f();
    Console.WriteLine(b);
}

bool f() {
    Console.WriteLine("f"); return true;
}

Fixed bug: a pre-existing C# bug using "base.property"

In C#, an async method which accessed "base.property" would cause incorrect codegen in the case where that property had different accessibility of its getter and setter. We discovered that this was caused by a pre-existing bug in VS2010, to do with the similar case of iterators. It would produce incorrect codegen, fail PEVerify, and sometimes throw an exception at runtime. The root cause of the bug is that both iterator and async methods must be lifted into a class. This class can no longer call any protected "base" method since it lacks accessibility. Instead it needs to generate a stub method which does have that accessibility. And the logic for deciding when that stub method was needed, failed to take into account the potential different visibility of setters and getters.

// Bug: in the first CTP, both "f" and "g" would produce bad codegen
// that failed PEVerify. This has been fixed in the CTP Refresh.
class C : B
{
    IEnumerator f() { base.p = 1; yield break; }
    async void g() { base.p = 1; }
}

class B
{
    public virtual int p { private get; set; }
}

Fixed bug: VB would sometimes crash VS if you double-dotted

In the first CTP, in VB, if you had a variable whose type was inferred from an expression involving Await, and if you then double-dotted off this variable, it would crash VS.

Dim s = Await (New WebClient).DownloadStringTaskAsync(http://a.com)
Dim len = s.ToUpper().Length ' would crash VS in the first CTP

The reasons are pretty bizarre. When you dot off something, the intellisense engine needs to know the type. It finds the type by "keyhole analysis", i.e. only looking at the lines in question, without regard to the containing method. Indeed it didn't know that the containing method was async. There was a mismatch between intellisense (who therefore thought the Await was illegal) and the compiler (who knew it was legal). This mismatch caused the crash. The fix is for intellisense not to judge legality or otherwise of an Await.

Async CTP Refresh - design changes

Lucian Wischik, MSFT — Fri, 15 Apr 2011 15:44:18 GMT

Async CTP Refresh - Design Changes

The big news about the Async CTP Refresh is that it enabled development on SP1 and for Windows Phone 7, and came with a new EULA. But there were also a few design changes...

Async is like the zombie virus

I've come to believe that async will be like the "zombie virus" - once it bites one part of your program, you'll be inclined make more of your program async just in case an operation takes time. But normally your async methods will complete immediately -- and we've made some design changes to help the performance of this "fast path".

Design change: new "await" pattern for greater efficiency

In the Async CTP Refresh, we changed the "await" pattern to make the fast path more efficient. This will affect anyone who made their own types awaitable. The following code is in VB, but it applies equally to C#.

' What pattern does the compiler use to implement an await expression?
Dim i = Await e

' Old pattern, in first Async CTP

Dim $temp = e.GetAwaiter()
SAVE_STATE()
If $temp.BeginAwait(AddressOf cont) Then
Return
End If
cont:
RESTORE_STATE()
Dim i = $temp.EndAwait()

' New pattern, in Async CTP Refresh

Dim $temp = e.GetAwaiter()
If Not $temp.IsCompleted Then
    SAVE_STATE()
    $temp.OnCompleted(AddressOf cont)
    Return
    cont:
    RESTORE_STATE()
End If
Dim i = $temp.GetResult()
i = Nothing

In the old pattern, it incurred the cost of SAVE_STATE() even if the task had already completed. We couldn't put SAVE_STATE() inside the "Then" clause, because of the off chance that cont might be executed even before the "Then" clause had executed. In the new pattern we separated it out, so SAVE_STATE() and RESTORE_STATE() are never even executed in the "fast path".

In the old pattern, it also incurred the cost of constructing a delegate (which I've written "Addressof <label>" in the pseudo-code above), even if it wasn't needed. The new pattern will allow us to allocate that delegate lazily, potentially saving a heap allocation in the fast path. However, this is just potential for the future: we don't actually take advantage of it.

In the old pattern, it also left the "awaiter" field hanging around. In the new pattern, we null it out -- the C# equivalent is "default(T)". This is so that the awaiter does not hold onto references for longer than necessary, which could harm garbage collection.

GUIDANCE

If you are concerned about garbage collection in a long-running async method, you can “null out” your local variables. This is the same as what you can currently do in long-running non-async methods.

Taking advantage of async "fast path"

How might you take advantage of the async fast path? Here's some sample code, this time in C#. It uses the new method TaskEx.FromResult<T>() which was added in the CTP Refresh.

// This will use the "fast path" in the common case where the

// data is already available locally. It will avoid heap allocations

// in that case.

Database db;

while (await db.MoveNextAsync())

{

Console.WriteLine(db.Current);

}

Thanks to the change, this "while" loop incurs only two small method calls (and no heap allocations) beyond what would be needed in a non-async alternative. The performance boost comes down to this implementation:

class Database

{

private static Task<bool> trueTask = TaskEx.FromResult(true);

private string[] currentBuffer = null;

private int currentIndex = -1;

public string Current {get {return currentBuffer[currentIndex];}}

public Task<bool> MoveNextAsync()

{

if (currentBuffer != null && currentIndex < currentBuffer.Length-1)

{

currentIndex++;

return trueTask; // avoids the cost of allocating a task

}

return MoveNextAsyncInternal();

}

public async Task<bool> MoveNextAsyncInternal()

{

currentBuffer = DownloadNextChunkFromDatabase();

if (currentBuffer == null) return false;

currentIndex = 0;

return true;

}

Costs of async... where even the "fast path" doesn't help

Even if the fast paths are taken everywhere, there are still some inherent costs in async:

' Compare the cost of these two statements.

' The async one has some overhead...

Dim i1 = f1()

Dim i2 = Await f2()

Function f1() As Integer

Return 1

End Function

Async Function f2() As Task(Of Integer)

Return 1

End Function

The async call costs THREE extra heap allocations - one for the async state machine, one for its continuation delegate, and one for the resultant Task object.
The async call costs several extra method calls to set up those objects and those fields.
The async call costs additional IL instructions and an additional try/catch block within the body of the method.
The return statement in the async case costs an additional method call.
To await f2() costs two extra method calls.

So how is it that the previous code managed to avoid most of those costs?

while (await db.MoveNextAsync()) {

Console.WriteLine(db.Current);

}

Here "MoveNextAsync()" was not actually an async method, i.e. it didn't use the async modifier. And it returned a pre-allocated Task object instead of allocating a new one each time. In this way it bypasses most of the extra async costs. The only extra cost it incurs over and above the synchronous case is two extra method calls.

GUIDANCE

Create “chunky async” APIs rather than “fine-grained async” APIs. For instance, create APIs which asynchronously retrieve a batch of rows from the database in one call, rather than just one row at a time.

The extra cost of async is negligible compared to the latency of network operations or UI operations. It is only ever worth thinking about in inner-loops or in server code where you’re optimizing for scalability. As always, measure performance before optimizing.

Don’t make your code async just for the sake of it. Only do so for a reason, e.g. to avoid blocking the UI, or because the API calls you’re making are async, or to avoid consuming too many threads.

As in the above case, the extra costs of consuming a “fast-path” async can be minimized in some situations. The extra costs of producing an async method cannot.

In case of the zombie virus, it’s best to prepare an emergency kit beforehand. Include a shovel.

Design change: new exception behavior for "Async Subs"

We made another change because we wanted uniformity in the behavior of exceptions in Async Subs ("void-returning asyncs" in C#).

This hopefully won't affect anyone!

GUIDANCE

It’s fine to use async methods that are Subs (void-returning asyncs) for top-level event handlers and the like. It’s okay for these to throw exceptions

It’s fine to use async methods that are Task-returning or Task<T>-returning, and have the suffix “Async”, for your normal async methods.

As for other acceptable uses of async methods, there are a few niche cases where it makes sense to write “fire-and-forget” Async Subs which the caller is never able to await, but these should not throw exceptions that your program is intended to handle.

For everyone who followed that guidance, the change in behavior of exception-throwing Async Subs won't have any effect. That's because the only exception-throwing Async Subs were the top-level event handlers.

' First Async CTP: idiosyncratic exceptions

Async Sub f()
    Throw New Exception("A")
    Await t
    Throw New Exception("B")
    Await TaskEx.Yield()
    Throw New Exception("C")
End Sub

' [A] Always thrown to the caller of f()
' [B] Might be thrown to caller of f(),
' or maybe to the caller of the
' continuation-after-t (usually the UI
' message pump), depending on whether t
' took the fast path or not
' [C] Always thrown by whoever called the
' continuation-after-Yield

' Async CTP Refresh: uniform exceptions

Async Sub g()
    Throw New Exception("A")
    Await t
    Throw New Exception("B")
    Await TaskEx.Yield()
    Throw New Exception("C")
End Sub

' [A] Thrown to the caller's Sync.Context
' [B] Thrown to the caller's Sync.Context
' [C] Thrown to the caller's Sync.Context

Implementation in first Async CTP:

At the start of the async method, the compiler implicitly generates a call to
System.Runtime.CompilerServices.
VoidAsyncMethodBuilder.Create()
This saves the current SynchronizationContext.Current
It then calls sc.OperationStarted()
When the method completes normally, the compiler implicitly generates a call to
builder.SetCompleted().
This calls sc.OperationCompleted()
If the method completed due to an exception, the compiler implicitly generates a call to
builder.SetCompleted().
This calls sc.OperationCompleted().
Next, the compiler lets the exception propagate up the callstack.

Implementation in CTP Refresh:

At the start of the async method, the compiler implicitly generates a call to
System.Runtime.CompilerServices.
AsyncVoidMethodBuilder.Create()
This saves the current
SynchronizationContext.Current
It then calls sc.OperationStarted()
When the method completes normally, the compiler implicitly generates a call to
builder.SetCompleted().
This calls sc.OperationCompleted()
If the method completed due to an exception, the compiler implicitly generates a call to
builder.SetException(ex).
This calls sc.OperationCompleted().
It then does sc.Post( () => throw ex ).

Async CTP Refresh - its state and direction

Lucian Wischik, MSFT — Thu, 14 Apr 2011 16:31:00 GMT

Async CTP Refresh - its state and direction

We really appreciate everyone who has installed the Async CTP. It has given us tremendous feedback. We appreciate all the discussion and bug reports that have come from users. We made the CTP uninstallable to encourage people to test it.

But this is just a CTP. You install it, use it and deploy apps with it at your own risk. This and the following four blog posts will give you raw information to help you make an informed judgment about the state of the CTP.

We do not provide support for the Async CTP. We wanted to get the CTP out early, and so haven't held it up to the same quality standards as we will for the final polished release of async that's coming in the next version of Visual Studio. But I'd like to point out that Microsoft has already released a polished version of "Async"...

F# has already shipped with Async in Visual Studio 2010.
It is high quality, robust, tested, flexible, and supported by Microsoft.
I personally think F# is a great language -- ahead of the curve, so that if you learn F# then you'll be a couple of years ahead of your peers. Indeed, F# introduced Async first.

Q. What issues are there in the Async CTP?

We've discovered close to 400 bugs in async since the first CTP, thanks to feedback from early adopters and thanks to the phenomenal testers in the MS Languages QA team. I'll analyze those 400 bugs over the next four days:

The first Async CTP was an early branch of our main development code base. We have spent all our bug-fixing work on that main codebase, which will eventually ship with the next Visual Studio.

We have back-ported only a handful of bug-fixes from the main codebase back into the Async CTP Refresh - mainly ones to do with quality of code-generation.

Q. Why not just release a supported out-of-band Async feature already?
Q. Why delay it until the next release of Visual Studio?
Q. Why not put all the bug-fixes into the CTP Refresh?

Async is a huge feature! I think it will change the way most people program. We have to do it right, to make it consumable by everyone rather than just early-adopters. Here's some of what has to happen:

1. Language support in C# and VB
The CTP only contains about half of the language support. It doesn't yet support proper overload resolution with async lambdas, nor lambda type inference, nor async expression lambdas, nor late-bound await.

2. IDE support
Debugger support, GenerateFromUsage, Intellisense - all are absent from the CTP

3. Adding async APIs to the .NET framework
The CTP threw together a bunch of extension methods to make existing async APIs support the language feature, but we need to properly engineer all of them, and think about new APIs that should have async versions.

4. Bringing the support libraries to other platforms, such as Windows Phone 7 and Silverlight
The CTP had a provisional AsyncCtpLibrary_Silverlight.dll, and the CTP Refresh has a provisional AsyncCtpLibrary_Phone.dll, but these are not in a final state. We can make them faster and cleaner if we engineer them properly.

5. Making ASP work with async
The CTP has an ASP async sample, but we think we can bake async support more powerfully into ASP.

6. Unit-testing
The CTP Refresh has a unit-testing sample, but we've put it out as an exploration of what should be done - not the final answer

7. Inventing the new design patterns for async programming, and guidance
The new style of async programming, from F# and now C#/VB, has not been used widely before. We think it will become ubiquitous. But no one yet has the programming maturity to know what are the best design practices around async. It'll take Microsoft and the wider community both time and experience before we figure out how best to use async. We can't be sure we've got the feature right until we've got more real-world experience. And we'd never want to commit something into the C#/VB languages until we're sure it's right.

In all, to do Async right we need wholesale work on all of VS and on all of .NET. It can never be done just by a CTP. It is the kind of disruptive change that requires a whole new release of VS.

Q. Will my Async CTP code still work the same when the next VS is released and I upgrade to it?

NO! Your current Async CTP Refresh code will require changes when the next VS is released and you upgrade to it... Here are the chief differences:

TaskEx class
In the Async CTP you have to use TaskEx everywhere. In the final version, we'll be rolling all these things into the main Task class.

Overload resolution and type inference
The Async CTP does not implement overload resolution of async lambdas properly, nor type inference. If you pass an async lambda then it might pick different overloads when you upgrade to the next VS. This was a real issue for us in the CTP where we had to separate TaskEx.Run and TaskEx.RunEx to work around the overload-resolution limitations.

Order of evaluation
The Async CTP has the wrong order of evaluation for compound expressions. In particular, it evaluates all await expressions in a statement first, and then execute the rest of the statement afterwards. Thus, "if (f() && await g())" in the CTP will always evaluate g() and await it first, even if f() returns false. The next version of VS will have the correct order of evaluation. To make this fix we actually had to overhaul a large part of the codegen side of the compilers. We thought this too risky, at this stage, to back-port to the CTP Refresh.

Extension-method APIs
The Async CTP uses extension methods to provide async versions of the .NET APIs. The next release of VS will have them as instance methods. Overload resolution rules treats extension methods differently from instance methods, and so the next release may cause subtle differences in overload resolution.

Precedence
The Async CTP has the wrong precedence for the Await operator in VB. It should have highest precedence, but actually has lowest. For instance, "Await e + Await f" is parsed in the CTP as if it were "Await (e + Await f)," but in the final release it will parse as "(Await e) + (Await f)" .

Async CTP Refresh - Installation

Lucian Wischik, MSFT — Wed, 13 Apr 2011 15:57:00 GMT

Async CTP Refresh - installation

The Async CTP Refresh was announced on 13th April 2011. It includes Visual Studio 2010 SP1 compatibility, enables Windows Phone 7 development, has a new EULA with updates regarding usage in production environments, and is compatible with non-English installations of Visual Studio and with Visual Studio Express.

The Async CTP Refresh has installed cleanly for most people. But we have had reports of a few problems. Here's some trouble-shooting for the installation process.

FIRST: If you had previously installed the first Async CTP, first uninstall it before installing the Refresh.
(Uninstall may ask for your original VS2010 installation media, and will probably need a reboot).

Set aside some time. This is how long it took me with a superfast internet connection and SSD hard drive:

30 minutes to uninstall the first Async CTP
30 mins to download+install the Windows Phone Dev Tools, and VB for phone developers
2 hours to download+install Visual Studio 2010 SP1
1 hour to download+install the Async CTP Refresh

COMMON FIX: A fix for most installation problems is (1) uninstall Async CTP, then (2) reinstall it.

To uninstall the Async CTP:

Go to Start > ControlPanel > Uninstall > Updates
Search for all the updates with "Async" in their names
And uninstall them. There may be 1, 2 or 3 updates to uninstall - about 30 minutes on my machine.

A quick check that the Async CTP Refresh has installed correctly

If you suspect there's something wrong with your installation of the Async CTP, then please check the version information of these four files. (Please check all four of them, even if you're not doing C# or VB or Phone development!)

1. C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe
2. C:\Windows\Microsoft.Net\Framework\v4.0.30319\vbc.exe
3. C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\msvbide.dll
4. My Documents\Microsoft Visual Studio Async CTP\Samples\AsyncCtpLibrary_Phone.dll

If you see the following version numbers, then the Async CTP Refresh has been correctly installed:

	csc.exe	vbc.exe	msvbide.dll	AsyncCTPLibrary_Phone.dll
CTP-Refresh	4.0.30319.440	10.0.30319.440	4.0.40219.15	1.0.0.0

Q. How to find those version numbers? A. Right-click on each file and choose Properties; the version number is in the "Details" tab.

If the version numbers are incorrect:

Here are the other version numbers you might find.

	csc.exe	vbc.exe	msvbide.dll	AsyncCTPLibrary_Phone.dlll
VS2010	4.0.30319.1	10.0.30319.1	10.0.30319.1	absent
Async CTP 1	4.0.30319.326	10.0.30319.326	10.0.30319.326	absent
VS2010 SP1	4.0.30319.1	10.0.30319.225 10.0.30319.431	10.0.40219.1	absent
Async CTP Refresh	4.0.30319.440	10.0.30319.440	10.0.40219.15	1.0.0.0

Please verify that all four version numbers are correctly that of the Async CTP Refresh. If they're not, then you should uninstall+reinstall:

COMMON FIX: A fix for most installation problems is (1) uninstall Async CTP, then (2) reinstall it.

I want to stress this: you should check the version numbers of all four files. Even if you think you're not going to use C#, say, you should still check all four files including csc.exe. Any discrepancy in any of the files will indicate your machine is in an incorrect state, and you should uninstall then reinstall.

If the installer says "You need SP1" but you already have SP1

There's a bug in the Async Installer to do with Express versions of VS. The situation: if you have VS Express with SP1, and try to install the Async CTP, then it will complain that SP1 isn't installed. The workaround is to temporarily add a key to the registry. Details here:
http://social.msdn.microsoft.com/Forums/en-US/async/thread/356cbf95-11ab-44d6-bea2-f2682ccb7b8e

If the "Phone" samples fail to load

If you don't have the Windows Phone Dev Tools installed, then the Phone samples will fail to load in VS.

The fix is the same as always:

First, uninstall the Async CTP
Next, download+install the Windows Phone Developer Tools
Next, download+install VB For Windows Phone Developer Tools
Next, download+install Visual Studio 2010 SP1
Next, download+install the Async CTP Refresh.

Note that the order here is important! The Async CTP must be uninstalled before you do anything else. The phone tools must be installed before SP1. The Async CTP must come last.

If the "Phone" samples cause VS to crash when you try to load them

If you don't have the VB For Windows Phone installed, then the VB Phone samples will crash VS when you try to load them.

In this case you can get by with a much easier fix:

Just download+install VB For Windows Phone Developer Tools

If the version numbers are CORRECT but you get errors in VS

Some users have reported that the four version numbers are all correct, but they still get squiggly underlines within Visual Studio.

This is typically due to a third-party extension which is not aware of the new async keywords.

If you still have errors

Please post a request for help in the Async Discussion Forums. We do monitor those forums frequently, and we may be able to help.

When you ask for help, PLEASE mention all four file version numbers. That will help!

PS. Many thanks to Jaap Suter for spotting a typo in the version tables.

A technical introduction to the Async CTP

Lucian Wischik, MSFT — Fri, 29 Oct 2010 08:00:00 GMT

I made this slide deck that covers all of the Async CTP technically.

[powerpoint] A technical introduction to the Async CTP.pptx
[pdf] A technical introduction to the Async CTP.pdf

Here are its contents:

[100-level] Straightforward explanation of when and how to use Async
- What is the difference between "asynchrony" and "concurrency" -- and when to use them (and when not)
- Why asynchrony is different from "running on a background thread"
- How to use the async+await keywords
[200-level] How exactly does an async program behave?
- A detailed animation of control-flow of an async method
- What happens on the UI thread, IOCP (IO Completion Port) threads, and the UI message-queue
- What is the new "Task Asynchronous Pattern" (TAP) in the framework
- How to use cancellation in the TAP, and push or pull approaches to progress-notification
[300-level] What library-authors should know about async
- How to make your own types awaitable
- How to implement TAP-like APIs yourself
[400-level] How is async implemented? How was it designed?
- Full details of the compiler transformation -- how it rewrites asynchronous methods, and how it deals with try/catch blocks
- Discussion and explanation of several design decisions we made
- How Async relates to existing computer science theory.

Async CTP: developer stories

Lucian Wischik, MSFT — Thu, 28 Oct 2010 10:30:00 GMT

We've shipped the Async CTP! And VB also has iterators!

I'm writing this blog post at 8.30pm on the evening before the Async CTP will ship. We're all pretty nervous and excited. Most of the Async/VB/C# team are at an "MVP Insiders" party. I'm sitting here fretting over code and writing tutorials.

Excited, and writing tutorials

I've been working on concurrency for my entire professional life, since graduating from college in 1995. And despite this background I have to say that the ideas in the Async CTP took me quite by surprise. The ideas came from F# Async Workflows and from the Axum prototype released by Microsoft last year, and we've developed them further to make them fit fluently into C# and VB.

Because the ideas are fairly new, there hasn't been much academic literature on the subject, nor textbooks, nor training courses. We're having to invent new concepts and patterns, and then figure out the most effective way to teach those concepts.

One of those surprising concepts is that asynchrony doesn't mean "background thread". Most people think it does! It's a little cocky for us to come out and tell the world "you've been using the word 'async' wrongly all these years", but that's what we're doing.

Async Function DoWork() As Task
' ... CPU-bound work to compute fast fourier transforms
End Function

When people look at this code, about 80% will see the word Async and immediately assume that it's going to run that work on a background thread. Those are the approximate results of our initial usability studies and internal testing. Of course, that's not what it actually means. What it means is that the method might have Await expressions in it, and (if it does) then it might end up returning its resultant Task before the body of the method has actually completed. I'll spell out our motives for co-opting the word "async" in a future post.

Another surprising concept is that of single-threaded concurrency. It shouldn't have been so surprising, since people have been doing cooperative multitasking for decades -- including in Windows 3.1 with the Yield keyword, and before that CallCC in Scheme and ML, and always with co-routines. But I think that the Await keyword makes cooperative multitasking more valuable now than it has been in the past. I'll be writing more about why we like this approach (as compared to the "zillions of threads" approach of the Go language, for instance), in a future post.

Nervous, and fretting over code

We've spent the last week building an installer, testing it, signing it, and preparing release material.

Today (the day before we ship the CTP) we discovered a serious bug where VB's XML-literals didn't work in async or iterator methods, so I fixed the bug, hastily tested it, we scrapped the installer and started rebuilding it over from scratch. That process takes several hours and involves the cooperation and good will of many kind people in the company. The Async CTP touches about 5% of the .cpp and .h files that make up the C# and VB compilers. I wrote much of the CTP, and so feel personally responsible for every bug.

Now (the evening before we ship the CTP) I just discovered another serious bug where VB will crash if a variable's type is inferred from an await expression and then you double-dot off it, e.g. "Dim result = Await t : result.Descendants.ToString()". I've fixed the bug, and I have to figure out whether to drag people away from their party, start a rebuild of the installer, and jeopardize the timing of the release in case it doesn't finish in time.

I think it's not quite that serious: everyone can have their party and their sleep, and the fix can be left for an update in a few days' time or maybe skipped entirely.

This Async CTP has been largely an "underground" project by a small group of 5 program-managers. Microsoft divides its employees into three categories: developers who write code, testers who test it, and program managers who look after specifications and deadlines. For most of the CTP's development cycle, we five PMs had to fill all three roles to build something substantial enough that management would approve it. This meant many late nights -- on some weeks sleeping more nights at the office than at home. What made all this effort worthwhile was the joy of working with such smart colleagues, and the satisfaction of finally being able to implement, refine and publish the answer that those smart colleagues delivered to the research question I first started asking in 1995: "how should you think about concurrency and make it usable for everyday programming?"

Teched Tweets

Lucian Wischik, MSFT — Wed, 09 Jun 2010 14:42:07 GMT

I'm giving a talk at TechEd 2010 (New Orleans) now.

I wrote a little VB app to display live tweets about #teched with "VB" in them. The source code's here.

How to write a VS2010 Extension using Statement Lambdas

Lucian Wischik, MSFT — Thu, 29 Apr 2010 22:27:00 GMT

Here's how to write a VS2010 extension (".vsix") in Visual Basic. The code is made a lot easier thanks to one of the major new features in Visual Basic 10, "statement lambdas".

This extension renders comments in a new typeface, Comic Sans Bold Italic.
You can write extensions that put any kind of WPF graphical effect in the buffer.
[I've made a channel9 video to accompany this blogpost, and it's in the middle of processing....]
Source code: ComicComments-src.zip [9k]
Prebuilt binary: ComicComments.vsix [26k]

0. PRELIMINARIES

Install the VS2010 SDK from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en

MSDN documentation about it is here: http://msdn.microsoft.com/en-us/library/bb166441(VS.80).aspx

1. CREATE THE PROJECT

File > New > Project > Extensibility > EditorClassifier

This creates a new project. It created it with three source files:
- EditorClassifier1.vb
- EditorClassifier1Format.vb
- EditorClassifier1Type.vb

This was a bit more complexity than we need. I deleted the last two from the project, and replaced the source code of EditorClassifier1.vb with just the following:

Imports System.ComponentModel.Composition

Imports System.Windows

Imports System.Windows.Media

Imports Microsoft.VisualStudio.Text.Classification

Imports Microsoft.VisualStudio.Text.Editor

Imports Microsoft.VisualStudio.Utilities

<Export(GetType(IWpfTextViewCreationListener)), ContentType("code"), TextViewRole(PredefinedTextViewRoles.Document)>

Class ViewCreationListener : Implements IWpfTextViewCreationListener

<Import()> Dim formatMapService As IClassificationFormatMapService

<Import()> Dim typeRegistry As IClassificationTypeRegistryService

Public Sub TextViewCreated(ByVal view As IWpfTextView) Implements IWpfTextViewCreationListener.TextViewCreated

End Sub

End Class

The <Export> and <Import> attributes show you that the extension is a MEF component. The long and short of it is that our code TextViewCreated will be invoked once for each new code-editor buffer.

2. CHANGE THE FORMAT MAP: FIRST ATTEMPT

Here's the first attempt at implementing TextViewCreated:

Public Sub TextViewCreated(ByVal view As IWpfTextView) Implements IWpfTextViewCreationListener.TextViewCreated

Dim formatMap = formatMapService.GetClassificationFormatMap(view)

Dim textClassification = typeRegistry.GetClassificationType("text")

Dim textProperties = formatMap.GetTextProperties(textClassification)

Dim commentClassification = typeRegistry.GetClassificationType("comment")

Dim commentProperties = formatMap.GetTextProperties(commentClassification)

Dim commentTypeface2 = New Typeface(New FontFamily("Comic Sans"), FontStyles.Italic, FontWeights.Bold, commentProperties.Typeface.Stretch)

Dim commentEmSize2 = textProperties.FontRenderingEmSize + 1

Dim commentProperties2 = commentProperties.SetTypeface(commentTypeface2).SetFontRenderingEmSize(commentEmSize2)

formatMap.SetTextProperties(commentClassification, commentProperties2)

End Sub

Each language classifies the text in the buffer, as "comment" or "text" or "typename". The formatMap is a map from classification to typeface. The line in yellow is where we update the map.

3. CHANGE THE FORMAT MAP: FINAL ATTEMPT

There are some problems with the above code. The first problem is that TextViewChanged can be called more than once, but the highlighted line of code is quite costly -- it causes an entire UI refresh. We can avoid this cost by only changing the map if necessary:

If Not commentProperties.Equals(commentProperties2) Then

formatMap.SetTextProperties(commentClassification, commentProperties2)

End If

The second problem is that sometimes TextViewChanged isn't called at the right time. It might be called too early, for instance. To make it more robust we should also update the formatMap the first time the window gets focus, in response to the view.GotAggregateFocus event.

The third problem is that, if some other plugin made a change to the formatMap, or if the user changed font size for instance, then we need to redo our work on the formatMap. The right place to do this is in response to the formatMap.ClassificationFormatMappingChanged event.

The final problem is that if we respond to the formatMap.ClassificationFormatMappingChanged event by calling formatMap.SetTextProperties, then that might itself trigger the formatMap.ClassificationFormatMappingChanged event again! So we need to protect against being recursively called by ourselves.

All these problems can be elegantly solved with a multi-line statement lambda. This is how:

Public Sub TextViewCreated(ByVal view As IWpfTextView) Implements IWpfTextViewCreationListener.TextViewCreated

Dim formatMap = formatMapService.GetClassificationFormatMap(view)

Dim inUpdate = False

Dim FixComments =

Sub()

If inUpdate Then Return Else inUpdate = True

Dim textClassification = typeRegistry.GetClassificationType("text")

Dim textProperties = formatMap.GetTextProperties(textClassification)

Dim commentClassification = typeRegistry.GetClassificationType("comment")

Dim commentProperties = formatMap.GetTextProperties(commentClassification)

Dim commentTypeface2 = New Typeface(New FontFamily("Comic Sans"), FontStyles.Italic, FontWeights.Bold, commentProperties.Typeface.Stretch)

Dim commentEmSize2 = textProperties.FontRenderingEmSize + 1

Dim commentProperties2 = commentProperties.SetTypeface(commentTypeface2).SetFontRenderingEmSize(commentEmSize2)

If Not commentProperties.Equals(commentProperties2) Then

formatMap.SetTextProperties(commentClassification, commentProperties2)

End If

inUpdate = False

End Sub

AddHandler view.GotAggregateFocus, FixComments

AddHandler formatMap.ClassificationFormatMappingChanged, FixComments

FixComments()

End Sub

The yellow highlights show the key changes.

What's good about using a lambda for this is that we can keep everything local to the place where it's needed. That's because the FixComments lambda is able to use the various fields (view, formatMap, inUpdate) directly. If we tried to turn FixComments into a normal named method, then we'd have to create a class which had those three things as members, and we'd have to write a constructor for it, and the code would start to look messy.

4. DEBUGGING AND DEPLOYING

source.extensions.vsixmanifest -- this file contains name and other information about your plugin. You must supply some additional files:
- some kind of "license.txt" of your chosing
- an icon 32x32 pixels big (I use PNG format)
- another icon 200x200 pixels big (again I use PNG)

To debug, just press F5 as normal. This will launch a version of VS2010 with your extension installed. However, it installs it into an "Experimental" folder
C:\Users\lwischik\AppData\Local\Microsoft\VisualStudio\10.0Exp
rather than the more usual
C:\Users\lwischik\AppData\Local\Microsoft\VisualStudio\10.0
All new editor-classification projects have been set up to debug by launching VS with the command-line argument "/rootsuffix Exp", which is why it looked in that experimental folder. This is so that you can debug without compromising the real VS.

Once it's finished, you can deploy. The extension is packaged up in your EditorClassifier1\bin\Debug folder in a file called
- EditorClassifier1.vsix

Any user can double-click on this .vsix to install the extension. Internally, it's really just a .zip file that contains the necessary files.

Req28: Override events

Lucian Wischik, MSFT — Fri, 05 Mar 2010 11:59:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Allow you to override an event. This idea requires some explanation. Currently, both VB and C# allow you define events in interfaces, and implement them:

Interface I1

Event e As Action

End Interface

Class DI : Implements I1

Public Event e() Implements I1.e

End Class

However, VB does not allow you to declare a MustInherit class with an event; and if a library (e.g. WPF) has created such a class in C#, then VB doesn't let you inherit from that class:

MustInherit Class C2

MustOverride Event e As Action ' declaration disallowed in VB

End Class

Class D2 : Inherits C2

Public Overrides Event e() As Action ' overriding disallowed in VB

End Class

Finally, VB doesn't let you declare an overridable event, or override it. C# does let you declare the overridable event but it behaves incorrectly when you try to actually override it...

Class C3

Overridable Event e As Action ' declaration disallowed in VB

End Class

Class D3 : Inherits C3

Public Overrides Event As Action ' overriding disallowed in VB; buggy in C#

End Class

IDEA: We should allow users to inherit from MustInherit classes and override their MustOverride events.

This is a parity issue. Without this, VB users are simply unable to use classes such as System.Windows.Documents.Serialization.SerializationWriter (which is a MustInherit class with a MustOverride event). Note that this is entirely CLS-compliant. The only VB workaround is mock-type injection voodoo.

We could go further and allow declaration of MustInherit or Overridable events, and we could go even further and provide a correct consumption of "Overridable events". But these seem like much less important.

Provisional evaluation from VB team: The most important parity issues for us are ones where VB users are shut out from libraries that are usable by C# developers. This is one such case. We therefore think this is an important problem to fix.

Req27: Allow query syntax in For Each

Lucian Wischik, MSFT — Fri, 05 Mar 2010 10:00:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Allow "For Each x In collection Where x>10", and other query expressions. We should allow this kind of code:

For Each x In collection Where x > 5

Currently we're forced to use awkward workarounds:

For Each x In From x_ In collection Where x_ > 5

For Each x In collection.Where(Function(x_ As Integer) x_ > 5)

For Each changedEntity In entityIndex.AllEntities.Where(
Function(x) x.ChangeTracker.State = ObjectState.Deleted)

IDEA 1: Allow only "Where" in For Each statements

IDEA 2: Allow arbitrary LINQ queries in For Each statements

This looks like a simple enough request, but it's not... The issue is that For Each uses the Collection Pattern: it looks for an accessible method or extension method named GetEnumerator, and on that it looks for MoveNext/Current; or failing that it looks for IEnumerable(Of T); or failing that it looks for IEnumerable. Meanwhile, a LINQ query use the Query Pattern: it looks for a conforming Select method, or failing that AsEnumerable/AsQueryable, or failing that Cast.

How to deal with this "impedance mismatch"? One solution is to go for IDEA 1, i.e. we figure out up-front which limited set of LINQ-like operators we want to allow. The problem with this is that it's so limiting, and we might get the set of operators wrong, and they wouldn't quite behave like thier LINQ counterparts.

Another solution is to go for IDEA 2, but say that every "querying For Each" statement is merely syntactic sugar for some LINQ query, e.g. "For Each x in coll where x>5" is merely syntactic sugar for "For Each x in (From x_ in coll where x_ > 5)".

Then we worry about performance. The compiler generates faster code when you "For Each" over an array than when you For Each over a collection. We would want "For Each x in coll Where x<5" to be exactly as performant as "For Each x in coll : If Not x<5 Then Continue".

Provisional evaluation from VB team: We're torn. It's a nice feature. But performance concerns push us to IDEA 1 with its problems, while generality/usability concerns push us to IDEA 2 with its problems.

What do you think? Would you like to see the more limited IDEA 1? With which LINQ-like query operators? Or would you prefer to see the more general IDEA 2?

Req26: allow With as a modifier on expressions

Lucian Wischik, MSFT — Fri, 05 Mar 2010 07:00:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: We should allow "With" as a modifier on expressions. Currently the "With" object-initializer syntax is only allowed on constructors, e.g.

Dim x = New S With {.p = 1, .q = 2}

This is rather limiting. It would be good if we could use it on factory methods, e.g.

Dim y = Factory.CreateThing() With {.p = 1, .q = 2}

The cleanest way to allow this, in the language, is to allow a "With" initializer to come after any expression:

Expression ::= ... | Expression ObjectMemberInitializer

This would be syntactic sugar for evaluating the expression and then assigning its properties:

Dim $temp = Factory.CreateThing()

$temp.p = 1

$temp.q = 2

Dim y = $temp

Provisional evaluation from VB team: When you tell the car dealer "I'd like to buy this car but with the yellow paintjob" -- you don't expect him to get out his spraycan and change this car right here; you expect him to go to the back of the store and pick out a similar car but with one difference. Likewise, we think it will be awfully unclear to users that "With" modifies an existing object rather than constructing a new object with some variations. We think that this proposal "digs up more snakes than ladders".

Req25: With and From should be allowed together

Lucian Wischik, MSFT — Fri, 05 Mar 2010 04:13:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: With and From should be allowed together. It's just a silly oversight that they're not. For example, we should allow this:

Dim x As New List(Of Integer) With {.Capacity = 10} From {1, 2, 3}

Provisional evaluation from VB team: It would be nice if we'd put this into the feature when we created it in the first place. But as for adding it now -- well, it seems like it wouldn't really add much value to many users. We think there are better ways to spend our development time.

Req24: warnings where "Nothing" isn't null

Lucian Wischik, MSFT — Fri, 05 Mar 2010 03:25:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Emit a warning where "Nothing" is used in a likely-incorrect way. 99% of users think that "Nothing" means the same as C#'s "null", i.e. a null reference or empty nullable -- but it isn't. Nothing is instead the same as C#'s "default(T)". Also, 99% of users don't realise that VB does null-propagation for all operators including the equality operator. We should give warnings in cases where we're overwhelmingly sure that Nothing is being misused.

Example 1.

Dim x As Integer? = If(False, 1, Nothing)

' gives x.HasValue=True, x.Value=0

It's hard, though, to know exactly what conditions would trigger the warning. One example condition, which would catch the above case, is "Warn when Nothing means the same thing as the number 0, since the user should have just written 0 instead".

Example 2.

Dim x As Boolean? = Nothing

If x = Nothing Then Console.WriteLine("is nothing")

' doesn't print anything

Contrary to common expectations, this code doesn't print anything. The condition we could use to catch this is, "Warn when the user writes an equality operator expr = Nothing or Nothing = expr in the case where expr has nullable type." And indeed in VS2010 we already did introduce this warning!

Example 3.

Private _AccessLevel As Integer?

Public Property AccessLevel As Integer?

Get

Return _AccessLevel

End Get

Set(ByVal v As Integer?)

If _AccessLevel Is Nothing OrElse _AccessLevel <> v Then _AccessLevel = v

End Set

End Property

AccessLevel = 15

AccessLevel = Nothing

Console.WriteLine(AccessLevel)

' prints 15: the second assignment didn't do what we expected

In this case the user has written the wrong conditions inside the property setter. The condition we could use to catch this? I don't know. It's not clear. But note that in this case the expression "_AccessLevel <> v" has type Boolean?. Bill McCarthy suggested that we emit a warning whenever a comparison operator (<, >, <>, =) produces a Boolean? but is used in a conditional statement that expects just a Boolean. It's a clever idea but I worry it will have too many false positives.

Other ideas. One possibility is to add two new keywords to VB, "null" and "default(T)" like in C#. Then we could deprecate "Nothing". This would be a bit of a shame in some cases, though, e.g.

Sub f(Optional ByVal x As IntPtr = Nothing)

void f(IntPtr x = default(IntPtr))

But in general, we think that throwing in extra keywords which do almost the same as existing keywords is a bad idea (witness the current confusion over CType vs DirectCast vs TryCast vs CTypeDynamic). We would also not want to deprecate a code construct that's used in 99% of user projects out there.

Provisional evaluation from VB team: Adding extra warnings is a good idea. We're not sure we've figured out exactly the right conditions that would trigger the warnings, though. We worry that the conditions above will produce false positives, i.e. they will warn in perfectly legitimate code. We also worry that they will produce false negatives, i.e. they will fail to detect cases that should be caught.

If you have been burnt by "Nothing" not being null, please post with your code snippets. That will help us evaluate whether our conditions are appropriate. Thanks!

Req23: Make more keywords contextual

Lucian Wischik, MSFT — Fri, 05 Mar 2010 03:07:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Make more keywords contextual, rather than reserved. At the moment lots of words like "Event" and "Next" and "AddHandler" are reserved keywords. If you want to have variables or methods with these names then you have to put them in brackets, "[Event]" and "[Next]" and "[AddHandler]". We should change the compiler so it allows these to be used as identifiers in contexts where it's not ambiguous.

Doing this would help those of us who are re-implementing the VB compiler in VB! It would also help with things like WPF which has a method named AddHandler. Since VB is so English-like, the English-speaking programmers tend to run into clashes with VB more than they do with other languages. "Next" and "End" are particularly frustrating because they're such natural words do use for your own identifiers.

Incidentally, you can currently use all keywords as identifiers if they come AFTER a dot, e.g. it's fine to write "Dim x = Fred.Next" or "Dim y = MyClass.Of({1,2,3})". The only exception is "New", where Fred.New isn't allowed (except bizarely in the case of Enums).

Provisional evaluation from VB team: This is a nice idea, but it doesn't seem very important.

Req21: Allow unambiguous types from ambiguous namespaces

Lucian Wischik, MSFT — Tue, 16 Feb 2010 02:56:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Allow unambiguous types from ambiguous namespaces. This request arises from VB's powerful "import" feature, which is more flexible than that of C#, but which introduces problems. I'll explain by example:

Dim x As ComponentModel.INotifyPropertyChanged

' In Winforms apps, this is ambiguous

' between System.ComponentModel and System.Windows.Forms.ComponentModel

If you write this code in a Console app then it compiles fine. But if you write it in a Winforms app then it's a compile-time ambiguity error. That's because Winforms apps import both "System" and "System.Windows.Forms", and the compiler doesn't know whether the prefix "ComponentModel" means System.ComponentModel or System.Windows.Forms.ComponentModel.

It makes VB fragile against the framework introducing new types or namespaces.

IDEA: VB should allow "X.Y.Z" whenever the full name "X.Y.Z" is unambiguous (even if the prefix "X.Y" is ambiguous).

Here are some other examples:

Threading.Thread.Sleep(1000)

' In WPF aps, this is ambiguous

' between System.Threading and System.Windows.Threading

Dim y As Xml.Linq.XDocument

' If you import System.Security.Cryptography, this is ambiguous

' between System.Xml and System.Security.Cryptography.Xml

It's not clear if this idea should work for ambiguous namespace and class prefixes, or merely for ambiguous namespace prefixes.

Provisional evaluation from VB team: We agree that this is a problem that would be good to fix. However, the spec rules for "unqualified and qualified name lookup" are already baffling ($4.7 and $11.4.4). This proposal would complicate them yet further. We will only consider this if we get clear and unambiguous feedback from users that they want the feature.

Req20: Range expressions

Lucian Wischik, MSFT — Tue, 16 Feb 2010 02:21:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA 1: Allow range expressions as a literal for IEnumerable. For instance,

' This expression

Dim x = 5 To 14

' should be syntactic sugar for this one

Dim x = Enumerable.Range(5, 10)

IDEA 2: Allow "in range" expressions. For instance,

' These conditions

If y In 50 To 100 Then ...

If 50 <= y <= 100 Then ...

' should be syntactic sugar for this one

If 50 <= y AndAlso y <= 100 Then

Provisional evaluation from VB team: The syntax for IEnumerable.Range isn't much of an improvement. As for the range-expression-tests, "50 <= y <= 100" already has a different meaning in VB, and "y In 50 To 100" isn't any clearer than the long version. We're not persuaded by these ideas.

Req19: Allow statements to start with parentheses

Lucian Wischik, MSFT — Tue, 16 Feb 2010 01:58:00 GMT

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: Allow statements to start with parentheses. Currently, every statement in VB must start with either an identifier or a keyword. We should allow statements to start with arbitrary expressions. At the very least, starting with "open parentheses" would be good. It would mean that we'd no longer need "Call" in the following statement:

Call (New Threading.Thread(AddressOf ThreadProc)).Start()

Provisional evaluation from VB team: It'd be a surprisingly big change to the parser code to implement this! We see that it would be useful, but don't believe it would be worth the effort to fix.

Lucian's VBlog

Async CTP v3 – installation

A quick check that the Async CTP is working

If the version numbers are incorrect

If Visual Studio crashes upon opening a VB/C# project

Uninstallation

If you still have problems

A day in the life of compiler bugfixing

Loop control variables with side-effects

Fixing the bug?

Talk: What's new in VB10 (VS2010)

Talk: What's new in VB10 (VS2010)

Talk: How to write an [Async] connected app for Windows Phone 7.1

Talk: How to write an [Async] connected app for Windows Phone 7.1

Talk: The [Async] Future of VB and C#

Talk: The [Async] Future of VB and C#

[placeholder] How to write a connected VB phone app

Async CTP Refresh - mitigation strategies

Async CTP Refresh - mitigations when using the CTP

Async CTP Refresh - what bugs remain in it?

Async CTP Refresh - what bugs remain in it?

Bad codegen bugs

Bugs in language/IDE areas unsupported by the CTP

Miscellaneous bugs and workitems

Async CTP Refresh - compiler bug fixes

Async CTP Refresh - Compiler Bug fixes

Fixed bug: a C# race condition in "finally" blocks

Fixed bug: another C#/VB race condition in "finally" blocks

Fixed bug: a VB compiler bug with caught exception variables

Fixed bug: a VB compiler bug with Select statements in asyncs/iterators

Fixed bug: a VB compiler bug with late-bound For loops in async/iterators

Fixed bug: a VB compiler bug with type constraints in asyncs/iterators

Fixed bug: a pre-existing C# bug with nullables

Fixed bug: a pre-existing C# bug using "base.property"

Fixed bug: VB would sometimes crash VS if you double-dotted

Async CTP Refresh - design changes

Async CTP Refresh - Design Changes

Async is like the zombie virus

Design change: new "await" pattern for greater efficiency

Taking advantage of async "fast path"

Costs of async... where even the "fast path" doesn't help

Design change: new exception behavior for "Async Subs"

Async CTP Refresh - its state and direction

Async CTP Refresh - its state and direction

Q. What issues are there in the Async CTP?

Q. Why not just release a supported out-of-band Async feature already?Q. Why delay it until the next release of Visual Studio?Q. Why not put all the bug-fixes into the CTP Refresh?

Q. Will my Async CTP code still work the same when the next VS is released and I upgrade to it?

Async CTP Refresh - Installation

Async CTP Refresh - installation

A quick check that the Async CTP Refresh has installed correctly

If the version numbers are incorrect:

If the installer says "You need SP1" but you already have SP1

If the "Phone" samples fail to load

If the "Phone" samples cause VS to crash when you try to load them

If the version numbers are CORRECT but you get errors in VS

If you still have errors

A technical introduction to the Async CTP

Async CTP: developer stories

Teched Tweets

How to write a VS2010 Extension using Statement Lambdas

Req28: Override events

Req27: Allow query syntax in For Each

Req26: allow With as a modifier on expressions

Req25: With and From should be allowed together

Req24: warnings where "Nothing" isn't null

Req23: Make more keywords contextual

Req21: Allow unambiguous types from ambiguous namespaces

Req20: Range expressions

Req19: Allow statements to start with parentheses

Q. Why not just release a supported out-of-band Async feature already?
Q. Why delay it until the next release of Visual Studio?
Q. Why not put all the bug-fixes into the CTP Refresh?