Question

I have built a class library that I've initially written in Visual Studio 2010 using .NET 4.0 features, including the new TPL classes.

However, I would also like to publish a Visual Studio 2008 compatible version of the class library, built for .NET 3.5 (2.0), without the specific features related to .NET 4.0.

My question is this: How would I best set up this so that I can easily fix bugs and get bugfixes in both versions, as long as it is in common code?

Here's the various ways I've discovered:

1. Create a whole 'nother repository for the .NET 3.5 version, manually merge bugfixes over (ie. they're not really related through Kiln, just me manually copying changes over using Beyond Compare or a similar tool)
2. Creating a branch, and keeping two branches open
3. Named branch (what's the difference between a named branch and an unnamed one?)
4. Creating a sub-repository (what is this?)

As you can see, I have plenty of questions, any guidance you can give me at all would be most welcome, but most of all, if anyone has already done what I'm trying to do, any specific pointers as to what worked best would be most welcome.

Things that I need to handle:

1. Project files and Solution file has different format, so either I:
   • Create unique names for those, and just keep everything together
   • or, branch/split (see questions above)
2. Some changes internally in the files, mainly to remove support for TPL-classes (.NET 4.0) in the Visual Studio 2008 (.NET 3.5) version, I can do this using #if DOTNET40 type of defines easily, but if it's better to branch and make the changes, then I'd like to know that (I assume not.)

Answer 1

Are you planning on doing future development on the 3.5 version as well or just bugfixes?

If you want to develop both, my suggestion would be to hand edit the csproj file for the solution. If you look under the first PropertyGroup you see the TargetFrameworkVersion element. You can safely move this down and put it in the subsequent PropertyGroup elements (the ones with Conditions) and then set specific values for different build configurations. VS doesn't allow you to do this from the UI but it does support it at build time.

This means you can switch from the 3.5 build to the 4.0 build just by changing build configuration. You can then control TPL and other .net 4 use with a conditional compilation symbol.

Visual Studio 2008 can open 2010 csproj files as well so if you want to continue using your old tools for the 3.5 configurations you can.

If you don't really plan to develop the 3.5 version, but just do bugfixes, then you should consider branching the 3.5 version as a branch repo, and then any shared bugfixes get made on the branch and pushed across to the main 4.0 product. Very much like the stable/devel structure suggested elsewhere on this site.

Hope this helps.