.NET isn't really mean for real-time

I am doing some research on Internet to pick up a new language to program the machine. Since I am familiar with Microsoft products, I picked up some .NET languages to do comparison. But I found some messages in Micorsoft newsgroup which raise my concern.

The message from Consumer62000 in the newsgroup is as follows;

Let me tell you a scenario and you will see what I mean.
There is a large application that has communication with a real time
system . The app has to respond to the requests in no more than 1 s.
The app is a C# .NET app and everything is fine and everyone at
Microsoft is happy that they forced their "new" platform down someone's
throat.

Now imagine a scenario where the GC has to collect the memory. Well,
when GC runs all the threads are suspended and there is no response to
the incoming requests and application fails a critical requirement.

Well,any MS people here who can defend their sucky product,
I know they will say "don't use .NET for this or that...use C or C++
etc"

My q to them is why did you create .NET then?

Microsoft personnel reply as follows:

>Microsoft is happy that they forced their "new" platform
> down someone's throat.
Wrong. In the "C" world you still have choice. C++ works just fine. No one
forces you to use .NET.

> My q to them is why did you create .NET then?
Simple... because not all applications require real-time behavior. In fact,
I would argue that most applications do not require real-time behavior. So,
yes, .NET *may* not be the best way to go in these scenarios. You answered
your own "q". Any architect, or developer for that matter, should do their
homework before deciding how an application should be written. Use the
proper tools for the proper tasks. Microsoft gives developers options and
it's your job to decide when and how to use them.

Entire conversation can be found here.

So it is better for me not to choose .NET framework to control the machine. VB.NET and Visual C#.NET are not suitable languages for machine control. However, I feel that choosing Visual C++.NET is still a feasible solution. Visual C++ .NET unmanaged code (MFC application) can bypass some features of .NET framework. That mean it can run outside .NET framework without garbage collector. However, it will defeat Microsoft purpose of .NET to eliminate "Buffer Overrun Problem" which is very common in Visual C++.