handling version of VS for dev machine

the scenario is this: there are 9 developers; all of them maintain vs 2003 and 2008 projects.(visual basic).. only 2 program on vs 2010 and maintain an app.

we are creating an image that will go to all the developers.
14 apps are on vs 2003 code; 9 apps on vs 2008 and 1 on vs 2010.

what vs versions would you recommend on the image?should it have all 3? really can't swing it just with 2003 and 2010, can we?

good point on licenses; we have it covered.. if that is what we need, we will go with it.

*If we don't want to upgrade, then the only option is to have 27 licenses, right? (will need all 3 versions)

but if we upgrade all projects to 2010 (just open them and save them, which will upgrade/convert them), will there be any errors or testing  needed.. (why i ask is i know that access 2010 when it converts older projects is not seamless.. still code updates are needed to avoid errors.. how is it with .NET?)

*If we don't want to upgrade, then the only option is to have 27 licenses, right?
That is correct.

.NET logs all potential errors and warnings when it upgrades projects. I've never had issues with upgrading them. I get a warning a lot that I'm targeting an older version of the .NET runtimes than the current one but that's not really a problem. Since all the libraries are still targeting the same version of .NET, the only things that upgrade are the .sln and .project types of files. All your code files remain unchanged. The reason Access causes problems is because upgrading forces you to use the new version of the code as well.

Tommy,

am i understanding correctly from you that VS 2010 can convert both VS 2005 and also VS 2008 into Vs 2010 solutions without any issues?

can you explain the above in the context of "all the libraries are still targeting the same version of .NET"- Do you mean there may be three VS 2010 solutions - one pointing to 2005 .NET , one points to 2008 .NET and one points to 2010 .NET?

Yes. Every project I have tried to convert has converted fine.

When you create a .NET project, it targets a specific .NET runtime/version with all the applicable code. By default it will target the latest version. The versions are not 2003, 2005, 2010, they are more like 2.1, 1.3, etc. But yes, the 2010 solutions can point at any version of .NET. It will keep pointing at whatever version the old project pointed at. So you shouldn't need to update any of the code.

OK- thanks Tommy; can you please provide a msdn link for the below 2, if possible, so it will put the team at ease as are at crossroads now, if we should upgrade or not:
*The reason Access causes problems is because upgrading forces you to use the new version of the code as well.
*The reason .NET won't cause problems is because upgrading does not force to use the new version of the code.

I can't find any articles specifically from MS that say those things, but when you upgrade a solution, look at the report or even the timestamps on the files and you'll see that only a few files get changed.

Why don't you just copy your solution folders and test to see if the upgrades work? If they don't work because of some funny references or something, it will tell you.

OK, Tommy. so, what I am understanding is if i upgrade a VS 2005 or VS 2008 project to VS 2010, you would expect it to work without any issues?

what about vs 2003- can you do the same?

I would expect so. You can always make a copy of the project and test. If it's not going to work, you'll know right away. It's not going to create subtle errors. It will either work perfectly or fail miserably since you are just updating the project files not the actual code.

good explanation.. thanks and that link seems to be right on..


you had said "I can't find any articles specifically from MS that say those things" did you see any links from experts blogs or MVPs.. if not, that is fine, too..

appreciate your help.

I sure didn't. Although I did see a lot more posts griping about Access and Excel database and spreadsheet version change errors than VS upgrade errors.

thanks again.