Mono 中的系统数据
Mono 中的 System.Data 是否已扩展以包含额外的功能？ 我试图在 Mono.Data.SqlExpressions 中使用为 Mono 编写的 SQL 解析器，但是当包含 SqlExpressions 命名空间中的所有类时，该项目仍然无法编译，因为 System.Data 中的类不匹配。< br> 例如，System.Data.DataColumn 没有定义PropertyChanged 事件。 我需要使用 Mono System.Data 库吗？ 当项目中包含 Mono DataColumn 类时，不会发生此编译错误（它引用了 DataCategory 等类，这些类在 .Net 框架中找不到）。
或者，如果您能提供有关如何将 Mono 中的 Sql 解析器移植到 Microsoft 的 .Net 框架的任何帮助，我们将不胜感激。我尝试下载源代码并将缺少的库添加到项目中，但这种方法似乎有缺陷。缺少的依赖项的数量似乎增加了，而不是解决了问题。
Has System.Data in Mono been expanded to include extra functionality?
I'm attempting to make use of the SQL Parser written for Mono in Mono.Data.SqlExpressions but when all the classes in the SqlExpressions namespace have been included the project still fails to compile because the classes in System.Data do not match.
Example, System.Data.DataColumn does not define the PropertyChanged event.
Will I need to use the Mono System.Data libraries instead?
When the Mono DataColumn class is included in the project this compilation error does not occur (it references classes such as DataCategory, which aren't found in the .Net framework).
Alternatively, any help on how to port the Sql Parser in Mono to Microsoft's .Net framework would be appreciated. I have attempted to download the source and add the missing libraries to the project but this approach appears flawed. The number of missing dependencies seems to increase instead of resolving the issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Mono 试图与 MS 的实现实现二进制和 API 兼容。这意味着除了一些内部支持方法和类之外，Mono 公开的所有 API 都应该与 MS .Net 的 101 匹配。这是为了避免复杂化，就像人们假设一个方法存在一样，因为它在 Mono 中编译，但它毕竟在 MS.Net 上不起作用。
当 Mono 贡献者实现新代码和功能时，通常会将其合并到单独的程序集和项目中。 Mono.Data 顾名思义就是这样一个“扩展”，因此您需要包含所有依赖程序集才能构建它是有意义的。 Mono.Data.dll 及其依赖项是否可以在 MS.Net 上运行，这只是检查文档并进行测试的问题。
至于你的第二个问题，我无法告诉你具体细节，但除非代码有在 Windows 上运行的特定指令，否则很可能需要大量工作来移植。与任何 API 一样，许多代码不会暴露给公共接口，并且在移植代码时需要解决实现的内部功能。我建议您花一些时间分析代码的工作原理，然后尝试通过删除 Mono 代码上尽可能多的依赖使其在 MS.Net 上运行。最后，如果代码足够兼容，您应该考虑使用编译指令和 #if !MONO 编译指令来修补 Mono 的源代码，以避免给未来用户带来麻烦。
Mono tried to be binary and API compatible with MS's implementation. That means that except for a few internal support methods and classes, all the APIs exposed by Mono should match 101 with MS .Net's. This is to avoid complication like people assuming a method exists because it compiles in Mono and then it doesn't work on MS.Net after all.
When new code and features are implemented by Mono contributors it's usually incorporated in a separate assembly and project. Mono.Data as the name suggests is such an "extension" so it makes sense you need to include all the dependent assemblies to be able to build it. If Mono.Data.dll and its deps will run on MS.Net or not its a matter or checking the docs and testing it.
As for you second question, I can't tell you specifics but unless the code has specific intructions to be run on Windows it will most likely require a lot of work to port. As with any API a lot of code isn't exposed to the public interfaces and internal features of the implementation need to be worked around when porting the code. I would suggest you take sometime analysing how the code works and then try to make it run on MS.Net by removing as much deps on Mono code as it makes sense. In the end if the code is compatible enough you should consider patching Mono's source with compilation intructions and #if !MONO pragmas to save the trouble to future users.