The current philosophy seems to be that only active team members can participate in code reviews which are always made for one check-in. Here are a few suggestions on how to make it more usable.
1) Make it web-based so one doesn't need Visual Studio (and sources for entire solution). This way one could easily ask for consultancy from a remote expert
2) Make it possible to create review request afterwards and possibly spanning multiple check-ins. The current practise suggests people to do huge check-ins which is not a best practise.
3) Have the comments to make a discussion tree. Currently comments are plain comments and one can't reply to a comment, so a real conversation is not possible using this feature.
4) The process of adding a comment (right click -> add comment -> write -> save (or using shortcuts left mouse click -> ctrl+shift+k -> write -> ctrl+enter) is not as fluent as it could be.
Just clicking the source in code review window could open a new comment box. And a plain enter on this box could save it.

When implementing an interface, the "Implement Interface" context menu does not insert the associated XML documentation.

It should, since that XML documentation is usually a good starting point. Consider perhaps adding a TODO tag.

The same should apply to abstract class implementation.

The alternative, copying the contents of the Code Definition window into your code, saves a lot of (re)typing. Unfortunately, the documentation does not include the XML documentation tags, which must be added by hand.

An example from the code def. window:

// Summary: <-- should be <summary>
// Performs application-defined tasks associated with freeing,
// releasing, or resetting unmanaged resources.
// <-- missing </summary>.
void Dispose();

It also looks like the documentation is not complete - is the exception documentation missing??

This comes off of the ARM Desktop post here:
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx#10266574

As stated in the article, ARM devices can't install desktop apps other than Office 15. Here is an idea to provide desktop apps via the windows store using WinRT instead of Win32:

* I agree totally with not allowing users to install applications for ARM hardware outside of the windows store. At least for the first generation of ARM PCs, this will greatly help reduce consumer confusion and improve their experience with these PCs. They find software for their PC in one place and everything they see in the windows store is guaranteed to be compatible with their ARM device. That's a very good thing from a consumer's perspective.

* I agree totally with the idea that it will be IMPOSSIBLE to get developers of win32 applications to do the same work Microsoft has done to Office, to get them to work well on low-power systems. The win32 API is simply not designed with those concerns in mind and probably never will be.

* I agree totally with the idea that ARM devices will tend to be low-power, resource-constrained devices. In these circumstances, it is VERY important to users that they be given control over what applications can do on their device, when they run, etc... That control is not something people generally have when win32 applications are involved, as every other application installs some background service, updater, etc... Every application has its own kind of installer and uninstaller, and they don't work consistently. The windows store, WinRT app model is consistent, and WinRT apps are predictable in what resources they use and in how they are installed or uninstalled, and users have centralized control over what background services these applications run (and there are limitations in how much resources those services can take up).

Where I DISAGREE with the direction the windows team is going (at least as far as I am interpreting it, I could be wrong about their intent) is in restricting altogether the ability for third parties to create some form of desktop "productivity" app for ARM devices. The fact that you are bringing the Office suite to ARM as a desktop app is a perfect example of why third parties need to be able to do this too. But how would you allow this, while still protecting users and not going against all of the above points?

The solution, in my opinion, is NOT to allow developers to port WIN32 applications to the desktop ARM environment, but to allow developers to create WinRT applications, which are distributed through the Windows Store just like other Metro applications, but which can run in the Desktop environment. This would be a slightly extended version of WinRT - a sort of "WinRT Desktop App Profile".

The extended features of the desktop profile might include additional controls for productivity apps, Load and Save dialogs that resemble the traditional Load and Save dialogs we're used to (but still allow you to go into the full-screen versions, for instance to access metro load/save dialog extensions), and any other functionality that is specific to the desktop, like the ability to manage multiple windows and modal dialogs.

However, unlike win32 apps, WinRT Desktop Apps would use the same API, with some few extensions, as the full-screen metro apps, and thus would generally run well on low-power systems and use the same kind of application lifecycle events that Metro apps use. The only difference is in how the UI is **** out, with more of a focus on the kind of dense productivity app layout that you see in developer tools, photoshop, office, etc.. Although they could be made touch friendly, they don't necessarily need to be touch-centric (just like the new Office is touch friendly but not touch-centric).

Another idea is that it would be interesting if part of the extended Desktop App profile included the ability for an app to support plugins. These plugins would be distributed on the windows store itself and would ALSO target the WinRT API. So for example, let's say Adobe released Photoshop as a WinRT desktop app. Part of the app meta-data would say that plugins for the app are supported, so that when the user downloaded Photoshop from the store, plugins for Photoshop would also appear in the store. Adobe would of course control who would be allowed to publish plugins for the app.

Hi,

Is there a way i can open 2 projects on Microsoft Test Manager at the same time. Now when i am connected to a project and i feel the need to traverse to a different project it requires me to close my initial project. I came across a msdn blog which suggests i try loggin in as a different user " http://blogs.msdn.com/b/vstsqualitytools/archive/2010/02/27/running-two-microsoft-test-manager-s-side-by-side.aspx. ". But each time i try to log in as a different user i get an error stating "error parsing c:\windows\microsoft.net\framework\v4.0.30319\config\machine.config parser returned error 0x80070005"

and then mtm crashes!

Is there anything i can do to avoid this?