Maintaining a Project with Two Windows Phone Versions

I am currently reading the Mango (Windows Phone OS 7.1) version of my Phoney Tools project. But I have a particular problem: I need to maintain both a 7.0 and a 7.1 version of the project builds. You might have the same issue with your own project so I thought it’d be a good way to show off some special features that Visual Studio has to help you solve these sorts of situations. Essentially my goal was to maintain one set of code but build both sets from the same source.

First off, I took my original project and created two solution folders and created the 7.1 projects as shown here:

image

To build the 7.1 versions, I linked the source code between the projects.  If you haven’t done this before, this means that the 7.1 projects would use the same physical file as the 7.0 versions but be built against the Windows Phone OS 7.1 project settings. To created a linked file, when you add an existing file, you have to pick “Add as Link” in the Existing File dialog:

Add as Link

Using the small dropdown on the “Add” button, you can add the files to your project as a link to the original file. You can see these links in the Solution Explorer so you know which files are linked:

image

You can see the icon shows a small overlay of an arrow to indicate the linked files. This way I can have a single set of code that can build both versions.  Key here is that the underlying references and project types all point at the two versions of the phone libraries. But what about code differences? That’s where project defines come in. In my 7.1 project settings dialog under the build tab, I added a new define called “MANGO”:

Visual Studio Project Settings

With this new project define (again, only in the 7.1 projects), I can edit the code where necessary using this define:

#if MANGO
  [Obsolete("Class is no longer required in Windows Phone 7.1.")]
#endif
  public class GameTimer
  {
    ...

With these two tricks, I now have both 7.0 and 7.1 building in the same solution. I hope this helps you trying to do the same thing!

 

Comments

Gravatar

morten Tuesday, August 23, 2011

Its easier to just make a copy of thecsproj file (put it in the same folder) add it to the solution and change the build target. That way it keeps it simpler to set up, maintain and and compare the project files down the line. You can still create solution folders to organize the project files in.
Lastly I've seen the compiler sometimes have problems with linked files.

Gravatar

Jake Ginnivan Tuesday, August 23, 2011

Nice post, you inspired me to talk about how I have done it, just for a different approach. I have a single project, and have modified the .csproj file so I can switch targets based on the current build configuration. Then I use a build.cmd to build both artifacts, then package them in the new NuGet packages.

http://jake.ginnivan.net/multitargeted-windows-phone-project

Gravatar

Robert MacLean Tuesday, August 23, 2011

Why not use branching in your source control? Seems exactly what that is for!

Gravatar

Atley Tuesday, August 23, 2011

Very cool article! Thanks for the info.

Gravatar

Shawn Wildermuth Tuesday, August 23, 2011

morten:

I've had more trouble with double .csproj's than linked files, but if it works, great.

Gravatar

Shawn Wildermuth Tuesday, August 23, 2011

Jake,

The problem with a single csproj file is that I will be adding new files to the 7.1 version that don't exist in the 7.0 version so i'd have to #IF MANGO #ENDIF whole files which I don't like.

Gravatar

Shawn Wildermuth Tuesday, August 23, 2011

Robert,

I only use branching if I am going to do changes that will be merged together at some point. These are two distinct versions that will be maintained with some code sharing (not all).

Gravatar

Valeriu Caraulean Tuesday, August 23, 2011

Have you looked at Project Linker tool?
This one - http://msdn.microsoft.com/en-us/library/ff921108(PandP.20).aspx

It "links" two projects together and all file additions/deletions/renames are reflected in second project automatically.

In your case you have to manage this manually, haven't you?

Gravatar

Shawn Wildermuth Tuesday, August 23, 2011

Valeriu,

Yes, but I prefer to do it manually as the versions are not sharing *all* files.

Gravatar

Peter Kuhn (@Mister_Goodcat) Wednesday, August 24, 2011

I use the exact same approach.
One pitfall I came across is that "Add as link" does not work for the tile icons/images of an app project - you'll receive generic deployment errors that leave you clueless (something like "Parameter incorrect"). The only solution I found was to create a real copy for those files.


Leave a Comment

*
*
*