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!

Microsoft caused outrage when without warning or explanation they dropped support for the Smart Device Extensions. Meaning that there is no support for both managed (Compact Framework) and unmanaged (C++) development for the Windows CE platform.

Microsoft promised support would be added by the time VS2010 was released but then back tracked, to date the official line is use VS2008. This product is nearly 4 years old, it is becoming increasingly more impractical to use VS2008 solely for the purpose of developing for the Windows CE platform. Many development teams invested heavily in the benefit of having a single UI for both embedded and desktop development, with the advent of the Compact Framework skill sets and more importantly the code base could easily be shared across platforms. This is now no longer true, as the desktop development/source control/build/test environments have moved on the embedded development environment is stuck in the past. This means duplication of code, duplication of effort and increased cost.

Anyone wanting to start developing for Windows CE has to first buy an MSDN subscription because you can no longer buy VS2008 retail.

As support for Smart Devices has been inherent in VS since VS2003 many people have been caught out when upgrading to VS2010, in many cases those who make their living in the embedded world are now stuck with no upgrade path. Microsoft has refused to comment or discuss the future of embedded development, this silence has forced many to look at alternative platforms.

One of the top voted suggestions on the Connect site was to restore Smart Device Extension support in VS2010, Microsoft has ignored this in typical fashion.

See the Connect Item: http://tinyurl.com/3ctgqda