Could not load satellite assembly - Why doesn’t my app work on WP8 (part 4 of N)

While beginning to port our app Terminator to WP8, we were faced with an exception in App.InitializeComponent of the type MissingSatelliteAssemblyException

We started terminator way back in the Windows Mobile 6.5 days, and it was one of the first apps we produced for WP7.

At some point in the distant past, (November 2011 to be a bit more precise) the store changed so that you needed to add something like this to your assembly attributes:

[assembly: NeutralResourcesLanguage(“en”)] or as suggested by some here:

http://stackoverflow.com/questions/6741455/the-neutralresourcelanguage-attribute-is-missing-on-the-entry-assembly
[assembly: NeutralResourcesLanguage(“en”), UltimateResourceFallbackLocation.Satellite)]

Unfortunately, I chose this second option, and that’s the source of the error.

Removing it solved the problem.

Why does System.GetType return null–Why doesn’t my app work on WP8 (part 3 of N)

While porting our Skied Demon Ski logger app to Windows Phone 8 to support background location services and new wide tiles, we stumbled across a problem calling

System.GetType(“typename, assemblyname”) where it would always return null.

While GetType worked with a fully qualified assembly name, that struck me as bad for maintainability as I’d have to remember to change it whenever something changed, and because it was loaded by reflection, it wasn’t likely to go away completely.

After some investigation, I finally came up with this helper method:

static Type GetTypeEx(string typename, string assemblyname)
{
   foreach (var a in AppDomain.CurrentDomain.GetAssemblies())
   {
      if (a.GetName().Name == assemblyname) return a.GetType(typename);
   }
   return null;
}

So I now call it like this:

GetTypeEx(“typename”, “assemblyname”);

I only do this a couple of places in the software, but if I were to make heavy use of reflection, I’d probably cache the assembly references into a dictionary to save the iteration.

What an obscure bug - Why doesn’t my app work on wp8 (part 2 of n)

We’ve just submitted a new update for Skied Demon, our GPS logger for Windows Phone, and while testing by cycling, we noticed that the top speeds weren’t updating.

But we also noticed that this only happened on Windows Phone 8.  The exact same program running on WP7 works fine.

Originally, we thought there was some problem with our data notifications, and then we noticed that the updates failed only after running behind the lock screen.

It turns out, that on WP8, calls to Obscured and Unobscured events are not balanced as they were on WP7.  Why exactly my app would care that it’s been obscured even though it’s already had the message is a bit beyond me, but that’s the way the new API rolls, I guess.

We’ve now submitted an update to the store.

Why doesn’t my app work on wp8 (part 1 of n)

We recently switched over to a Lumia 920 for testing our apps, and have found that some of our apps just don’t work correctly.

For instance, our popular Skied Demon ski logging app exhibits problems on Windows 8 on a Lumia 920.

It turns out that the problem is caused by setting up BitmapCache as the CacheMode on some of the controls to improve performance.  The ironic thing is that this fails on Windows Phone 8 and not on Windows Phone 7.

This may also be caused by the increased screen resolution on this particular phone though I haven’t yet been able to verify that.  I suspect that what’s happening is that a bitmap is being constructed for the size of the zoomed area.  As that size grows, eventually the entire thing falls apart.

However, I would have expected WP8 to behave at least as well as WP7.

So, that’s one (of presumably many to follow pitfalls, as we know at least one more of our apps is currently not working, probably caused by a store issue)

How to use Microsoft.Bcl.Async correctly on XP

We recently updated our Terminator for Windows Desktop application to use the async/await features and still target .NET 4.0 so our XP customers can continue running the program.

So, first we updated our copy of Visual Studio 2012 to the latest and greatest release 2, and installed NuGet too.  So far so good.

Our installer is based on WiX, so we also updated to version 3.7, but we built our own bootstrapper, so we ported that to VS 2012.

Unfortunately, that led us to discover that a regression causes VS2012 Rel 2 to produce programs that don’t actually run on XP, as described here on connect, but luckily there’s a solution that works on the workaround page

That’s the first hurdle down.  So, we then added support for Microsoft.Bcl.Async by typing into the NuGet Package Manager Console:

Install-Package Microsoft.Bcl.Async

From there we could target.net and declare async entry points and await them to our hearts content.

So it came time to obfuscate.  We use EazFUSCATOR.net, which lets you trial for free for 30 days.  We’ve found it well worth the investment to purchase this package, which also gives support.  Unfortunately, VS2012 and Microsoft.Bcl.Async broke Eazfuscator 3.7, but the team there pulled out all of the stops and got us a beta that fixed the problems we’ve had within 24 hours of each problem.

So, we were good to go.  We tested it all and everything seemed hunky dory.  The only thing was, we started to notice that the async routines seemed to be very async.

how ASYNC?

Well, so async that they never, ever completed.  This was a bit of a puzzle.  It appeared that the methods were never completing at all.  So what went wrong?

It turns out that you must actually install some new DLL’s when you install your package, or it will just fail silently (which was the real surprise).

• Microsoft.Threading.Tasks.dll
• Microsoft.Threading.Tasks.Extensions.Desktop.dll
• Microsoft.Threading.Tasks.Extensions.dll
• System.Runtime.dll
• System.Threading.Tasks.dll

Needless to say, we’d forgotten to add these into our WiX installer, and as a result the machines that were using the installer were failing to fetch the cloud overlay, until we added them.

A discrepancy between the solution’s source control information

Yes, I’ve been battling with my source control provider (Source Safe) and Visual Studio 2012 Pro.  I add my solution to source control with the menu item, and everything appears fine.

However, when I close my solution and then reopen it, I get this gem:

I’ve tried reconstructing my project from scratch, and keep bumping into this problem or variants of it.

Searching the net doesn’t really turn up much helpful.

After 5 hours, I’ve finally found what appears to be the problem.  In each .vcxproj and .vcproj you’ll find a line like this:

<SccProjectName>"%24/Products/WPF/education/DesktopTerminator.root/DesktopTerminator", FAUAAAAA</SccProjectName>

The problem is the %24.  Changing it manually to $ fixes the problem!  To fix it, right click each project, select unload, then select Edit, and make the changes, then select reload.

Now it turns out there is some other chatter about it here on social.msdn and here on connect

Notice that on connect it will be fixed in the next major version of Visual Studio.  So, for now, keep editing those projects.