Scott Hanselman started a whole ".NET Purity" debate a few days ago, which has prompted quite a set of responses (includind a very good one from my good friend Sam.
My own personal opinion on the matter (not that anyone would care
If you're going to even remotely push for something like this, there are far better alternatives than .NET purity; things that will get you far more mileage in the long run.
Like what? Well, verifiability to start with. That by itself goes a significant way towards helping you achieve a second, more interesting goal: being able to run in semi-trusted or restricted environments.
Portability? I most certainly don't care much about it right now, and for the kind of applications *I* build, what small subset of the BCL that the ECMA standarizes is way too small to do anything useful, so it's just not worth targeting at this point.
And .NET purity is certainly a dumb statement. Much less useless than verifiability. For example, the latter will probably allow you to get your code into, say, Yukon, while the first one may not. (Of course, I know next to nothing about yukon, but that sounds like a good possibility).
Problem is, people talk about "pure .NET" as if it made the component instantly better. Well, guess what? It doesn't. It doesn't even make it more secure. Hell, you could write a pure .NET component in MC++ that's not verifiable and that could very easily just completely hose the GC heap beyond all recognition. How would that help you? Or why would that help me in any way trust your component?
Remember that pure .NET code also includes full blown unmanaged pointers (yes, that's the name, and yes, you can do quite a bit with them), almost full memory access, etc.
