jesfer

Lately I've had a few TFS users complain to me that the TFS client (aka Team Explorer+Visual Studio) lacks the explorer integration you get with TortoiseSVN. Now, I've never felt the need for this feature but decided to do some research. And guess what? You CAN get explorer integration with TFS! In several different ways!

• Visual Studio Team System 2008 Team Foundation Server Power Tools
• Dubbelbock TFS
• SvnBridge
• LizardTF

I have not tried any of them (yet) but I'd recommend the power tools... mainly because it is Microsoft and they'll eventually steamroll the competition (except maybe SvnBridge). Just pay attention to this small but important part of the "instructions" on the download page:

"Please note that the TFS Windows Shell Extensions are not installed by default. Choose Custom when prompted at installation to add the tool to the installed components."

If I'm not too busy I'll write up a short review of the TFS Windows Shell Extension in Visual Studio Team System 2008 Team Foundation Server Power Tools. Jeez... Microsoft, you relly need a shorter name for these tools!

This is actually really easy as long as every developer on your project makes the move simultaneously. If not, well, there are a couple of things to keep in mind.

• VS2008 will convert your solution and project files even when you stay in .Net 2.0. Converted solution files can not be opened by VS2005. Project files can still be opened (you'll get a warning but that is all). This means you'll have to work with two versions of your .sln files, one for VS2008 and one for VS2005.
• If you've used Microsoft's Test Project template for writing unit test etc, the reference to ”Microsoft.VisualStudio.QualityTools.UnitTestFramework” will have changed in the conversion, breaking the project for VS2005. This reference will have to be manually changed back and forth depending on what VS version developers use.

That's it so far, but I'm sure there are some other pitfalls out there waiting for me :P

Found a very good quote at Worse Than Failure today...

"Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill."
Michael A Jackson - Principles of Program Design, 1975

Must have been what happened when the program I'm currently maintaining was originally designed... not that I would ever do something like that... promise...

I was recently asked to bugfix an application. The bug was eaasy enough to fix, just add two lines of code, no big deal. In order to build the application I had to install Enterprise Library 3.1 and re-reference a few .dll files in it. Also no big deal, done it before with previous versions of Enterprise Library... but it turns out i stumbled right into a configuration pitfall!

Short version for those who dont want to read Tom Hollander's blog about Avoiding configuration pitfalls with incompatible copies of Enterprise Library:
If you install Enterprise Library 3.x a go with all default options/choices, you end up with two sets of .dll files. If you have to re-reference these files in a project and use the wrong .dll your code will compile but throws an exception in runtime... referencing the other set of dll files will solve the problem (but might cause new problems as well).

Objective:
Get a VS2003 ASP.NET web application project from SourceSafe, migrate to VS2005 and add to TFS source control. All done on a PC running Windows Vista. As VS2003 will not run on Vista opening the solution in VS2003 and disconnect it from source control is not possible... might be possible to do from SourceSafe, but I decided to give it a go and just open it in VS2005 straight away.

Problem:
VS2005 conversion wizard fails to convert the web application. Depending on if I let the .sln file point to localhost or changed the projekt path to "C:\myAppPath\myWeb.vbproj" I get two different errors:

Error 1 (keeping localhost/myWeb/myWeb.vbproj as project path):
Conversion Issues - myWeb.vbproj
Thats it... No clue as to what is wrong.

Error 2 (changing to C:\myPath\myWeb.vbproj as project path):
Conversion Issues - myWeb.vbproj:
Unable to open the Web 'C:\myPath\myWeb.vbproj'. The Web 'C:\myPath\myWeb.vbproj' does not exist.
Looks a bit more helpful, but since the file DOES exist... No, no more helpful than what I got in Error 1.

Solution:
As it turned out there wasn't really anything wrong with the myWeb.vbproj file. Except that it was write protected... Checking the "make writable" checkbox when getting the code from SourceSafe (or just removing the write protection from the file) made all the difference. VS2005 disconnects the code from SourceSafe source control and converts everything 

Now I just need to solve all the compilation errors and the code will be ready to check into our TFS... Looking back, I might have been able to avoid the entire problem by following Microsoft's instructions for migration. But why learn to swim when it is soooo simple to just jump into the deep end of the pool? Anyway, hope this is helpful to someone else...