如何创建自定义 .NET 基类库 (BCL) 又名 mscorlib 替代品？
有谁知道如何使自定义 BCL 与库存 CLR？如何发现CLR和BCL之间存在的最本质的联系并重用它们？
这是我到目前为止所拥有的： http://lightnet.codeplex.com
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.codeplex.com
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
查看 Script#，这是一个由 Microsoft 工作人员编写的用于将 C# 编译为 Javascript 的工具链并在他们的一些网络应用程序内部使用。这个人通过让你使用 /nostdlib 进行编译并引用他最低限度重新实现的 BCL 来做到这一点。生成程序集后，工具会通过它进行反射并将其转换为 Javascript。他使用重新实现的 BCL 来实现准确的调试，并防止您使用在 Javascript 上下文中没有意义的 BCL 功能。它看起来与您现在的代码惊人地相似，包括大多数类本身是空的或只有一些空方法的事实。这是因为 BCL 的类/方法的实现是用 Javascript 实现的。
这可能是一个专利雷区。我从最近的 Oracle 诉讼中了解到这一点：如果您按照规范实现 BCL，您就只能受到社区承诺的保护（尽管与 Java 不同，您不必同时实现 CLR）。是的，Microsoft 的专利豁免更多比 Java 自由）。我认为这是一个绝妙的想法，在很多情况下都很有用。我可以想象自己使用它来代替 DSL，或者代替嵌入脚本语言，或者代替迂腐地担心我的插件架构中的代码安全性。但从微软的角度考虑一下——如果他们允许不合规的 BCL 获得专利豁免，那么什么才能阻止有人将其专有产品称为“不合规的 BCL 实现”并获得豁免呢？
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?
鉴于这些评论，听起来您想将库存 CLR 与自定义 BCL 一起使用。
我非常怀疑这是否有效。 CLR 和 BCL 之间可能有相当多的联系 - 他们会提出一定的实施期望，并依赖它们，这并非没有道理。例如，CLR 可能依赖于某些您不知道的内部类型。
如果您设法让库存 CLR 与您自己的 BCL 实现一起工作，我会感到相当惊讶，尽管实现自定义 BCL 以与 Mono 运行时一起工作可能会简单得多 - 至少在那里您可以调试正在发生的情况，如果你遇到问题了。
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.
希望这不是我正在挖掘的古老线索，但我没有看到年份；假设它是一两个月前的（大约 2010 年 9 月）......
无论如何，这对我来说除了学术目的和只是享受乐趣/学习之外毫无用处。我怀疑它会失败，除非您使用反编译器来查看 BCL 的内部接口是什么样的，并确保您的实现符合默认 CLR 的期望；或者，查看 Mono 实现。
我认为它对于实际目的没有用处，因为 Microsoft 的 .NET BCL 是一种极其强大的实现，我怀疑一个人或一个小团队可以做得更好。需要轻量化吗？这就是 .NET CE 运行时的用途，并且在小型设备上运行良好。有人还提到了.NET MF（Micro Framework）；如果名字恰到好处的话，那是一款轻量级 MF'er。 :)
我认为实际用途的唯一方法是您自己完全重新实现 CLR/CLI/CLS（以及“CL-everything”）并创建自己的 .NET一些其他平台的实现。
编辑：请注意，如果您使用 .NET 的任何其他部分，则它使用标准 BCL；所以你不会摆脱它，但仍然需要它。如果您尝试在不存在标准 .NET 实现的平台上运行它，那是件坏事，但我不认为这就是您正在做的事情......
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...
即使您可以编写自己的 BCL，您如何让其他代码使用它？所有此类代码都是根据实际的 BCL 构建的，并且需要 BCL 程序集中使用的强名称。
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.