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.

One more way to setup NTU’s VPN in Windows 8.1

If you are working or studying in NTU (Nanyang Technological University), you may want to connect to NTU’s VPN from home sometimes (for some remote desktop for example). I have tried to follow the instructions at http://www.ntu.edu.sg/cits/itnetworking/remoteaccess/Pages/quickstartguide.aspx. Those methods works great on Windows 7, Windows 8.0 and Windows 8.1 as well. However, I don’t really like to install Juniper or NTURAS VPN on my laptop, mainly because it is already very messy and I don’t want to make it any messier, so I tried to setup a VPN connection manually and now it becomes so convenient connect.

Continue reading the instructions

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 →

How searching has changed in Windows 8.1

There have been many welcome changes from Windows 8.0 in Windows 8.1, both in the users and developers’ perspective. However, I believe not all of those changes are really improving the user experience (I still think some are only make to dodge the media critics). One of those is the introduction of the hero Search screen, where your search result is now the accumulation from installed apps, Windows settings, local files, Windows Store and Bing results (including some big images and information about the recognized entity, Web images, Web videos and websites). I remember they said about one page where you could get the search results from everywhere, but I still do not see search results from data inside my own apps.

Continue reading my comparison and opinion