Some mid-night thought from the TechEd keynote

It is almost morning, but TechEd is so much exciting, so I cannot go to bed yet. Besides that, Visual Studio Update 2 is also installing so I cannot write codes either. So I will jot down all the excited features that I have just learned from the keynote.

Visual Studio Online API

Just one word: AWESOME! I have been waiting for this for too long.

Recently I have migrated all my project codes to Visual Studio Online from my previous Subversion provider. Moreover, with the extensive support for project management in Visual Studio Online, all my app’s backlogs and bugs are recorded here as well. The current VSO web portal has many great and advanced features; unfortunately, it lacks a responsive design for smartphones which is very important for me when most my development is for the phone and many of my tests are on the phone itself.

I always imagine about detecting a bug or thinking of a new feature when using the app and then being able to add it immediately to the backlog in a simple phone app (voice control could be cool as well, something like VSO record a bug for XXX app about …). It is now all possible with the introduction of VSO API.

Even more than that, the team has also released WebHooks as well. So not only can you poll your backlog for information, but you (and your code) can also know exactly when something has changed. Let’s say you can write some code to easily send your phone a toast when your backlog items are changed by other team members!

Azure API Management

This one is also a very nice feature that has just come to Azure. Basically this API Management is a proxy to your current API, where you can map new endpoints managed by API Management to your existing Web API endpoints. In addition, this proxy does provide you with so many useful facilities, for example, a developer console with example generation, testing support and a management console with throttling, caching, analytics, notification, security and many convenient functions for your APIs. You can also customize your developer console by changing LESS variable, adding posts, navigation items and widgets.

New & Exciting Microsoft

Microsoft has so many great products through out its history. However, with the new focus on services, Microsoft is now opening up many of its services (e.g. OneNote, OneDrive, VSO, Office 365, etc.), which is so nice for app developers and so nice for my imagination.

Let’s start some new projects right away!

Passing Async Task functions as a parameter

Some Motivations

If you have programmed Windows Phone or Windows Store apps, you may know about Dispatcher in Windows Phone or CoreDispatcher in Windows Store. In this article I will focus more on Windows Phone implementation, but basically this should be very similar in Windows Store.

In general, those dispatchers are ways to marshal UI interactions from a background context (any context that is not the UI context) to the UI. Trying to directly access (both read and write) any UI control or any view model property that has been bound to a UI control from a background context will trigger an UnauthorizedAccessException. Instead you will have to call Dispatcher.BeginInvoke(Action action) method (or Deployment.Current.Dispatcher.BeginInvoke(Action action) if you are not in a page) and put all the UI accessing codes in the action parameter.

It work perfectly fine until I tried to introduce some async logic inside.

You could do it simply this way:

Read More

Windows.Launch contract failed with error: The app didn’t start

I recently met a problem with my Windows 8 app, when only the splash screen’s image showed up and the app crashed. Even App object is not initialized yet so there’s not much I can do with the debugging tools in Visual Studio.

I tried to check Package.appxmanifest, but nothing seemed strange there. Project properties also looked perfectly ok. So I tried to dig in the Event Logs. A quick look in Microsoft-Windows-TWinUI/Operational log (inside Applications and Services Logs/Microsoft/Windows/Apps) revealed several error logs: “Activation of the app <app name> for the Windows.Launch contract failed with error: The app didn’t start.” but there was no other useful information. Searching on the internet did not help either.

I decided to take a look at the changes from last revision, and l suddenly realized the file app.config was added to the project. I suppose Nuget or VS somehow misunderstood the project type and put the file there for assembly binding, and this file prevented app activation from complete successfully. Removing the file and everything go back to normal.

I have already met the same problem before (and I believe someone has also written about this), but I completely forgot about it, and it cost me so much time. So I decide to write the solution down here, to make sure I can solve the problem faster in the future.

SignalR, camel case and a lost of connection problem

The Problem

Today I went into a problem trying to configure SignalR to automatically serialize my data contracts in camel cases. Having done that once for Web API, I knew that it can be done easily by changing the contract resolver of JSON.NET to CamelCasePropertyNamesContractResolver. So I went ahead and incorporate the new ContractResolver to SignalR:

It looks good and everything run without a warning or error except that SignalR is no longer be able to connect to the server. I confirmed this by putting a breakpoint inside this function.

At first I did not realize the culprit was the camel case, so I try to dig deeper under the hood. I used the new diagnostic tool of IE11 to see what’s going on and compared with a previous version to see what’s going on. I could clearly see that the new version lack the 2 calls: connect and send although the negotiate when through successfully with a 200 response. (The first image was the SignalR calls in the new version and the second image was the SignalR calls in the old version)

image4

image12

I decided to dig even deeper into the negotiate response, and I found the culprit. The property names here suppose to be proper case, not camel (so it should be Url instead of url). So probably SignalR cannot interpret the response!

image8

The solution

This problem was actually solved properly by several people.

http://msmvps.com/blogs/theproblemsolver/archive/2013/03/14/signalr-and-camelcase-data-contracts.aspx

http://blogs.msdn.com/b/stuartleeks/archive/2012/09/10/automatic-camel-casing-of-properties-with-signalr-hubs.aspx

The basic idea was to change the contract resolver but limit the effect of camel case to only classes external to SignalR. I tried the solution in the first link and it worked like a charm! It’s great to learn that today!

Async void is not the only way to fire and forget

I have developed several apps for Windows 8 and Windows Phone 8, and I am always amazed my one new feature that was introduced to the C# compiler: async and await.

If you are not familiar with the new async feature of C#, you could try to search for “C# async programming” on the Internet or go to this page on MSDN to read the documentation:

http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx

If you have already used async/await for a while, you must be aware of the danger of async void (aka “fire-and-forget”), which could creates unobserved exception easily. In other words, you cannot simply use a try-catch block to catch the exception if you are awaiting an async void. There are already many blog posts and videos on this topic already, so I will not describe it again here. You can have a look at this video if you want to know more about the problem of async void:

http://channel9.msdn.com/Series/Three-Essential-Tips-for-Async/Tip-1-Async-void-is-for-top-level-event-handlers-only

Continue reading about another culplits: Task.WhenAny →