GenerateWinPRTManifestV2 error

Documenting this as Google was unable to find anything. Bing found nothing exact that matched but a few things that pointed me in the right direction.

I've had some "fun" trying to resolve the following error relating to the "GenerateWinPRTManifestV2" task during build.

Error 255 The "GenerateWinPRTManifestV2" task failed unexpectedly.
System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.CCIHarvestRegistrationInformation(ProcessWinmd processWinmd, Dictionary`2 inprocServers)
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.UpdateWinmdRegistration()
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.ExecuteImplementation()
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()

It turns out that there were two projects referencing different copies of the same library and MSBuild wasn't able to differentiate between them. (They weren't strongly named.)

The fix was just to make sure that all the projects in the solution only use one version of any library.

I hope this helps save someone else some time if they hit the issue and end up searching for the same task name.

Remember. Strong names FTW!

'tis the season to...release apps

We're fast approaching the time of year when more people are releasing and updating apps in time for the big shopping holidays (Thanksgiving & Christmas).

The store typically takes at most 5 working days for processing submissions but they have advised that due to traditionally larger volumes at this time of year things may take longer than usual*.

The announcement was made in the Dev Center forums but you may have missed it. (Don't feel bad, I don't monitor the forums too carefully either.)

If you want the app certified by Thanksgiving, you should submit it by Wednesday, November 20th.

If you want the app certified by Christmas, you should submit it by Monday, December 16th.

If you want the app certified by New Years, you should submit it by Friday, December 20th.

Of course submitting early won't hurt and meeting these dates still doesn't guarantee it will pass certification if it doesn't meet all the requirements.

* For reference I submitted an app on Sunday just gone and it was ready this morning. Taking approx. 4 days.

Be careful about when you interrupt your users

It's common to want to ask your users something. Maybe you want to prompt them to rate your app, provide feedback or update to the latest version.
The way I see most people do this is with a MessageBox being displayed when the app is launched.

I don't think this is the best approach.

I hope you're creating apps with the user and what's best for them in mind.

When a person starts your app they probably have a task, goal or purpose in mind. People don't launch apps to rate them or send feedback, although the desire to do this may come up while they're using the app.

By prompting the user to take some action that you want, you're putting a barrier between them and what they really wanted to do when they launched the app.

Adding a minor frustration just before you ask for a review may not be the smartest thing to do.

I suspect that a better approach would be to prompt the user with such requests when they've done what they launched the app to do.
For some apps it may be harder to identify just when the user has completed what they wanted to do.
As a general rule, prompting when a person leaves the app, rather than when they start it seems to make more sense to me.

Thoughts?
I'd love to hear from anyone who's experimented (and tested) in this area.

Sharing a resource with a TextBox.CaretBrush can cause some weird behaviour

I think I've found another bug in Windows Phone but it seems really odd.
I'm documenting it here before escalating to find out if it really is a bug but I can't believe its intended behaviour.
Maybe you have an idea or explanation as to why this is happening? If so, do please share.

Have a look at this code:

It creates a page that looks like this:

The thing to note is that the CaretBrush on the TextBox, the Foreground on the Button, the Foreground on the first TextBlock and the Fill of the Rectangle are all bound to the same resource.
This is exactly the sort of thing I'd expect to see when wanting to apply the same colour to multiple elements on a page (or app).
What's probably unusual, or somewhat of an edge-case, is setting a custom colour for the CaretBrush, although this is often necessary when using a heavily customised UI. (That's where I first discovered this. - The above is the simplest reproduction I could find.)

So what's special, well, the caret (if you're unfamiliar) is the little line in the TextBox that flashes to show you the edit point when the control has focus.
The odd thing here is that rather than just the caret flashing, in the above example everything with the "colour" bound to the same resource as the CaretBrush flashes too. That what the right hand image shows.

This can be quite an odd experience when you see seemingly random elements on a page start to flash while typing into a TextBox.

Fortunately the fix is easy. It's just to not bind the CaretBrush to the same resource as anything else.
Of course this means you will have some otherwise unnecessary duplication in your XAML though.


My guess is that there's something odd internally with the way the TextBox finds the caret so that it can cause it to flash. If not that the the Brush is remembering the items that reference it in an incorrect way. Either of which are very odd.
I'd love to hear any thoughts on this and will report anything I hear back from official channels.


*** UPDATE ***
I've had it confirmed that this is a very old (over 5 years) known bug with the Silverlight TextBox control. One to be aware of if heavily styling a TextBox and easy to work around.

Why ShellToast may be blank

Just made a discovery that may be worth noting.

If creating a ShellToast with a Title of more than 64 characters (including any whitespace) then the toast will be displayed but the title will not be shown.
If Content is specified this will still be displayed. If no Content is specified then the toast will just include the application icon.

This is both undocumented and unexpected behaviour.
It's particularly unexpected as deliberately specifying an empty string for the title causes an error.
I'm not sure if this is a bug or a built in back door to avoid displaying the title. Either way this worth being aware of when working with toasts.

Why Windows Phone developers should care about large screen devices

Yesterday, in an article on Mobile Industry Review by Stefan Constantinescu, he made reference to a survey carried out earlier this year by Open Signal.
That survey discovered that people with devices with larger screens download more data.

"[with] each additional square inch of screen ... 288 MB more data [was] downloaded per month,"

What does this survey mean to Windows Phone developers?
The survey is based on Android users so there's an argument that it might not directly apply. I don't see a big issue with assuming that the results of the survey can be universally applied. Anyway, it's not as if such a survey is really possible of Windows Phone users just now as the range of devices currently available would prevent such a survey being possible.

Why might this be the case?
Why would people use more data (over Wi-Fi) with larger screen devices?
I can imagine a couple of reasons:
1. Apps (and websites) may be downloading larger assets (images) on larger devices to prevent the best looking content to the user. If this was really the case then I'd expect increased data usage not only on Wi-Fi though.
2. People usage larger devices differently to smaller ones. We "know" this. But sometimes it's easy to forget. Different sized devices are used by different people, in different ways and at different times. Larger, handheld devices are used more for consumption than a "phone" traditionally is.

Why should Windows Phone developers care?
Nokia's new Lumia 1320 and 1520 devices will be available shortly. They are considerably larger than the Windows Phone devices currently available and so are likely to be used in slightly different ways and the above survey results may apply.

What can we do with this information?
Regardless of personal opinions about so called "phablet" devices it's worth remembering that some people like them and that they may use them differently to traditional phone size devices.

It might be tempting to assume that more data usage means more apps are used. I don't think this is the case.
I'd expect that apps are rather used for longer as is the pattern for larger tablets compared to phones.

If you're a developer working on a Windows Phone app that is focused on data consumption then the above survey should help confirm to you that making sure the app can provide the best experience on ALL devices is in your interest and that of your users.

Stopping a live tile from flipping

Sometimes you may want to remove the contents (and images) from the back of a [flip] tile to stop it flipping. How to do this isn't always obvious and it can be frustrating to discover that just setting the content to an empty string or null doesn't work.

To stop a tile from flipping you must clear it’s content, not just set it to an empty string.

Unfortunately the FlipTileData class doesn't provide a method or property to make this easy. Instead you must use an XML document that contains appropriate FlipTileDate template information.
Something like this:

var clearTileBackXml = new StringBuilder();

clearTileBackXml.Append("<?xml version=\"1.0\" encoding=\"utf-8\"?>");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");

var ftd = new FlipTileData(clearTileBackXml.ToString());

ShellTile.ActiveTiles.First().Update(ftd);

If you’re updating anything other than the primary tile you need to set the Tile ID in the XML as well as select the correct element from the ActiveTiles collection.

For more info and to see the full template go to MSDN.

Why MP3s may not play on Windows Phone

What follows is the result of at least 4 man-days worth of effort involving at least 6 different people. It ended with a solution that had people in disbelief at the simplicity of the workaround and the probable cause.

For the most part playing music from within an app is simple and there are lots of ways to do it: background audio; MediaElement; or launcher.

Sometimes things go wrong though and last week was one such time. I was asked to look at a bug in a new app that plays music. The bug was that for some tracks there is an obscure error when playing from isolated storage. If the file is copied to the PC from isolated storage then it plays fine though.

In the exception, with it's entirely external call stack, we could see a HRESULT of 0xC00D36C4 or a message of -1072875836. Neither of which are particularly helpful.

Even the internet couldn't give us much help. All we could find was a constant name of MF_MEDIA_ENGINE_ERR_SRC_NOT_SUPPORTED for the hex value but that was in a streaming video context. This didn't really help at all.
Beyond that we found records of bugs relating to playing some audio files on Windows Phones but these had all been closed and marked as "no repro".

I looked at files sizes when the tracks were downloaded on the phone and on a PC and everything looked the same.

After much experimentation I realised there was a step in our reproduction process that hadn't been fully explored.
When files are saved on the phone they were given name based on their identifier. This meant that in IsolatedStorage they looked like: "/tracks/tr123456".
When copied to the PC we were renaming the file to include an extension (of ".mp3") so we could double click them to try and start playback.
Starting to approach the limit of possibilities, I wondered what would happen if we tried to play the file with the ".mp3" extension on the phone. Low and behold the track started playing on the phone without issue.

So, the fix?
Just make sure that the files all had a ".mp3" extension on them and they all played fine. Yes, really that simple.

Why does this solution work?
Here's what I think is happening:
Without a file extension to tell the internal media stack what format the file is it guesses, probably based on looking at part of the files contents. In the instances where the file will not play correctly it is probably assuming that it is not a regular MP3 file, even though it is, and so tries to play it assuming a different format.
I must admit that my knowledge of the internals of the MP3 format is non-existent and my knowledge of the internals of the media playback stack is even smaller but this seems to be the most likely theory.

What can we learn from this?
Always include a file extension on your files. Not only does it make it easier/clearer for people to see what type they are, it also help the OS know how to read/play/process them.

Really glad to see all that PhoneGap effort paying off

If this comes off as a bit self-congratulatory then so be it. Sometimes my trumpet needs blowing and there isn't a big queue of people lining up to do it for me.

Earlier this year Microsoft ran a competition (challenge) to bring existing apps built with PhoneGap (Apache Cordova) to Windows Phone.
Recently, Microsoft highlighted and interviewed the winning apps again.

I'm especially pleased to see this.
Back in the summer of 2010 (yes, so long ago) I spent some time building what became the Windows Phone version of PhoneGap and then Cordova.

Honest. Look, here's a screenshot of the network graph from GitHub.

This was done at a time when there were questions about the ownership of the apps I built in my own time, with respect to my then employer.

Rather than spend my time building apps I might have to argue for ownership of I spent my time on other things. I spent a lot of time answering Windows Phone related questions on Stack Overflow and working on open source projects like the WP7 verison of PhoneGap.
I was familiar with PhoneGap from having used it to build iPhone apps in 2009 and saw that it would be beneficial to Windows Phone as a platform if it was easy for existing PhoneGap apps  to be repackaged and retargeted at WP. As there wasn't anyone else working on it at the time I decided to step up.
Unfortunately the performance of hybrid apps on Windows Phone 7 was a long way off that of native apps which greatly affected it's adoption. Fortunately things greatly improved with Windows Phone 8 and more apps are now being built and ported over from other platforms.
While I was only involved at the beginning when it came to the amalgamation of Windows Phone and PhoneGap/Cordova I still like to think I played a part and remember fondly the work I did at the time.

I look forward to seeing more great apps being built with PhoneGap in the future. :)

App Studio has been updated and shows some improvements

Having been critical of App Studio in the past and noting some of its short comings, the fact that it was recently updated deserves a review of these latest changes.

Rather than revisit the app I produced as a test previously I decided to go through the whole process of creating a new, minimal, app of the most basic variety. An app that just shows content from a single RSS feed.
For fun, this time, I've built it based on this blog. Not really a site that would justify and app but a fun source of content for me to play with.

First the good news
There are definitely improvements in the apps being generated now.
The biggest improvement is the offline/data caching support.
In turn this means that the apps that are generated could be submitted to the store and should not fail store certification testing.
There are also additional configurable options on the site which adds further improvements to the generated apps.
The generated code also no longer includes unused additional libraries. This brings down the size of the XAP file and in this instance smaller is better.

The bad news
Things are still far from perfect. Here's a few of the most obvious things I noticed:

 

 

• Images aren't well formatted. It appears that a square version of images is created for reuse and this is used regardless of where it's displayed in the app. The square image is also very small and so can be hard to read when scaled up. Especially when the image is tapped to show a larger version.

• On the page showing details all text is in a single control. This suffers the limit on the amount of content that can be displayed in a single control and so some of the text isn't visible.
• The alignment and spacing on this page is also consistent.
• If scrolled part way down an article/story/post and then you swipe to the side to go to the next article the scroll offset isn't reset so the new article is displayed part way down.
• The details page contains the same page header as the panorama. This is unnecessarily large and a waste of space by providing undue prominence to the screen element that probably isn't even needed on the page.
• Reading of articles (via TTS) still doesn't have a way to stop the reading once started and selecting it multiple times will queue multiple readings of the story.
• Pinning an article still creates a poor quality live tile. (If I don't blog about live tiles more soon - pester me about this.) There also isn't anything to tell you when an article is already pinned. Trying to pin it again just does nothing.

• The spacing between articles isn't consistent. Presumably because whitespace at the end of the snippet that is displayed isn't being accounted for.

 

• The "go to source" link from the app bar which should take the user to the original article in the web browser doesn't always work correctly. It appears to just be using the first link in the source XML but this isn't always the one you want. In this instance it's the "application/atom+xml" link to post comments. As you can see from above this doesn't lead to the appropriate content being displayed.
• This incorrect link is also picked up when trying to share the article/link.
• In terms of sharing: Sharing a link populates the message with much more text than can be supported by many of the share services, such as Twitter and its 140 char limit. When sharing a status or by email the default message includes the HTML from the original article.

These are all simple issues that should be trivially simple to identify and hopefully they are already in a bug list somewhere. If not, I can only figure it's because they're having as much difficulty hiring testers with Windows Phone experience as I know a number of other companies are.


The reality
I've only looked at a tiny part of what's possible with App Studio but what I have looked at is amongst the simplest of things that are possible in an app and even basic things like standard alignment and spacing aren't correct. This doesn't encourage me that the more complex elements and functionality are better implemented.
App studio is still a very long way off producing something that is anything but basic without further modification. But it's not all bad and still in development so further improvements should be coming.
Having such a tool is a great start in terms of having some code as a starting point for building upon, but, alas this is not all that it's being used for.
I have a feeling that this tool is seen by some within Microsoft as a quick and easy way to help boost the number of apps in the store. Unfortunately I don't think that consumers want a load of generic apps. Just filling the store with them only really helps the people who get measured on the number of apps in the store.

What the tool really needs is a guide to go with the generated xap/code with more detailed advice on how, why and where things could and should be changed to help make a high quality app. While the studio is in such a state of flux and development such documentation would be impractical though. Hopefully such a guide will be produced once App Studio gets out of beta.


If only I had the time to fix all the issues...or even just point them all out. :(