Ranting and raving about anything I feel like complaining about.

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 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 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 Why not use branching in your source control? Seems exactly what that is for!
Gravatar Very cool article! Thanks for the info.
Gravatar morten:

I've had more trouble with double .csproj's than linked files, but if it works, great.
Gravatar 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 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 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 Valeriu,

Yes, but I prefer to do it manually as the versions are not sharing *all* files.
Gravatar 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.

Add a Comment

*
*
*