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.

BT 2-Wire Business Hub handing out wrong IP Address

One of our clients had a hard drive crash that prevented them booting into Windows.  As the machine was pretty old, and running XP, we agreed that it was a good time to upgrade to Windows 8 and snappy new hardware.

Everything went well, we managed to reinstall all of the software on the new machine, and transfer over all of the data.  We even managed to make a VHD image of the old broken hard drive, and copy that onto the new machine.

As the machine was the network server as well as one of the workstations, it seemed the best plan was to keep the machine name the same, so that the new machine could impersonate the old one.

The only problem was that the BT Hub was insisting on handing out the IP address of the old, dead machine (192.168.1.100) instead of the one assigned to the new machine via DHCP.  And there seemed to be no way to get the Hub to forget about the old machine.  Sometimes it returned 127.0.0.1 and others it returned 192.168.1.100, but never it seemed 192.168.1.64

This problem dragged on for a couple of weeks, until finally I noticed the problem.

The BT hub has case sensitive host names.  The old machine was STUDY, and the new machine was study.

When a lookup of a host name was requested, the old machine was first in the table, and a case insensitive comparision returned that, instead of the new lower case machine.  Why the Hub compares as case insensitive but inserts as case sensitive appears to be a bug in the firmware.

The FIX?

Simply rename the machine on the control panel to be the old upper case version.

1and1 changed my .htaccess file!

Over the last few months I’ve had sporadic random changes to the .htaccess files on my website.

I looked again today when I noticed that some of my sites I look after are behaving incorrectly.

The .htaccess file had been changed to this:

AddHandler x-mapp-php6 .php3 .php4 .php .phtml

More to the point, all of my changes were gone.

What caused it?

I have a hunch.  The changes that occurred at various places on my website occured at pretty much exactly the same time as I added an additional domain to my package.

So the moral is, if you’re using 1and1 for hosting, and ever add a domain, they’ll break the rest of your websites.

I haven’t had any useful help from 1and1 on this.  They’re claiming that someone is hacking my site, but the logs don’t show anything, so I think that’s unlikely to be the cause.  My money’s on the hunch at the moment.

Windows 8 Winhlp32.exe

It seems Microsoft just can’t get this one right.

Installing some old legacy apps that use Winhlp32 for their help leads you on an out of the box install of Windows 8 to this page:Windows Help program (WinHlp32.exe) for Windows 8, which is KB917607

Unfortunately, installing this update doesn’t actually help on a 64 bit system.

When you do try to launch the installed winhelp, you get a partial title bar describing the problem.

Digging out Spy++ reveals that the actual title continues:

“located in the System directory.”

Moving the file there unfortunately, doesn’t actually help.

So, for the moment, I’m uninstalling by running the downloaded msu file from the update from an elevated command prompt like this:

windows8-RT-kb917607-x64.msu /uninstall

Attempting to install the Windows8-RT-KB917607-x86.msu on either a 32 bit or a 64 bit system claims that “this update isn’t applicable to your computer”