|
But basically .NET is intended for user level application programming, therefore it hasn't integrated all WIN32 API access, only via P-invoke.
At last, there are very rare situations, when data processing or something like application needs to directly address OS low-level functions.
If one is coding not only for fun, but for money also, .NET with it's VS2005
greately reduces developing/debugging and projecting time, especially buiding user interface and database design (and as we know, time is money .......).
BTW, i'm mainly building data acquisition and remote/telemetry systems and even then i don't need in low-level resources access, excluding mobile devices itself, of course.
Factically, even system service, written on .NET, works with the same results and efficiency, that oldest one, based on MFC (W2003 server, some sort of gateway/proxy).
About efficiency - after switching to .NET we were increased minimum hardware requirements for database client workstations to Pentium 2, however even P166 with 64M works well. From user's point of view, installation and maintanence are much more easy, than MFC or VB runtime dll support. User intarface, built using .NET is much faster, than this same on Java base.
Self-contained executable is good thing, but in case, for example Delfi, this comes at some cost - dlls are linked into executable, greatly increasing it's size. And .NET runtime must be installed on computer only once. All other executables after that becomes like self contained.
So, i personally have nothing bad to say in VS2005/.NET address, if target system has enough CPU and RAM resources. But these are now not expensive parts. If i need to access some sort of unmanaged resources (for example LPT, USB ...), i'm using C++.
|