Basically, in order to be safe you need to do one of two things:

1. Handle exceptions within the async method itself; or
2. Return a Task<T> and ensure that the caller attempts to get the result whilst also handling exceptions (possibly in a parent stack frame)

Failure to do either of these things will result in unwanted behaviour. Here is a simple sample to run - just uncomment out the method calls one at a time to see what happens.

----- code start -----

  using System;
  using System.Runtime.CompilerServices;
  using System.Threading;
  using System.Threading.Tasks;

  namespace AsyncAndExceptions
  {

    class Program
    {
      static void Main(string[] args)
      {
        AppDomain.CurrentDomain.UnhandledException += (s, e) => Log("*** Crash! ***", "UnhandledException");
        TaskScheduler.UnobservedTaskException += (s, e) => Log("*** Crash! ***", "UnobservedTaskException");

        RunTests();

        // Let async tasks complete...
        Thread.Sleep(500);
        GC.Collect(3, GCCollectionMode.Forced, true);
      }

      private static async Task RunTests()
      {
        try
        {
          // crash
          // _1_VoidNoWait();

          // crash 
          // _2_AsyncVoidAwait();

          // OK
          // _3_AsyncVoidAwaitWithTry();

          // crash - no await
          // _4_TaskNoWait();

          // crash - no await
          // _5_TaskAwait();

          // OK
          // await _4_TaskNoWait();

          // OK
          // await _5_TaskAwait();
        }
        catch (Exception ex) { Log("Exception handled OK"); }

        // crash - no try
        // await _4_TaskNoWait();

        // crash - no try
        // await _5_TaskAwait();
      }

      // Unsafe
      static void _1_VoidNoWait()
      {
        ThrowAsync();
      }

      // Unsafe
      static async void _2_AsyncVoidAwait()
      {
        await ThrowAsync();
      }

      // Safe
      static async void _3_AsyncVoidAwaitWithTry()
      {
        try { await ThrowAsync(); }
        catch (Exception ex) { Log("Exception handled OK"); }
      }

      // Safe only if caller uses await (or Result) inside a try
      static Task _4_TaskNoWait()
      {
        return ThrowAsync();
      }

      // Safe only if caller uses await (or Result) inside a try
      static async Task _5_TaskAwait()
      {
        await ThrowAsync();
      }

      // Helper that sets an exception asnychronously
      static Task ThrowAsync()
      {
        TaskCompletionSource tcs = new TaskCompletionSource();
        ThreadPool.QueueUserWorkItem(_ => tcs.SetException(new Exception("ThrowAsync")));
        return tcs.Task;
      }
      internal static void Log(string message, [CallerMemberName] string caller = "")
      {
        Console.WriteLine("{0}: {1}", caller, message);
      }
    }
  }

----- code end ----- 

From this we can see that the common advice isn't actually true:

• It's perfectly fine to have an async void method (such as an event handler) so long as you look after exceptions within that method
• Simply changing the signature doesn't prevent unhandled exceptions

The basic reason for this is that if you don't attempt to get the result of a Task (either by using await or by getting the Result directly) then it just sits there, holding on to the exception object, waiting to get GCed. During GC, it notices that nobody ever checked the result (and therefore never saw the exception) and so bubbles it up as an unobserved exception. As soon as someone asks for the result, the Task throws the exception instead which must then be caught by someone.

We've just added an additional sub-site for Missing Platform APIs, where you can provide feedback on APIs that are available for traditional Desktop Windows apps, but not available in the Store Profile. This includes both Win32 / COM and .NET APIs that you'd like to use for compatibility with your existing code, or with 3rd-party libraries that you'd like to use but can't (because they have dependencies on missing APIs).

If there are specific APIs from other operating systems that you would like to see a Windows equivalent of, you can also suggest (or vote on) those.

Remember that, as always, providing an explanation of why you want the API is critically important as we assess what changes to make to the Store Profile over time. There are many cases where the full power of an API is fundamentally incompatible with the Store model, but a restricted use-case (or one that introduces a new capability) might be compelling.

Also, in case you didn't know there is also a UserVoice site for general Windows Phone consumer features.

At its core, the sample exposes a LayoutableUserControl and a LayoutablePage that let you specify a set of layout rules that are evaluated every time the control is re-measured. Each rule implements the ILayoutRule interface that exposes a mechanism to check if the rule applies given the control's current size (ILayoutEvaluator.Evaluate) and a mechanism to invoke the functionality of the rule (ICommand.Execute).

From there some primitive layout evaluators (like WidthLayoutEvaluator - checks if the current control's width is smaller than a given width or not), some primitive commands (like GoToVisualStateCommand - goes to a named visual state), some compound evaluators / commands, and some more complex base types are defined.

The end result is a set of high-level rules that can be used for many basic operations. For example, one of the rules used in the sample is the following WidthUpdatePropertyRule:

<layout:WidthUpdatePropertyRule
  DisplayName="Make buttons smaller"
  Width="550"
  ComparisonType="LessThan"
  Name="ExplorerViewProperties"
  Property="ButtonSize"
  Value="50,50"
  ValueIfFalse="80,80"
  ValueConverter="{StaticResource SizeConverter}" />

As the DisplayName property indicates, this is used to update the ButtonSize property of the ExplorerViewProperties named resource to 50x50 if the Width of the control is less than 550px, or to 80x80 if not. Parts of the UI are data-bound to this object, and so they will update dynamically.

Another example:

<layout:HeightGoToVisualStateRule
  DisplayName="Make text smaller"
  Height="300"
  ComparisonType="GreaterThanOrEqualTo"
  VisualStateName="LargeText"
  VisualStateNameIfFalse="SmallText"/>

This rule switches to the visual state LargeText if the Height is at least 300px, otherwise it switches to the SmallText visual state.

Of course, all pixel values are in effective pixels (aka view pixels). We don't care what the actual physical resolution of the display is. You can also use some of the building-blocks to make more complex rules (at the expense of more XAML).

You might ask yourself why something like this doesn't come standard as part of the platform or the SDK. When we were working on Windows Phone 8.1, we had many discussions about this very topic, but ultimately we didn't ship any layout-helper controls like those in this sample for two basic reasons:

1. There is no tooling experience (Visual Studio or Blend design surface) for these layout rules; you need to reason about them without being able to see the results (or, more likely, take a starting guess and then use trial-and-error to perfect it). There is a tooling experience for Visual States, but not for automatically switching between them while designing the control
2. We weren't able to settle on what the right long-term approach should be for adaptive layout. This is just one approach of many possible approaches, and whilst it is convenient for some scenarios we don't (yet) know what the best solution will look like in the future

Anyway, until such time as we solve the problem in some hypothetical future release, you can use this code (or hack it any way you see fit) in order to get your own apps up and running. If you have comments, suggestions, etc. feel free to post them below!

(P.S. I apologize for the lack of comments in the code. Hopefully when I do a full blog post for the //build talk I will have the code properly commented... and maybe even tested!)

As I mentioned in my //Build talk, the emulator is not a good place to perform visual verification of assets because the display characteristics of your monitor are highly unlikely to match those of any physical devices. But it is an excellent tool for verifying the layout of your apps, and for comparing how the layout changes on the different-sized devices.

If you want the emulators to appear on your monitor in the same relative sizes as they would appear in real life, you should follow this set of zoom factors:

• Figure out maximum zoom for the 6" 1080p emulator that fits on your screen
• For the 5.5" 1080p emulator, multiple it by 0.92
• For the 4.7" 720p emulator, multiply it by 1.18
• For the 4.5" WXGA emulator, multiply it by 1.11 (it is mislabeled as 4" in the RC SDK)
• For the 4" WVGA emulator, multiply it by 1.57

So for example if you have a 1080p desktop monitor, these are the values you should use:

• 6" 1080p: 45%
• 5.5" 1080p: 41%
• 4.7" 720p: 50%
• 4.5" WXGA: 53%
• 4" WVGA: 71%

Those values will give you emulators that show content at the correct proportional size relative to each other. You might wonder why the numbers are so strange - for example, wouldn't the 4" phone just be 2/3rds the size of the 6" phone? - and the reason is that in addition to being different sizes, these devices all have different pixel densities. But your monitor has a fixed density and so we need to take that into account when calculating the sizes. Also there is a small adjustment for the 15:9 vs 16:9 aspect ratios.

You can verify that you have the right ratios setup by running the sample app from https://aka.ms/wpsllarge and going to the "size-aware page" and looking at the bottom image of the US 1 cent coin ("penny"). The bottom image will be the same physical size on all your emulators (but probably not the same size as a real penny... that only works if you run it on an actual device :-) ).

Thanks to everyone who made it to my talk, which is now available online (so if you didn't make it, you can watch it now!). Also, thanks to everyone who has provided feedback so far! If you saw the session and haven't evaluated it yet, please do (and all the other sessions you see, too!). This helps us make these events better in the future.

One person mentioned that the "40 inches" in the title was a bit misleading since I didn't discuss the Perspective Pixel devices (aka PPI).

Firstly, THANK YOU (whoever you are ;-) ) for providing the feedback!

Secondly, it's true that apps explicitly designed for the PPI devices benefit from specialized UX that is tailored to the usage pattern of those devices, and unfortunately I could not cover that in the talk. It's also a statement could apply to all specialized use-cases (any app could benefit from specialized UX on phones, tablets, PCs, etc. although it is not required). But in a general sense, all the concepts in the talk apply. The "small" PPI device is 55" diagonally, has a raw density of 40 dpi, and a physical resolution of 1920 x 1080 pixels. It has a scale factor of 1.0 and an effective resolution of 1920 x 1080. That means that for general apps, the PPI is no different than a standard 24" 1920 x 1080 monitor. It has the same effective resolution, the same scale factor, and would run apps exactly the same way. This is why the talk really focuses on ignoring the physical aspects of the device (size, DPI, etc.) and focusing on the effective resolution.

But there will always be an opportunity for developers to go further and tailor their apps for specific use-cases. In this example, if you wanted a special UX for the PPI, you could check if the DisplayInformation.RawDpiX property was <= 40, and that the effective resolution (ActualWidth and ActualHeight in XAML) was >= 1920 x 1080, and if so infer that you were running on a really big display.

Also, I wanted to give you an early look at the LayoutRules helper code I wrote for automatically switching between visual states in XAML. Eventually there should be an official post on the Windows Phone Blog, but in the mean time I put together a quick Universal Project showing how to use it (the original sample, which wasn't as good, can be found here). Enjoy!

LayoutRulesTestApp.zip

D:\Path\ProjectName.vcxproj : error : Unable to read the project file "ProjectName.vcxproj".

D:\Path\ProjectName.vcxproj(60,5): The imported project "C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\ExtensionSDKs\SQLite.WP80\3.8.0.2\DesignTime\CommonConfiguration\Neutral\SQLite.WP80.props" 
  was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Fixing this is pretty easy, but requires manual editing of the project file. Here's what to do:

1. If the project is under source control, check it out first. You need to do this manually from the Source Control Explorer, since right-clicking on the Solution Explorer won't work
2. Open the project file for editing (either from the Source Control Explorer or by right-clicking on the project in Solution Explorer and choosing "Edit ProjectName.vcxproj")
3. Search for "SQLite.WP80" in the source code; you should get 9 hits on 5 different lines (the number may vary depending on how many build configurations you have)
4. The first set of hits should all be inside <Import> statements. Look for the version number after highlighted search text (eg, "3.8.0.2") and replace it with the new version (eg, "3.8.2")
5. The last hit will be at the bottom of the file, and is in an <SDKReference> element. Again, replace the old version number with the new version number
6. Save the project file
7. Restart Visual Studio. Important: do not try to re-load the project; it won't work. You must restart Visual Studio
8. Reload your project and build; it should work
9. Check the changes back into source control (if applicable)

In theory you could just do a search-and-replace for the old version number with the new version number, but just in case something else in your project has that string, I prefer to do it manually (it's not very difficult).

I’ll still be posting on my personal blog (this site) from time to time on topics that don’t “fit” in the larger WPDev blog, but most of the meaty stuff will be on the official blog. I have a bunch of ideas for content that should be published throughout the coming months one way or another, so stay tuned! Note that after this initial post I won’t be announcing any of my WPDev posts here; I’ll assume you’ve either subscribed or that your search engine / social network / microblogging service of choice will point you in the right direction.

What do you think of this change? Love it? Hate it? Let me know in the comments below.

Oh, and Happy New Year everyone!

Yes, in Windows Phone 8 we have added the Application.Terminate method so that you can quickly exit your application in the case of insurmountable roadblocks such as the user refusing to accept the EULA or not signing into their account. As noted in the docs though, this is not a "clean" shutdown (you will not receive any navigation events nor any lifecycle events) so if you have any state to save, you need to save it first.

The guidance from the previous two posts still stands -- in general you should not need an "Exit" button in your app, nor should you normally need to terminate yourself -- but in the cases where you really really really need to, now you have a better option than just crashing.