I suggest you ...

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

780 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Ed BlankenshipEd Blankenship shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    11 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • CodeWarriorCodeWarrior commented  ·   ·  Flag as inappropriate

        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 HouwingJesse Houwing commented  ·   ·  Flag as inappropriate

        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.

      • Ed BlankenshipEd Blankenship commented  ·   ·  Flag as inappropriate

        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.

      • Ed BlankenshipEd Blankenship commented  ·   ·  Flag as inappropriate

        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.

      • Ed BlankenshipEd Blankenship commented  ·   ·  Flag as inappropriate

        I love that idea too! I think there is a separate User Voice item for NuGet "repository & feed" functionality for TFS as well.

      • Xavier DecosterXavier Decoster commented  ·   ·  Flag as inappropriate

        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.

      • Ed BlankenshipEd Blankenship commented  ·   ·  Flag as inappropriate

        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!

      Feedback and Knowledge Base