VS2013 deploys Windows Phone app to emulator only after 'Rebuild Solution' command

Question

Something weird happened to one of my C# Windows Phone 8 Silverlight projects.

It's a simple page with one TextBox I'm experimenting with, building a customized style for it. First I placed a TextBox on the PhoneApplicationPage, generated a style template for it using the 'Edit Template\Edit a Copy' command from the context menu in the designer. Now I'm changing some setters and property values in the style, but when I hit F5, an old version of my project is launched in the emulator - all my recent changes aren't taken into account. The latest changes are reflected in the launched app only after I issue the 'Rebuild Solution' command from the Build menu.

The XAML markup has no errors, and it seems all stuff is correct. Other WP8 projects are built and deployed to the emulator ok too. The problem does not depend on the selected emulator (WVGA 512Mb, 720p, etc). Restarting VS/emulator has no effect too.

What it can be and how to fix it?

---

Some more info. For any normal project I see this in the Output window when I hit F5 (the app full path was shorten to save space):

But for the problem project, the output log ends on the line '1> Xap packaging completed successfully' and the old version of the app is opened in the emulator immediately.

Answer 1

It seems, I have managed to find the reason of this strange issue. This can happen if the name of a WP app includes spaces! I noticed that if we create a new project and use the space character in its name, the spaces are replaced with the underscore characters on the phone (for instance, "WP Test App" is deployed under the name "WP_Test_App"). I also found this while searching for a solution of this problem:

App doesn't get updated then debugging - incrmental update not correctly working?

I played a little bit with the names of my project and solution, i.e. removed the spaces in them, and it helped to solve my puzzle.

BTW, as the author of the question under the above link states, this problem never occurred in the WP 7.1 SDK - it is specific only for the WP 8 SDK.