When using the /clr switch in VC++ 2012, it is not possible to include some of the new c++11 header files (i.e. <atomic> / <thread>) as compilation will break.

One typical application of c++/cli is to wrap a native class inside a (managed) ref class to expose its functionality to the .net world.

The restriction previously described prevents a ref calss to consume a native class with members like std::thread or std::atomic<T>.

A workarround (pimpl-idiom) is discussed in this topic:
(http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/9771f61c-05b7-4e3e-96fb-ac9ea31ac3f4)

The former approach requires to change existing code, therefore support for the new c++11 header files in c++/cli is proposed.

Currently the Lightswitch HTML Client for LoB apps is excellent, but also very primitive in some regards. Without controls like Tree Views or Data Tables it can be difficult to build even basic data intensive applications with LS. This is made more complicated by that fact that the client exposes only a few hooks for Javascript and HTML injection by default, and tying custom plugins and controls into LS can be surprisingly complex.

In short, it would be a huge boon to LS HTML to add more controls and would expand the use cases of it significantly.

Some controls that would be appreciated:
- TreeView
- Grids/Data Tables
- Panels (the most recent version of jQuery Mobile has this baked in)
- Some sort of navigation control

Much as I love ADO.Net Entity Data Model Designer (VS2010), one feature is making me INSANE.

When initially putting together a complex data model, it's perfectly fine (and desirable) that Designer figures out on its own where the lines delineating associations are placed. However, eventually, I wind up meticulously placing those lines myself for the sake of readability.

But if I finish my painstaking layout, and then decide to, say, add a property to an existing entity, Designer redoes my entire layout, or at least every association line that leads to or from that entity.

It's the definition of frustrating. I find myself trying to manually edit the design portion of the XML to undo some amount of the crazy changes; sometimes it works, sometimes I have to redo the whole thing manually.

Simply setting a preference to disable auto-layout, perhaps excepting the specific association being created (if you're creating a new association), would be a dream come true.

Currently, extension methods can only be defined in a static class. It would be very helpful if an extension method could also be defined in an instance class, so that this was possible:

public class Foo
{
public void DoBar()
{
new Qux().GetBaz("corge").DoGrault();
}

private static Baz GetBaz(this IQux qux, string s)
{
// Get Baz from qux here...
}
}

This simply enables a more fluent syntax for private helper methods. This can improve readability of the code compared to a more procedural-looking use of normal static helper methods.

The current workaround is to define a new internal static class, but that opens those helper methods to be used from other classes in the assembly, and sometimes such private helper methods aren't ready for that (they may not properly protect their invariants).

An alternative to the above code would be to allow extension methods to be defined in (private) nested classes.

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.