Umnanaged code is not bad, but adds its own set of problems. More managed the code is, less your problems with things like memory leaks

The big advantage of 100% .NET code is that it lets you staff more flexibly. If your developers only need to know .NET technologies, you can hire more widely than if they need to know .NET and COM/Win32.

Much said of PInvoke and COM Interop here, I have heard that the next version of the CLR will do away with this. If this is the case it will be interesting to show how many of the arguements stand.

You say something about the Java VM and that's 100% pure and .NET is not. This is not true. F.e. Sun's Java VM runs native OS threads instead of threads using it's own Virtual CPU, when you start a thread in Java. When you use PInvoke or Com in .NET it's the same as using JNI in Java. What's the difference? I don't see it.

You have any notions of ever running a piece of code under Mono?... then "pure .NET" suddenly becomes a practical consideration.

Good comments and points from everyone.

Java is been known among developers as following: "Write once, - debug everywhere". This is mostle because of inconsistencies in implementation of OS abstraction layer in particular implementation of Java VM. Windows.NET aparently does not have this problem - because it does not intended to run on variety of OSes. I bet that Windows XP and Win2K are behaving similar in most cases but also I'm sure that there are some cases whare results of execution are different under different service packs (or whatever). Mono.NET (sorry for politically incorrect term) will be clear of the problem as soon as it remains on single Linux OS.

sorry for typos in the previous post...