Universal Apps: partial understanding

One of the ways to build a universal app is to use the partial keyword to allow you to split out functionality that must be different between platforms.

We tried this with our error reporting code, loosely based on LittleWatson.

There is good documentation here http://msdn.microsoft.com/en-us/library/wa80x488(v=vs.90).aspx on partial classes, but despite what it said we just couldn’t get it to work correctly.  So we concocted more and more bizarre ways to use partial, so that the program would compile, including partial methods (which unless implemented the compiler optimizes out).

In the end, it turned out to be nothing related to partial at all, that was preventing our methods from being called.  What had actually gone wrong was this:  We had inadvertently put half of the partial class in a different namespace, thereby making it invisible.  It’s no wonder we couldn’t find member fields in our main implementation.

Pitfalls of adding WP8.1 support to a universal app (Part 1 of N)

As part of our continuing port from Windows 8.1 to WP8.1 of Surface Level, I’ve just recently tracked down a problem thrown during suspension.

We’d already written quite a few classes that would act as a base class, and as a result, I implemented a partial method which I could call for certain tasks.  One of these tasks was registering our Suspension handler.

The bug I was seeing was an end of file reached while reading back our state file, which we use when we resume.  But there were two problems

1.  I kept getting odd suspension manager exceptions in my crash logs.
2.  The suspended handler never seemed to be called anyway.

Item 2 was the first to solve.  It appears that like W8.1, apps aren’t suspended when run in the debugger.  The only problem was, I couldn’t find the UI to shut it off.

Well, eventually I found it here on the Debug Location toolbar:

Clicking Suspend actually caused my suspension to run (twice in fact)

The first crash was caused by the state file being read only (a side effect of running suspension twice).  It turns out that when I added the WP8.1 project, the wizard had added a second call wiring up the suspension code, which I hadn’t spotted.  Removing the duplicate wiring allowed me to get suspension working properly.

VS2013.2 : One step forward, two steps back

We try to make it really easy to put together a new application by using the Export Template feature of VS2013 Pro.

Currently we have one template for all of our windows 8 apps, and another for our windows phone apps.

To start a new application, we use VS2013, and say File | New Project

Select our template and we’re off.  In that state we already have our view models, initialization and serialization frameworks, etc.  All of these are built from source files, and aren’t in a class library anywhere, and using templates makes it very quick to create a new independent branch.

We thought that with the advent of the new Universal Apps, we might be able to solve these problems once and for all, however, it isn’t working out like that.

The export template functionality is still there, but it doesn’t work.  You can export the shared project (but that doesn’t show up on the new project templates), and you can try to export either the WP or Windows Store projects, but they fail throwing an error about bad characters in the path.

So, from what I can see, we’ve lost this great functionality.

It appears that you could code up a template by hand by hacking through what’s in the universal app templates, but I’m not sure I can be bothered to at this stage.

With any luck, I’ll find a solution, and post it back here.

Upgrading a C++/CLI project to VS2013 from VS2010

Today, I begin to update an old C++ project to the latest compiler, and while building got this error message:

1>stdafx.cpp : fatal error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable

That’s all very well, but it wasn’t obvious what to do.

Here’s how I solved it:

First, I created a new CLR Class Library project with C++, and examined the vcxproj file generated.

I then took my project that wouldn’t build, and right clicked and said, unload project, followed by edit on the same project.

Looking for differences I spotted this:

<TargetFrameworkProfile>Client</TargetFrameworkProfile>

Of course, .NET 4.5 doesn’t support the client profile, and surprise surprise, it now works once I remove that line.

It looks like the VS2013 project upgrade doesn’t quite get this one right.