Rob's Blog

Much has been written on the fact that Visual Studio 2008 can build .net 2.0 applications, and that they can be installed side-by-side on the same machine.  This is phenomenal as it allows organizations to upgrade developer tools without forcing clients to also upgrade .net framework versions.  Very nice.

However, what isn't as fully documented is using Visual Studio 2008 and Visual Studio 2005 together on a development team.  For example, Sally Slickster is an early adopter, downloaded the VS 2008 iso from MSDN 8 minutes after Scott Guthrie posted the RTM news.  She'd like to use it for all development work from now on.  Harry Hard-head, on the other hand, just figured out where all the settings are in VS 2005, and installed VS 2005 SP 1 under great duress.  No way will he use VS 2008 until at least SP 1.  They're both working on the same .net 2.0 project.

When converting a VS 2005 project to VS 2008, and leaving it to target .net 2.0, it only changes 2 sets of files: the solution file (*.sln) and the project file(s) (*.csproj).  Ok, technically, as VS 2008 developers do things, it'll replace some comments with new version information.  The header at the top of .designer.cs files now reads version 2.0.50727.1433 for example.  Since these files are rebuilt any time the designer sneezes, I'll ignore them.

The .sln files used by VS 2008 and VS 2005 are similar, but not compatible.  (So says my very un-scientific testing.)  Yes, get annoyed, get indignant, run the VS 2008 conversion wizard, leave the projects in .net 2.0 mode, then check in the second .sln file in source control.  I hate it too, but it could be worse.

The .csproj files are a different story.  During the VS 2008 conversion wizard, many new nodes and attributes are added to each project.  I didn't find anything removed, just new stuff added.  With these in place, VS 2005 pulls up a "This project has been modified outside the designer" security warning box the first time the project is re-opened.  UAC has trained me to ignore these dialogs and just push OK.  Closing and reopening VS 2005 seems to not bring up the security dialog a second time.

The major headache with the .csproj files is with Web Application Projects.  This line is changed:

/>

it becomes:

/>

Note the 'v8.0' becomes a 'v9.0'.

Well, now VS 2008 is happy, but VS 2005 users can't build because C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0 doesn't exist on their machines.

Adam Salvo suggests just copying this directory from a machine with VS 2008 on it to all the machines without it.  It's a whopping 900k, so who cares.  Perhaps a carefully named shortcut could do the job as well.

Steven Harman suggests replacing the offending line in the .csproj file with these lines:


Basically, tell it to use what ever works best.  Very nice.  Very clean.  Very self-contained.  Yes.

Perhaps in time, everyone will move to VS 2008 and this problem will just disappear.  In the mean time, now Sally and Harry are happy, and you know what happens when Harry met Sally...

Rob

A very specific rule for using source control is to avoid putting temporary files, user files, or compiled content into the repository.  These files change far too frequently and offer little value to the versioning and historical process.  More than anything, they'll just make the repository excessively large and make everyone update their checked out copies more.  However, keeping temporary files out of SVN using TortoiseSVN isn't a perfect science.

TortoiseSVN will suck in everything in the folder, including hidden files and folders.  Windows hides the Thumbs.db file -- a cache of image thumbnails in the folder.  To see this file, open the folder in Windows Explorer, choose Tools menu -> Folder Options -> View tab -> Show hidden files and folders.  Now that you can see it in Windows Explorer, you can delete it from SVN in the standard way.  Standard caveat though: it deletes it from now on in the checked out trunk, it doesn't delete the history of the file being there, and by deleting it, you won't make the repository smaller.

A more industrial-strength way to avoid files like this from entering the repository is to adjust TortoiseSVN's settings.  From Windows Explorer, right-click, choose TortoiseSVN -> Settings.  In the General section, there's a "Global ignore pattern".  Mine currently looks like this:

bin obj CVS .cvsignore *.user *.suo Debug Release *.pdb test.*

This is just a space-delimited list of file patterns to ignore.  You can add Thumbs.db here or any other file mask that you'd like Tortoise to ignore when checking in files.  (Since I disabled creation of Thumbs.db on my system, I don't yet have it in the list.  You also may not need the CVS patterns if you have no legacy CVS content hanging around.) The lynch pin here though is this is a per-svn-client setting, not per-project or per-folder.  If someone else in the team checks out the source, builds it, and checks it in, if they weren't paying attention, they'll likely push these unwanted files into the repository.  (My solution to that is to hand the global ignore pattern list to everyone in the team.)

If you'd like a server-side solution, with the files not checked in (or previously removed, committed, and rebuilt), you can right-click on them in Windows Explorer, choose TortoiseSVN, and Ignore.  You can also do this by right-clicking on them in the Tortoise's commit screen.  The up-side is this is server-side, so it applies to all users of this file or folder.  The down-side is this is per-file.  So, each new project, new solution, or new directory added to the repository needs some TLC right out of the gate to insure it doesn't commit these files into the repository.

Which of these two is the best strategy for ignoring these files and folders?  The first is great for many folders and few people or people that don't change much.  The latter is good for many people and few folders or for teams that have high turnover.  But as always, your mileage may vary, and your comfort with each paradigm may temper your success.

Rob