Treat TFS as an Enterprise Symbol Server
I want my Team Foundation Server instance to be the Symbol Server for the Enterprise. Visual Studio and other debugging clients could then inherently understand when it sees a TFS URL how to locate the symbols or alternately, TFS could provide a URL that exposes symbols correctly (i.e. https://tfs.mycompany.com/tfs/DefaultCollection/Symbols). For those using the Azure-based hosted Team Foundation Service solution, it provides them a publicly-accessible (with authentication) location for Symbol Server as well.
We don't need a file share any longer if you have a TFS server! Symbols could be stored and maintained using the version control system (or some other non-versioned file system exposed & managed by TFS). Automated builds in TFS would understand where to publish the symbols as well. I would almost even say that it's turned on by default and no configuration is required to have that occur.
Visual Studio clients could also be "auto-configured" to add the TFS Server URL automatically to the Options --> Debug --> Symbols --> Symbol Server locations whenever Visual Studio connects to TFS for the first time. Developers shouldn't have to even have an understanding to make this happen and Visual Studio can really just handle this automatically in the background. (However, let the UX handle the security concerns appropriately).
I see this as being the proper foundation in place for truly innovative features in Visual Studio in the future. We have to make it easy though for all development teams to solve this right out of the box though without any thinking or additional configuration.
More details about this scenario and feature request can be found by visiting: http://bit.ly/SymbolServerTFSFeatureRequest
This would be an extension of the Symbol Server and Source Server features that were introduced in TFS 2010. It just takes it that much further! http://bit.ly/SymbolServerTFS
We have started piloting the VSTS Symbol service with internal teams at Microsoft. We are working with the Visual Studio team to enable integrated authentication from the debugger to the VSTS Symbol service. Once we have authentication working from VS, we will be able to pilot with external teams.
Any ideas on when this will be implemented?
@Josh - Hey Josh, this is a good point. As we've been thinking about it, it will work with either TFVC or Git repos that are stored in TFS & VSTS.
We use Git with VSTS and this would be very useful to have baked in to VSTS (I would argue it's a requirement), so while I'm glad it's planned, I hope this isn't implemented as TFS-only when it gets done. I just tried to set this up and the only problems I ran into (seemingly) are that (1) I couldn't specify the user or key for the share in VSTS and (2) I'm not sure about file permissions or prepping the share. We use hosted build agent currently. Personally, I don't care if the symbols are in SCM or in a share folder. I care if we can debug our VSTS apps.
I have recently (within the last year) been working on projects that are both modular (loading portions of themselves dynamically at run time) and remote (running on other systems) making the Symbol Server functionality a necessity for me when debugging.
If these symbols could be hosted in TFS and managed in the version control system (and immediately shared through common configuration in TFS with other devs) I think it would go a long way toward adoption. I, for one, did not ever consider the Symbol Server functionality until I happened onto it in the build process page of TF Build. I had seen mention of it in VS Options dialog, but figured there was a standalone server or tool of some sort that managed it.
I also agree that a TFS administered NuGet server would be of benefit. Just the ability for TFBuild to pull NuGet packages from inside the network would be a nice performance boost.
Jesse Houwing commented
Similarly I'd love for TFS to be able to act as Nuget Package server as well. Which is kind of related. Publish the outcome of one build in TFS and allow to take a dependeny on that build directly from the UI.
Definitely - Hosting it at http://www.symbolsource.org is an option for some development teams. However, there are many customers that I encounter that are not able to put their Symbol or Source Server in a publicly available location. We have a server product for Visual Studio, TFS, and the idea is to capture, store, and use symbols using TFS easily.
I agree with you about tons on the backlog for Visual Studio and TFS. That's why User Voice exists :) We can all crowdsource the stack ranking effort to help Microsoft understand what the collective community thinks is important to invest in.
Just host your own http://www.symbolsource.org/Public/Blog/View/35 - if this works for you it would be great to release this request since there are many things in Visual Studio land that need to be worked on.
Thanks a ton Michael! Feel free to shift your votes for something else over here to this one! Even if it's just one vote.
I ended up having to do that to create this particular User Voice item.
Michael Paterson commented
Great idea. No votes left :(
FYI - I have gone ahead and added my additional details for this feature request on my blog site if anyone is curious about the feature: http://bit.ly/SymbolServerTFSFeatureRequest
Xavier Decoster commented
yep, remember me posting the original idea here (http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2037617-built-in-support-for-nuget-packages) before the uservoice for tfs got moved to the current location by the VS ALM Team :)
However, I don't have any votes left and can't post any new ideas...
I love that idea too! I think there is a separate User Voice item for NuGet "repository & feed" functionality for TFS as well.
Xavier Decoster commented
Like the idea!
While talking about symbol storage: why not extend this even further and support NuGet symbols packages as well? This would enable us combining an enterprise NuGet server with an enterprise Symbol Server inheriting source control security.
Oh - if the symbols were stored in the Version Control repository, you could potentially benefit from the TFS Proxy Server in geographically separated locations as well!