I looked again at the code I posted earlier (it does not compile with Beta 1):
String^ line = file.ReadLine();
Is this really what I want to do with C++/CLI? I don't think so. In practice, if I want to read a line from a file and write it to the console, I'll do something like this:
ifstream file ("test.txt");
cout << line << endl;
Why do I need C++/CLI then at all? Well, the world is moving towards .NET and managed environments and I don't want to stay behind. On the other hand, I don't partculary like the .NET object model and BCL, and I want to use "classic" C++ whenever possible.
A solution is to develop my "core logic" code in standard C++, and then to expose it to the .NET world through an interface (or "Facade", if you prefer GoF terminology).
I see three ways to do that. One is to "flatten" my facade classes and expose them as a set of C functions, which can be called through PInvoke. Another would be to make COM wrappers. Finally, I can use Managed C++ or C++/CLI to easily write CLS compliant wrappers for my facade classes. COM wrappers is something I would rather avoid, which leaves me with C vs MC++ dilemma. The "C" approach appeals me because it enables other non - .NET languages to use the libraries. On the other hand, if I care only about .NET, with Managed C++ I can create classes that can be used from .NET languages directly, without PInvoke hassles.
The bottom line is: C++/CLI is about making C++ code available to .NET world, and if it is easy enough to do that, than I don't necesseraly care about deterministic finalization, STL.NET and other cool programming techniques. I'll just use ISO C++ for that.