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.