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

In 2012, all the Team Explorer interfaces have been combined into a single window. This has drastically reduced the efficiency with which we can do day to day operations. For example, to merge, I have to go to the Source Control explorer (Click Team Explorer tab. Click Home. Click Source Control Explorer). Then I apply my merge. Then I have to check in (Click Team Explorer. Click Home. Click Pending Changes. W.A.I.T. Check in the files). Then the next thing needed is always to do a build. (Click Team Explorer. Click Home. Click Builds. Start the build). As you can see, every action I do takes the Team Explorer to another page, losing my previous page, so I now waste a lot of time re-opening pages I was in a few minutes earlier. In 2010 these UI pages were independent so the workflow was fast.

One solution would be to allow multiple instances of the Team Explorer, just as is possible in Solution Explorer.

When merging changesets, I have to pick the target branch every time. Could it please just remember the last target branch? And ideally also grey out branches that are not mapped into my workspace.

Team explorer pages don't remember their settings. Pending Changes and Work Items open with all their sub-trees expanded. If I close ones I don't want to look at, more often than not when I return to the page (2 minutes later) they come back fully expanded.

There is no way to quickly see the status of All Builds any more. I have to open one of my specific builds, then change the filter settings to show all the builds. I need to check the status of our builds many times a day so this is very frustrating.

Pending changes: There is no differentiation between the different sections in this window, so it is **extremely** difficult to find things in it. To check in I have to enter a check in comment at the top, then scroll to the bottom to enter notes, then scroll back to the top to find the check in button - could notes and comments be put together at the top please? In general, this window gets very long and has to be scrolled, so it is terribly hard to find anything. In particular, the Included and Excluded file lists look identical. When you have scrolled down into a long list of files there is no way to tell if you are looking at included or excluded items. A subtle background colour difference (e.g. pastel green and pastel red - or green and red tint to the monochrome icons) would make a massive difference here because I would be easily able to distinguish the sections and tell whether I am looking at included or excluded files. I don't care how awful this window *looks* - what is important is that it enables efficient and easy workflows. Currently it is all about trying to "look metro" with no consideration to usability. In UI design terms it is simply unusable - I actually leave 2012 and run 2010 to go and deal with source control tasks because waiting 20 seconds to boot up 2010 is much faster than achieving the work in 2012. I thought I would get used to the UI but familiarity with it has not made it any easier to use - after several months use in Beta/RC/RTM versions I still find myself "lost" in the Pending changes window. This is probably because I often have pending changes with lists of more than 2 or 3 files (typically 5-30 files, and periodically hundreds or thousands of files)

Pending Changes: There is no way to see a flat list of files. I have 300 projects and a refactoring can mean I change 80 files each of which is in a different folder. The hierarchical list is 3 times as long, and there is no way to see a simple alphabetical list of leafnames to find files. The clunky filtering options are no substitute for simply listing the files easily. 2010 had options to swithc between a flat list or a treeview as appropriate.

Pending Changes: It initially seems useful that checkins occur in the background. However, this means that you move away from the pending changes window to do other work, and do not get any notification when a checkin has failed for any reason. If a checkin is not successful, it needs to show a dialog to tell the user that they need to fix it.

Pending Changes is SLOW. In 2010, whenever you opened the PC window, it instantly showed you the information you needed. Now, every time it opens it re-loads all its data from the server and there is a 6-second delay before it shows the info. Flying in the face of 2012's claims of making the UI 'less distracting', while Pending Chaages is working, it draws a pair of massive animated flashing blue bars across the side of my screen, which is *intensely* distracting and very annoying to have constantly going on in my peripheral vision.

Home: I don't understand why I would need a "New Query" link on the home page. We created the 20 queries useful to our organisation 5 years ago and have not since needed a new one. Do users really create such a profusion of queries every day that they need a link to do this on the primary user interface page? To me it's just a distracting item that I can accidentally click.

The use of hot-links in the web sense (of taking you to a new page) and as "buttons" that apply an action is very confusing. If it is a button that will fold out or hide some additional UI (like "Override warnings" and its corresponding "Cancel") then it should look like a button or a fold-out-this-section glyph. The cancel buttons in particular are really hard to spot so it's a difficult UI to get to grips with.

So, to summarise: Team Explorer and Pending Changes both suffer from cramming too much functionality into a single window. In both cases, becing able to split sub-sections of these UI pages out into separate windows so that I can focus only on and quickly access the information I need. In particular, it must be remembered that Source Control is not something programmers use occasionally, it is a core workflow that is used frequently every day. Shaving a few seconds off this workflow has a huge impact on the usability of the IDE for everyday programming tasks.

I appreciate you've all worked very hard to bring us this new UI, but it's much ****** to use and slower than 2010. Even after many weeks of use I have not "got used to it" - normally I can take on board a UI change in less than a week and then feel comfortable with it, but this metrofication has made it simply awful and too time consuming to use as a serious programming tool - too much "form over function". Until these issues are resolved, I will have to use 2010 to apply my source control, work item and build actions - it's actually faster to boot up a new copy of 2010 from my SSD than it is to switch to the 2012 pending changes window!