Working with multiple versions of Visual Studio

I'm trying to开发者_运维知识库 find a way of being able to use multiple versions of Visual Studio on the same set of projects. The majority of our team uses 2008, but I am trying out 2010. All projects are C#.

As I understand it Visual Studio 2010 insists on upgrading all projects, so it's not possible to leave all the solution/project files as 2008 versions. I really don't want to branch the entire source tree, so I'd like to find a way for multiple versions of the project files coexisting. Currently, I've duplicated all .sln and .csproj files so I have:

# 2008 versions
SolutionName.sln
ProjectA.csproj
ProjectB.csproj

# 2010 versions
SolutionName.vs2010.sln
ProjectA.vs2010.csproj
ProjectB.vs2010.csproj

The trouble is, despite the 2010 versioned files all having the same assembly names as their 2008 counterparts, Visual Studio (2010) believes the projects are all ProjectName.vs2010. Renaming the project in VS fails with a message saying a file of the same name already exists.

I don't think putting the 2010 version in a sub-folder would be a solution as it would screw up any relative paths in the files.

So:

• Is there any way to convince VS that the project name should not be suffixed with .vs2010 (i.e. not the same name as the file)? Or
• Am I approaching this the wrong way? Is there a better way of working with multiple versions of VS on the same projects?

UPDATE

My initial claim was wrong that Visual Studio was failing to find the project references because it was using the file name. The specific problem I was having was that in my build files the project references were of the form:

<ProjectReference Include="..\..\path\to\ProjectName.vs2010.csproj">
    <Project>{48354450-2462-449D-8B32-EFECA39F6CD7}</Project>
    <Name>ProjectName</Name>
</ProjectReference>

The project files that I copied apparently have a different ID (or whatever it is in the <Project> element. Simply removing the element from the build file has solved that particular issue:

<ProjectReference Include="..\..\path\to\ProjectName.vs2010.csproj">
    <Name>ProjectName</Name>
</ProjectReference>

Having said that, the whole process of duplicating the project and solution files has actually been more effort than it's worth, so I'm not recommending this approach.

Do you often modify the projects?

You could simply work with your upgraded version of the csproj and sln files. This way you would commit/check-in all changes to source code files except for the project files, which are not often modified anyway (except to add new files).

Then if you want to commit the changes in the project files, you'd work with an intermediate local VS2008 version of the file and line it up using your favorite diff/merge tools before eventually committing this VS2008 version. It would be some kind of local branch.

Unless you absolutely have to work with different versions of Visual Studio, those of the team still using 2008 could upgrade to Visual Studio 2010 Express. It's free for commercial use, and lacks only a few advanced features you might not need.

Have you tried opening the SolutionName.vs2010.sln in a simple text edior and changing the diplay name of the projects?

(form: Project("{$GUID}") = "$DISPLAYNAME", "PROJECTFILE", "{$OTHERGUID}"

Answering the second part of your question:

Why is it important to cover up that there are multiple versions of the project files? The reality is that there are two versions and you have to be careful to maintain both of them concerning the state of your project anyway (files are addded / renamed/ deleted; configuration options are changed).

Having two sets of projects and solution files will lead to differences between them which will break things.

Generally: Don't mix Visual Studio releases in the same project. Keeping the toolchain identical between developers will save you much trouble.

visual studio 2010 and 2008 project files (.csproj) are compatible side by side if you have both editors installed, meaning you can upgrade it, work on it in 2010, and have someone else work on it in 2008 without any issues. the only caveat is that you have to leave the target framework as .net 2.0 or 3.5 and that those who work in 2008 have to also have 2010 installed.

the only problem comes if they try to then open the project file in 2008 and they don't have 2010 installed (because I think 2010 adds some new build target that a standard 2008 won't know about). I didn't think this was a problem but I just ran into it this past week (on a web project), so it does exist in some form for some projects.

if you do go the rename route, the best way to go about that is to open the sln file in notepad, and rename the csproj references to the new names by hand (adding any new renamed folder paths), then renaming any folders outside visual studio, then renaming the file name in windows explorer, then rename the csproj in windows explorer, then open the solution in visual studio. your scm bindings may be hosed at that point though...