CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeffrey Palermo [MVP]

Software management consultant and CTO, Headspring Systems

Enabling team development with VS2008/2005 mix

Ok.  Now we have a problem.  Some folks want to use VS 2008 RTM while continuing to target an existing .Net 2.0 solution.  The project files don't give us a problem, but the solution file does.  Here is the first line in a VS 2005 solution file:

Microsoft Visual Studio Solution File, Format Version 9.00

When this file is opened in VS 2008, the nice upgrade wizard comes up.  This wizard will do crazy things to our solution file, like changing the first line to:

Microsoft Visual Studio Solution File, Format Version 10.00

Joking aside, this is the ONLY difference in running a .Net 2.0 solution in VS 2008.  There is absolutely no change to the project files necessary.

Given that, it ought to be possible to have some members of the team using VS 2005 and some using VS 2008.  Why not?  One way to accomplish this is to have two solution files in the source code trunk.  The files will be identical except the version number.

Below, I've provided two solution files for my NHibernate demo trunk.  You can use TortoiseSVN to checkout this trunk to try it out if you wish.

Note that you will have to pick one of these solution files for your automated build.  I'd recommend typing your automated Nant build to the VS 2005 solution and keeping that as the gold standard because, after all, your continuous integration server should only have .Net 2.0 installed if that's what you are targeting.  The members of the team using VS 2008 will have to ensure the VS 2005 solution gets any solution modifications that are necessary.  Both the local and CI build should use the VS 2005 solution file.  With that policy, team synchronization won't suffer.



Comments

cmyers said:

My experience:  It will 'upgrade' your CSPROJ files, but not in an incompatible way. 2005 can still load them.

EXCEPT for the Web Application projects. It *WILL* make a breaking change to those. Steve Harman has a workaround: http://tinyurl.com/3atdxe

# November 21, 2007 4:01 PM

stevienova.com » Blog Archive » links for 2007-11-22 said:

Pingback from  stevienova.com  » Blog Archive   » links for 2007-11-22

# November 22, 2007 1:25 AM

Mike Chaliy's Blog said:

Мабуть вже всі знають що в VS2008 тепер новий повністю новий формат файлу рішення (solution). Формати

# November 22, 2007 6:10 AM

Daniel Moth said:

Note that your VS2008 users will still have to be careful not to use C#3.0/VB9 features (which are of course usable against v2.0 of NetFx, but not understood by VS2005).

# November 24, 2007 6:30 AM

Jeffrey Palermo said:

@Daniel,

You are absolutely correct, but that is why it is important to keep the local developer build and the CI build tied to the .Net 2.0 msbuild.exe so that if someone accidentally uses a non-supported syntax, the continuous build will catch it right away even before the developer has a change to commit the change to subversion.

# November 24, 2007 4:09 PM

Carel Lotz said:

A concern I have is that VS 2008 installs SP1 for .NET Framework 2.0.  You therefore may run into scenarios where things work in your local VS2008 developer sandbox but not on the build server.  Highly unlikely I agree, but still something to consider.  Do you therefore install .NET Framework 3.5 also on the server to get SP1 for .NET 2.0?  I haven't checked, but is .NET 2.0 SP1 available as a separate download?  I don't want to make .NET 3.5 a pre-requisite just to get SP1 for .NET 2.0 installed.  

# November 26, 2007 3:46 AM

From the software development trenches said:

In my current role as .NET technology consultant I am trying to do all the pre-work required to get the

# November 27, 2007 11:07 AM

Jeffrey Palermo [MVP] said:

Previously, I posted how to support developers running Visual Studio 2008 and Visual Studio 2005 on the

# November 28, 2007 1:22 AM

Petar Repac said:

@ Carel Lotz

> I haven't checked, but is .NET 2.0 SP1 available as a separate download?

It is. Look at:

www.microsoft.com/.../details.aspx

# November 28, 2007 8:22 AM

jankyBlog said:

La Solution in VS2005 e in VS2008

# November 28, 2007 9:31 AM

Carel Lotz said:

> after all, your continuous integration server should only have .Net 2.0 installed if that's what you are targeting.

MSBuild allows you to specify a TargetFrameworkVersion property by which you can force compiler errors to be generated for code that are using features not supported by the specific version of the .NET Framework, i.e. if you create an application with some LINQ queries, the following creates compile errors:

msbuild ConsoleApplication1.csproj /ToolsVersion:3.5 /p:TargetFrameworkVersion=v2.0 OR

msbuild ConsoleApplication1.csproj /ToolsVersion:3.5 /p:TargetFrameworkVersion=v3.0

However, the following compiles successfully.

msbuild ConsoleApplication1.csproj /ToolsVersion:3.5 /p:TargetFrameworkVersion=v3.5

This allows me to still take advantage of the new improved build features like parallel builds in MSBuild 3.5.

# December 6, 2007 4:37 AM

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Check out Devlicio.us!

This Blog

Syndication