TFS stores a tremendous amount of text, but finding what you are looking for with the built-in tools is not very easy. The work item query editor follows the old structured approach - which is good for some things - but is clumsy for full-text, unstructured searches. Check-in comments are even more problematic.
Imagine a search engine that crawls the full TFS content, with simple scoping (project/folder and item type) that instantly finds changesets, work items and source code. The web frontent should have a very familiar "web search engine" style, but it should also be possible to perform these searches in a more integrated fashion from VS.

Lightswitch is a killer app with respect to LoB application development. My current client is giving up on the ASP.NET platform for an LoB application because Oracle has sold them on the idea of ADF forms and their BPM (ex Weblogic) Workflow integration using JDeveloper (sic).

Lightswitch is the perfect counter to ADF offering same/richer UI interactions, speed of delivery and ease of use, however lack of Workflow Integration makes it unsuitable for developing workflow application. With Sharepoint's anemic WF support and WF runtime's default set of activities library, building LoB WF applications in ASP.NET is a pain.

1. Throw the workflow designer in LS or using the Visio Workflow Designer canvas to allow users to build BPM workflows.
2. Do the code plumbing behind the scenes to use Windows Workflow Runtime engine.
3. Provide a drop in Task Library functionality
4. Enhance the Workflow Activities library with basic activities like sending email, calling webservice (I guess it's already there, but look at Nintex for Sharepoint's WF implementation to see how it can be targeted for business users), doing HTTP Post, creating Tasks, LDAP integration.

Voila! LS will beat the pants off anything ADF+BPM can do. Oh, yes, icing to cake would be publish to Sharepoint :-)

If you're a C# developer, I bet you've used something like this before:

***** SomeType DoSomething(params AnotherType[] array){...}

It is a lot easier to use the 'params' modifier than to create a new array with all the paremeters of the same type you want to insert in a method, specially when it comes to small test projects.

However, using this comes with a disadvantage: you MUST use the array type. No IList, List<T>, Dictionary<TKey, TValue>, etc.. I believe there is no such reason not to allow these list-like types to use the params keyword. Example:

***** SomeType DoSomething(params ListType list){...}

Of course you may wonder how is the compiler going to know witch types to accept. Well, for that I have several suggestions: there may be an obligation to derive it from IList<T> or to have at least one indexer... I don't know. What I do know is that this would be a good feature.

The idea is to show the status of workflow graphically. Typically we can do it by re-hosting the designer in a Rich Client, but the web equivalent is rather painful. Need a new HTML5 implementation. I have been planning on starting an open source version for a LONG time now, need the right kick in the pants to get down in. In my lob app I am using a highly customized version that spits out ImageMaps (sooooo web 1.0)...

Once the visualizer is up, extend it to do small designer functionalities. Something akin to Nintex's workflow designer for Sharepoint. Something like that for ASP.NET would give lob apps a real kick.

Every single time I add a project to a solution, Visual Studio "helpfully" adds to the solution every configuration it finds in the project.

Every single time the project has a platform that the solution doesn't, Visual Studio "helpfully" creates the missing solution platform and also, most annoyingly, "Mixed Platforms".

PLEASE leave them alone. I set them up how I like and I'd like them to stay that way.

Example use case #2:

I create a new project (defaults to x86) and add a Util library (AnyCPU). Wham, I'm only 5 seconds into a new project and I already have to clean up "AnyCPU" and "Mixed Platforms" from my solution platforms.

Example use case #1:

A library project has four configurations: Debug, Release, DebugWithFeatureX, ReleaseWithFeatureX. I add this to a project that has existed for years. The configurations "*WithFeatureX" only make sense for the library; the project is supposed to choose one of them and stick with it.

Instead, the users of the library are forced to clean up these never-watned configurations.

Problem:
I work for a large organization where we have 1000's of developers and we are constantly battling losing our admin rights. In order to get the software we need we have to have it packaged by the bank and pushed to the users machine. In the case of Visual Studio 2010 which is huge in itself, when a service pack is released we have to increase the install time even more by adding the Service Pack as a post install action.

Would like to increase client satisfaction by having available an install that includes the service pack(s) in the main installer, whether it's for 2010 or for Dev 11, in either case would love to see it happen.

Particularly in the world of C++, where the delta between what the compiler accepts and what the standard says is quite large, it is common for people to report bugs against the compiler.

Often, however, these are met with refusals to fix the compiler, and claims that there are workarounds.

I would love you to change this policy.

Yes, sometimes there is a zero cost workaround to a particular flaw. But that's not a reason to not fix the bug. I write code that I wish to compile in g++, VC++, and sometimes even clang++. Being forced to avoid standard constructs just because they provoke a VC++ bug is aggravating in the extreme.

Please stop treating workarounds as if they were good enough. We want to be able to use the best possible C++ compiler.

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.

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.