One app runs but others will not

May 7, 2012 at 9:18 PM

I was helping a partner deal with an issue today where all apps would build but only one of them would run on the device. It took a long time for me to track this down so I wanted to share the final solution.


How I found the issue


Here are the steps I ended up going through to figure out the issue:


  1. Used AppFactory to build a single app (AppName='xyz')
  2. Started Visual Studio and opened the solution in the Working folder (instead of the template folder)
  3. Changed the target to ‘Windows Phone Device’ and hit F5 to debug on device
  4. Output window showed a first chance exception KeyNotFoundException
  5. Under Debug -> Exceptions I checked the box to halt on all thrown exceptions (instead of the default which is only halt on unhandled exceptions)
  6. Stopped the debugger and started it again


At first this didn’t make any sense to me because KeyNotFoundException happens when attempting to access something in a dictionary that doesn’t exist. But then I realized that the resource string for App.xaml and MainPage.xaml included the text “component;”.

 The “component;” designator means that the resource will get loaded from inside the main assembly (or .dll) file. Then I noticed that under project properties the partner had changed the assembly name to match one of the applications (the one that was actually working on the device).


A little more detail


.NET assemblies are.dll files with some extra metadata information in them. An assembly has a file name, just like any other file, but it also has an assembly name in the metadata. The file name and assembly name are normally the same, but they can be different. When the “component;” designator is used, it’s telling the system to load the resource from inside the assembly. So no matter what the .dll file is called, the internal assembly name has to match the “component;” resource string.


In this partners case, the text that came before the “component;” designator was CordovaStarter1. That’s what their project was originally called. Namespaces can change all day long, but if the assembly name changes we have to fix up the resource strings.

 I never came across this problem before because in my case (and in the case of the other developers using it) we left our project and the assembly name something generic like “Template” or “MusicEngine”. Then only the .dll and .xap file names changed, so the internal assembly names were still intact.


To fix this I updated the partners template project and assembly name to be generic (e.g. “MusicEngine”). The application title still changes, as does the dll and xap file names, but the internal assembly name does not. It remains "MusicEngine" across all apps, which is perfectly OK and will not clash.