My example is RfcommServiceProvider.StartAdvertising(StreamSocketListener) listed on MSDN as being in the UniversalApiContract at version 1. My code was calling this and being flagged as version specific.

An overload was added in version 2 RfcommServiceProvider.StartAdvertising(StreamSocketListener, bool) and I'm guessing this is what was causing my code to be flagged.

The analyzer should consider the parameters to distinguish which overload is being called and if, in fact, it is actually version-specific or not.

Hi,

Using the latest pre release version (2.0.0), I've found that it warns about classes in the Windows.UI.Xaml namespace, like Thickness, as being Platform-specific code.

But these classes are declared in the Windows.Foundation.UniversalApiContract.

It's that ok?

Regards.

I installed the analyzer and I am getting this build warning

Analyzer assembly 'C:\Users\igor\.nuget\packages\PlatformSpecific.Analyzer\1.0.5\analyzers\dotnet\PlatformSpecific.Analyzer.dll' depends on 'Microsoft.CodeAnalysis.VisualBasic, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' but it was not found.

Is this normal? Or some kind of Nuget screw up?

Hello, I'm working on a project that utilizes the AsyncWorkflow code. It seems that the reconstruction of the state machine raises an exception when the project is compiled with either Release or Debug with the "Optimize Code" flag lit. Is this a known issue? Is there a workaround perhaps?
Would appreciate any help :)

It would be amazing to both add adornments and then print the textView of type IWpfTextView using c#.

Thanks!

VS 2015 Community, Markdown Editor from mads kristensen

I want to see additional compiler warnings for async/await...

The compiler already reports when you're missing an await:

async Task MainAsync()
{
   await Task.Delay(100);  // okay
   Task.Delay(100); // warning CS4014 - this call is not awaited
}

But what about the more tricky case where you do await something, but you got confused and what you got back was actually a Task<Task> so you needed a double await on it?

static async Task MainAsync()
{
    await Task.Factory.StartNew(async () =>
    {
        await Task.Delay(10);
        Console.WriteLine("A");
    });
    Console.WriteLine("B"); // oops! this gets printed before "A"
    // We want a warning that the return of await Task.Factory.StartNew was itself a Task
}

You might argue that the root problem is someone using Task.Factory.StartNew when they should have been using Task.Run. And I agree. But a warning about double-await might be the trigger they need to change.

Here's a counter-example to that rule:

// IDIOM 1:
Task t1 = FredAsync(), t2 = JonesAsync();
var winner = await Task.WhenAny(t1,t2);
if (winner == t1) …

// IDIOM 2:
Task t1 = FredAsync(), t2 = JonesAsync();
await Task.WhenAny(t1,t2);
if (t1.IsCompleted) …

The rule above would produce a warning on the second await Task.WhenAny. But I think idiom2 is nice and doesn't deserve a warning. I guess we should make an exception, so that the warning is never generated for await Task.WhenAny.

The problem can occur in more pernicious ways. Look at the following code. It came about from a well-intentioned attempt at making the method FredAsync more efficient, by returning quickly on the "hot path", and by doing the standard transform from async Task f() { await e; } into async Task f() { return e; }. But whoever wrote this code didn't apply the transform correctly...

static async Task MainAsync()
{
    await FredAsync(1);
    Console.WriteLine("B");
}

static Task FredAsync(int i)
{
    if (i == 0) return Task.FromResult(0);
    return Task.Run(async () => { await Task.Delay(i); return JonesAsync(i); });
}

static async Task JonesAsync(int i)
{
    await Task.Delay(i);
    Console.WriteLine("A");
}

What we see here is the exact same double-await problem as above but it's become disguised by an implicit conversion in the return statement from a Task<Task> to just a Task.

Now I know that in general it's really useful to have an implicit conversion from Task<T> to Task, e.g. for use by Task.WhenAll(params Task[] tasks). But maybe specifically the implicit conversion from Task<Task> to Task is too dangerous? After all, there are two different ways to transform Task<Task> into Task (either by awaiting it or by inheritance) and the user should always specify which of the two is intended.

Telling an async method "here's the filename to save to" is fine if you only have one, but when you're working with a non-trivial program that might have multiple tasks running at once, you need a better solution that can handle saving multiple tasks into the same save file.

The original post mentioned something along the lines of having a HiberationTokenSource / HibernationToken system. This is definitely needed to make AsyncWorkflow production-ready, preferably with a Hibernate(Stream) method available.