February 15, 2012 7:56 PM
by Ed Blankenship
If you haven’t talked to me before, I am a serious fan of the Symbol Server and Source Integration in Team Foundation Server. Recently, I thought about reducing the complexity of the entire story especially for those using Team Foundation Server. You still have to have a file share available for symbols which is just something else to have to request, manage, deal with for disaster recovery, and is particularly problematic when users are in geographically remote offices. Individual developers also have to manually register the symbol server in the Visual Studio options for each of the development machines they ever use. Why though? It shouldn’t be this difficult especially when you have already adopted TFS.
I submitted a new feature request on the Visual Studio Team Foundation Server product team’s User Voice site specifically for assisting with this complexity. I would like TFS just to be treated like an enterprise symbol server and Visual Studio can just take advantage. My good friend and colleague, Adam Cogan, encouraged me to share with my blog readers more details about this feature request.
I would also like to ask for your help with voting on the feature request if you like the idea and would be important for your team & organization.
The main part of this would be something like a version control folder to hold the symbol server files such as $/Symbols. This would be a special folder that would only be used for Symbols. You would then be able to have a URL endpoint that TFS recognizes and handles appropriately (i.e. https://tfs.myserver.com/tfs/DefaultCollection/Symbols).
With this type of feature in TFS you can take advantage of many side benefits including:
· No file share to worry about getting provisioned by IT or backed up
· Takes advantage of TFS Proxy caching for geographically distributed locations
· This could be a special version control folder type where it doesn’t have to keep history – only the latest version (T)
· Would work out really well for those using TFS on Azure (especially with on-premises build servers)
· Potentially Symbol Server for CodePlex projects!
· IntelliTrace & the VS Profiler benefits greatly from this as well!
If this feature is setup & configured, then why not just go ahead and auto-configure new TFS build definitions as well? Pop it right in there…
If I connect to a Team Project Collection, I want my Visual Studio (and other clients that use symbol server) to be auto-configured for the symbol server to be used. It should just be automatic! This would be very similar to how the client auto-configuration for TFS Proxy just works for anyone doing a version control get.
If you have symbols turned on for TFS builds to handle when retention policies are run, you could configure it to either destroy or delete the symbols from the special version control folder. As an administrator, I may want to actually destroy the symbols with retention policies for some of my build definitions just to save on space.
Help me everyone out with your votes!
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u
Hi! I am Ed Blankenship and a Product Manager at Microsoft for Visual Studio Online, Team Foundation Server, and the Application Lifecycle Management family of tools. I am an author of a few books, former Microsoft MVP of the Year, and a former ALM consultant.
Powered by Azure Websites
Site design by Jeremy Kratz