How do I make Visual Studio 2010 RC solution files compatible with previous versions?

Question

I'm trying to use visual studio 2010. But it seems that the .sln file that is created through it isn't supported by previous versions. Is it possible to save the projects in a way that it could be readable by previous versions of visual studio (2008).

Answer 1

The accepted answer is incorrect when it comes to projects. It's correct for solution files, but they're not actually as important as the project files (as they don't change as often, in my experience, and there are fewer of them).

For example, you might want to look at Noda Time. We have two solution files (NodaTime VS2008.sln and NodaTime VS2010.sln) which load the same project files. This provides a pretty practical solution to having developers working with different versions of Visual Studio.

Manually change the first part of the project file to look like this:

<Project ToolsVersion="4.0" DefaultTargets="Build" 
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

(Basically just change ToolsVersion to 4.0.)

You can also just let VS2010 convert the projects automatically and compare them afterwards if you want - see whether it's done anything else that you don't want.

At that point, when you build in VS2008 you'll get output such as this:

Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".

... but it will still work, in my experience. There may be some oddities if you use a lot of designers etc, but generally it seems to work pretty well.

Answer 2

A late answer, but for others in this boat, here's an option if you don't mind conquering a learning curve. Download a copy of TortoiseHg and install it. This is a version control system. (There are other version control systems such as git which can also do this, but they must support patch queues, and TeamViewer does not; however, this isolated usage does not conflict with TeamViewer for source management). Mercurial includes an extension called MQ, and you should enable it. Modify the setup to make Patch Queue Patches secret. ([mq]secret=true, or under settings, Commit, set Secret MQ Patches to True. If you start using Mercurial for change management and do not make patches secret you will suffer great pain as unavoidable accidents occur as the patches are committed to the repository and must be painfully, manually removed from each users copy, only to creep back in via the one user that was on vacation that day.)

Next, create a repository in the solution folder. Look online for an .hgignore file so you don't grab a bunch of crap, but if this is your only goal, you can ignore everything but the *.sln and *.*proj files. Place all of the files in there under the oldest version of Visual Studio you use. Next, open the solution file and allow Visual Studio to perform an automatic upgrade. Then open the TortoisHg workbench and create a new patch that contains all of these changes.

From here on out, you can make whatever changes you like to the source, and place them in another patch. When you're ready to share, open up the workbench, pop off all of the patches, and drag the upgrade patch to the top, and pop all the patches back on except for the upgrade patch. Finish (Repository->change history->finish patch) all of the patches (except for the upgrade patch). Your changes are now incorporated into a version of the solution that is based on the oldest version of visual studio that you have in use.

When you obtain updates from other users, pop your upgrade patch off, apply the changes via a changeset or shared patch, then pop your upgrade patch back on last. Repeat as necessary.

This does not capture modifications to the projects or solution file, since you will pop those back off when you remove the upgrade patch, but 99.9% of all source code is completely backwards compatible. So other than adding new/existing items to a project or adding new projects to a solution, this should cover the majority of your work. For changes to projects, perform those on the oldest supported version of visual studio, delete your upgrade patches, and recreate a new upgrade patch.