How to create a custom .NET base class library (BCL) aka mscorlib replacement?

Does anybody know how to make a custom BCL work with the stock CLR? How to discover existing the most essential ties between CLR and BCL and reuse them?

Here is what I have so far: http://lightnet.codepl开发者_高级运维ex.com

---

• Check out Script#, a toolchain for compiling C# to Javascript that was written by someone working at Microsoft and is used internally for some of their webapps. The guy does it by making you compile with /nostdlib and reference his minimally reimplemented BCL. After an assembly is produced, a tool reflects through it and turns it into Javascript. He uses the reimplemented BCL to enable accurate debugging and to prevent you from using features of the BCL that don't make sense in a Javascript context. It looks strikingly like your code does now, including the fact that most of the classes are either empty themselves or only have a few empty methods. This is because the implementation of the BCL's classes/methods are in Javascript, instead.

• This could be a patent minefield. I learned this with the recent Oracle lawsuit: you're only covered under the community promise if you implement the BCL to spec (though, unlike Java, you do not have to implement the CLR alongside of it. Yes, Microsoft's patent exemption is more liberal than Java's). I think this is a fantastic idea that could be useful in many situations; I can imagine myself using this instead of a DSL, or instead of embedding a scripting language, or instead of pedantically worrying about code security in my plugin architecture. But think about it from Microsoft's perspective- if they allowed patent exemptions for non-compliant BCLs, what's to stop somebody from calling their proprietary product a "non-compliant BCL implementation" and reaping the exemptions?

---

Given the comments, it sounds like you want to use the stock CLR with a custom BCL.

I highly doubt that that will work. The CLR and BCL are likely to have quite a few ties with each other - they will make certain implementation expectations, and rely on them, not unreasonably. For example, the CLR may rely on certain internal types which you wouldn't know about.

I would be reasonably surprised if you managed to get the stock CLR to work with your own BCL implementation, although it would probably be significantly simpler to implement a custom BCL to work with the Mono runtime - at least there you can debug what's going on if you run into problems.

---

Hope this isn't an ancient thread I'm digging up, but I don't see a year; assuming it's from a month or two ago (circa Sept. '10)...

Anyway, this sounds useless to me beyond academic purposes and just having fun/learning. And I would suspect it's going to fail unless you use a decompiler to see what the internal interface of the BCL is like and make sure your implementation meets what the default CLR expects; alternatively, check out the Mono implementation.

I think it's useless for practical purposes because Microsoft's .NET BCL is an extremely robust implementation, and I doubt one man or a small team can do better. Need lightweight? That's what the .NET CE runtime is for, and works well on small devices. Someone also mentioned the .NET MF (Micro Framework); and that is one light-weight MF'er if the name does it justice. :)

The only way I see a practical use for this would be if you totally re-implement the CLR/CLI/CLS (and well, "CL-everything") yourself and make your own .NET implementation for some other platform.

EDIT: Note, if you use any other portion of .NET, the standard BCL is used by it; so you won't have gotten rid of it and it will still be needed. Bad thing if you're trying to run this on a platform where the standard .NET implementation doesn't exist, but I don't think that's what you're doing...

---

Even if you could write your own BCL, how would you get any other code to use it? All such code is built against the actual BCL, and expects the strong names used in the BCL assemblies.