One of my frustrations as a developer in this rapidly changing world is deciding which technology to use. Sure, if I did nothing but read technical journals it would be easy, but that is a big IF. So when I want to create a new project and I have too MANY choices. If I'm creating a NEW project I don't want to have outdated options. I don't want to create an MVC 3 application, thank you very much, because I'm *assuming* that Microsoft made MVC 4 to be the better choice. Tonight I had to decide if my MVC 4 web app should have an ADO.NET Entity Data Model or an EF5.x DbContext Generator template. Simple solution: Prefix any template for which a better alternative exists for new projects with a "Legacy-" prefix and anything for which there is no other equally future-proof template with "CurrentBestPractice-" prefix. "More" is not "better" when it comes to choices unless the choices are contextually appropriate. The ideal number of choices, ideally, is zero, not a thousand!

I'm NOT just griping but rather hoping to help an awesome company make an awesome product that much more awesome to an awesome developer (me) and the other awesome developers.. better! MSFT, keep up the great work... your team amazes me!

Microsoft,

I can't stay silent any longer. I've got to get this off my chest. For too long you guys have ignored users, like myself, that want to get the most from our machines and program for users that want the same.

For too long Microsoft has ignored users that find managed code an unacceptable solution to many of today's computing requirements. These users expect and need a modern language to include both SPEED, CONTROL and FUNCTIONALITY. They believe the problem with .NET is that it focuses too much on functionality at the expense of speed and control. For people who want to write in a language that generates the fastest possible code (which enhances the user experience at every level), C++ is still the only answer.

Now I know the people at Microsoft are smart. Very smart. Perhaps a little too smart. But I know that you guys can write this thing if you want. I can't understand why it hasn't already been written. Why can't you see the market potential? Java is a sloth. It's generates the epitome of bloat ware. They're toast as managed code will ALWAYS be behind the 8 ball because speed can't grow forever. Microsoft is discovering that now in Windows 8 and mobile. Thus, there's a HUGE potential for a language that offers a rich feature set like .NET that makes writing high quality applications faster but does not force a managed approach.

A managed approach is fine for environments that need RAD or don't care about speed. But that set does not include by any stretch, the totality of computer users around the world. Many of us still want our computers to run fast and solve problems that demand speed.

The proof of that is the persistence of C++. Despite Microsoft's best efforts, C++ has not withered away. Despite complete and utter neglect by the world's largest software company and in Microsoft-compliant universities, C++ is still in wide use. If that doesn't speak to demand I don't know what does. People want speed and they want to get the most from their machines and the programmers want to write applications that maximize performance so people can get the most from them. It makes their apps the best they can be and maximizes the user experience. Thus, this new language doesn't force garbage collection, it doesn't put anything between my bits and the processor above what is already done in C++. This language generates efficient native code AND offers the functionality of .NET. It provides conventional managed environment as an option. I know you guys can do it.

This is a flexible language that meets the RAD requirements of slothy business uses and excels at generating fast, efficient code with responsive, snappy, modern user interfaces and maximum performance for the rest of us. The only extra overhead required in this language is that the programmer needs to keep track of managing memory as there is no garbage collection. Perhaps there's some additional overhead with technology-specific solutions such as COM+ and others but they are options not requirements.

The garbage collection issue which is a big argument for managed code can likely be solved by better debugging tools built into the development environment. I could elaborate but I'm sure people that work on these problems have an idea what that might be. It's starts by keeping track of how and where objects are created and used throughout their life. If the will of management is there to deliver a simpler solution rather than a more complex one, the issue of memory leaks can be largely solved.

.NET is great for business applications with minimal speed requirements. But there's the rest of us that want to get the most from our machines and program for people that want the same. I'd even go one further and say that if even the average user could make a side by side comparison of the exact same app written in .NET and native code that had available the same modern API, the native code would win handily. Speed simply enhances user experience on every level and it's high time Microsoft stopped messing around with managed and acknowledge that reality. If you don't, I'm sure the market will sooner or later.

.NET is starting to have a lot of the same "mess" than Java had when .NET pummeled it in the early part of the last decade. We have stuff like ArrayList, non-generic collections, ADO.NET, stream-based XML processing, and LINQ to SQL all cluttering up the libraries. It's rare I find a .NET developer who things he's using the best tools available but is wasting his time using some of these older, slower, ******-to-use libraries.

.NET is becoming too hard to learn to be good at for new developers fresh out of school. They're going to go to other languages they can find their way around faster. They're also getting taught old and crufty stuff from the old and crufty developers who are comfortable.

At the same time, the last few versions of .NET are moderate evolutionary steps; we need revolutionary before .NET gets pummeled by the competition. Make a grand gesture that .NET vNext is about the future, not the past, and fully remove (not just mark depracated) every feature that doesn't have a serious, truly compelling use case over its alternative in the same library. Yes, it's a breaking change; don't be afraid - it's what's needed. People who haven't updated their .NET app in 10 years will just keep using a previous version, and they'll survive.

Many other teams at Microsoft are starting to demonstrate that the winds are changing for partners who insist on not changing APIs and embracing change. They're making bold statements about the future and rallying the troops around them. Do the same and sweep the messy stuff out of .NET vNext!

I want the xml comment warnings for code generated by our developers, because it is in our coding standards to add xml documentation. However, we are using Coded UI, so there are many auto-generated code files included in our project, which clutters up the Error List (when treating warnings as errors) with thousands of errors we have no control over.

I want to be able to turn on the xml comment warnings in general, but disable the xml comment warnings for only code files that are auto-generated that we have no control over.

So, please add one of the following:
1. a way to disable the XML comment warnings for either all auto-generated code
2. a way to disable the XML comment warnings for certain file extensions (.Designer.cs).
3. Auto-generated code to include all xml documentation as to not cause the warnings

We know the issue about solution folders not being real windows folders. Not saying we change that, but, just as any project has a "Show all files" button in solution explorer, let's have a similar button active for the solution itself.

It'd still show any folders not mapping to projects or solution folder as "not included" (like in projects when you have other files you need to right click and "include" them in project).

An enhancement might be also being able to create equivalent solution folders (as in: the "include" feature), but just accessing the solution windows explorer folder from solution explorer will be enough really.