Please do work on Silverlight next version. I feel Silverlight is great tool which has best in cross development web experience. Although you guys are spending time on HTML5 and other stuffs, but I feel it takes years to bring HTML 5 is not flexible enough like Silverlight.

One more thing, as a Silverlight developer it was only my chance to replace flash from my projects, but as you guys stopped working on it; I feel that I wasted my time in learning Silverlight.

Do start working on Silverlight, Only this will get you back in increasing footprints in website business

The existing System.Resources.ResourceManager is based on .resx files built into a fallback assembly with multiple satellite assemblies. This model works fine for some situations but it is inappropriate for others. It is relatively easy to create custom resource managers but it is not simple to get an application to use the custom resource manager instead of the ResourceManager.

What is needed is an abstraction from the 'default' ResourceManager - a mechanism by which I can tell my application to use *my* resource manager instead of System.Resources.ResourceManager.

The solution should not be tied to a specific user interface technology. For example the ASP.NET Web Forms Resource Provider mechanism is designed to work with ASP.NET (Web Forms) only. The solution should work with ASP.NET MVC, ASP.NET Web Forms, WPF, Silverlight, Windows Forms et al.

The solution should be suitable for use with (1) file based resource solutions (e.g. .resx, .xliff, .rc, .csv, .resw, .po), (2) database based resource solutions (e.g. ADO.NET, Entity Framework) and (3) service based resource solutions (e.g. WCF, Web API, Web Service, OData).

Ideally the existing Strongly Typed Resource Class (STRC) implementation would use this resource manager abstraction so that all of the existing code that is based on STRCs would be able to use the new solution.

Visual Studio only provides hlsl compilation tools for C++ projects, while C# projects which also use hlsl are left without this facility. This is a glaring inconsistency in the tools provided to each language. C# is meant to be a first-class language yet the DirectX tools which are built in to Visual Studio are not equally provided to C#, this is an unnecessary and arbitrary limitation.

Developing DirectX applications with C# is becoming easier and there are now more tools than ever to work with this combination of technologies, including SlimDX and SharpDX, both fully capable managed DirectX frameworks (wrappers). Please provide C# developers with hlsl compilation, and for that matter, all the DirectX and graphics related tools that are provided to C++ developers, including the shader designer and the model editor. These features are equally usable by C#/DirectX developers as for C++/DirectX developers.

Code reviews currently can only be requested and viewed by VS Premium and Ultimate users. I fail to see why this feature is not available to anyone using TFS, regardless of Visual Studio version. If peer code review is required, then all members of the team must do it. However, in our company, we only get Premium MSDN licenses for developers that need it. Not everyone needs all the bells and whistles that come with Premium. And I don't think its worth the extra $5,000, per developer, to upgrade to Premium just to do code review. We would love to use Visual Studio for code review, but not for that price. We will have to go out and find a third party tool to do it for now.

I don't know how to write this suggestions clearer than the current title. I'll try to explain the background of this suggestions
This is the current situations in VS 2012:
1. F# has included as one of first class language since VS 2010
2. F# user base has grown larger than before, thanks to #1, Microsoft! But unfortunately? (read next)
3. Can't create ASP.NET project template using F# other than C# or VB.
4. Can't create WPF (hence Silverlight) project visually using F# (again, other than using C# or VB)
5. Can't create visual Windows Store app using F#, just like #4.
6. Other IDE such as Eclipse has provided great support and also open architecture using open plugin when dealing with Visual Designer on IDE. Therefore any language running on Eclipse can directly add visual designer support on Eclipse, not just Java and C++. It's also easier to create another visual design support for Eclipse for other programming language.
7. Xamarin has provide us F# support to create ASP.NET project and it has proven that F# is not just for numerical analysis and data centric (e.g. type provider) anymore. This will make VS 2012 less appealing to code F# on ASP.NET directly.
8. If there is other language runs on Visual Studio included as part of VS project templates, there's a large possibility it won't have visual design support other than C# or VB. Even C++ in Visual Studio can't be used to create ASP.NET and WPF projects, for example.

Based on those situations, I propose:
1. Make VIsual Studio's visual designers to be extensible and open enough (it doesn't have to be open source) to be available for other programming language to use. I know this will require large rewrite of current VS visual designer, but this closed and exclusive architecture (closed that it's only available on C# and VB) will provide less productivity when using other languages.
2. In accordance to #1 above, there should be open architecture (can be in form of open API) to simply add visual designer if there;s only small languages at initial releases for the next release of Visual Studio.

A sample use case of # 2 is: if there's VS 2015, the Visual designer support may only be available for C# and VB but the Visual designer can be available to be customized and then further repackaged as complete custom project template with visual designer supports for other language such as F# and can be other languages be another G# or Z# (or whatever) as well as long as it runs on top of .NET CLR.

The term visual designer I mentioned here includes current visual designers we have in VS 2012: ASP.NET Webform, ASP.NET MVC, WPF, Silverlight, Windows Phone, Windows Store.

Currently the only way to take advantage of the direct manipulation in a XAML Windows store app is by using a ScrollViewer. However that isn't always appropriate. For example if one wanted to implemented a fixed columns Excel type functionality where the cells of the first column should not scroll horizontally but the cells should participate in the vertical smooth scrolling and where cells in the first row (and header) should scroll horizontally but not vertically. There really isn't a way to prevent some of those from scrolling since the ScrollViewer's Direct Manipulation implementation will animate/offset the rendering in the compositor thread well before the UI thread gets any notification (e.g. ViewChanged). There are other situations as well where a control may need custom handling of the direct manipulation (e.g. synchronizing scrolling of several disconnected elements).

Unfortunately, in VS2012, a TFS get operation in Solution Explorer is basically the same as a get operation in Source Control Explorer. In the past, the get operation from Solution Explorer only obtained the files that were in the solution and projects (sln). If you wanted all other files, you used Source Control Explorer. The new design is causing us many problems because we have several files in Source Control that have absolutely nothing to do with the solution build, but have much to do with the product itself. For example, we have many documents and SQL databases that stored in TFS. The databases are stored not for their SQL structure, but for their data. The VS2012 design attempts to pull these files when they are already attached to SQL giving errors on the get. Further, TFS attempts to check out these files because it thinks they have been modified because SQL changes their content. In the past, we would only pull these files as required. Everything made sense with the previous versions. You only got the files you requested--no more. This allowed us to keep our build files up to date using Solution Explorer. Personnel who needed access to the other files would simply pull them as needed from Source Control Explorer. I would like at least the option to have the old behavior. It simply makes sense that when you ask for the files in the solution, you get the files in the solution--nothing more. Now, there is no way to get only what you want. Cloaking is not an option because it is too cumbersome on large solutions and needs manual configuration from workspace to workspace. Further, it does not work at the file level--something we require. This change seems to us to be something that was added for individuals with small solutions that fit a "typical" model. It lacks flexibility for us with large solutions and many types of files in TFS.

Implement security permissions at the test suite level within MTM. Currently one can set permissions in a test plan and in doing so the tester is unable to delete the test plan. Problem however, is there is no means to restrict at the suite level. So even if a tester cannot delete the test plan, they are capable of deleting any and every suite within this test plan. Since all test execution results are stored in the test suite, the plan setting should either be inherited by the suites or there should be a means to customize for the suites as well.