Geeks With Blogs

News Hi, my name is Vincent Grondin and I'm a senior consultant at Fujitsu, a consulting firm in Montreal, Québec. I'm starting that blog to share some of my thoughts and knowledge on .NET architectures and code. Being a consultant in the .NET world I come across many different things. Some good, some bad and others that are worth a blog post here whether they be good, or hmmm... shall I say, less good :) I hope you enjoy yourself while learning new stuff. Feel free to leave a comment or contact me anytime.
Vincent Grondin
typical project teams have a build environment to streamline the production and release of the various versions of their application or product. In many project, there is more than just the needed application that gets built in this environment. One very common thing that those environments often build is a toolbox or other kind of shared libraries. This article will hopefully help you setup an even better environment than the one you actually have or shall I say a more complete one… This post is intended for teams that have TFS and Team Build as part of their build environment. First off, I’m not the “creator” of this technique on how to enable the Source Server for TFS 2008. The current post is based on a blog entry I’ve read not so long ago and which can be found here:
I figure the more people talk about this technique and explain their solutions for this problem I’m about to introduce, the better for the community…
The problem with a build environment for building shared libraries evolves around PDB files and the fact that these files are hard to distribute to your developers because they contain hard coded paths. One such path is used by the debugger to find the source code file associated with the code you are currently tracing while debugging applications. If I build my toolbox on my build environment and try to distribute the assembly and pdb of my toolbox to other developers on my team, they will most likely be unable to trace within that assembly even tho they have the PDB…. Why is that so? Because the path written inside the PDB (something like C:\Builds\Toolbox\Source\Namespace\Class.cs…) matches the build environment and not the developer’s environment! Therefore, when the developer references this assembly and tries to trace within the assembly, he will get a message saying that the source files were not found (because the path points to the build environment) and that tracing cannot continue even if the PDB is present and accessible. What good is a custom built toolbox if your own people cannot trace or step into it when debugging your own stuff? No good at all actually.
This is where the source server comes in handy. Following the steps described in the link above (and the pdf document it contains) solves these problems for us. Here’s what will happen when you re-run your test and start tracing your code once the source server is enabled. When you trace over a line of code that resides into a referenced assembly that isn’t part of your solution, the debugger will see that the PDB file is there and available. It will open it and read all the information it needs to download the right version of the source file from your TFS and open it to you for tracing in your Visual Studio. At this point you shouldn’t even realize what just happen under the hood and think the function you’ve stepped into is part of the same assembly you were just in the line before... You can now pick up your jaw from the floor, read the last few lines again and do like I did when I read it the first time: fire up your VS 2008 and try this into your lab :)
Happy TFS-ing all !
Posted on Saturday, June 27, 2009 3:33 PM | Back to top

Comments on this post: Enabling TFS 2008 Source Server Functionalities

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Vincent Grondin | Powered by: