使用 C# 和 Mono 为 OS X 构建 Cocoa UI答案

【问题标题】：Building Cocoa UIs for OS X with C# and Mono使用 C# 和 Mono 为 OS X 构建 Cocoa UI
【发布时间】：2009-04-05 23:45:01
【问题描述】：

有没有人花时间比较 Mono 的各种 Objective C 桥和相关的 Cocoa 包装器？

我想移植一个现有的 C# 应用程序以在 OS X 上运行。理想情况下，我会在 Mono 上运行该应用程序，并为它构建一个本机 Cocoa UI。

我想知道哪座桥是最好的选择。

如果它对任何人有用，这里有一些我到目前为止找到的桥梁的链接：

CocoSharp - 在 OS X 上与 Mono 一起分发 - www.cocoa-sharp.com
Monobjc - 比其他文档更好（在我看来） - www.mono-project.com/CocoaSharp 和 www.monobjc.net
NObjective - （显然）比其他人更快 - code.google.com/p/nobjective
MObjc / MCocoa - code.google.com/p/mobjc 和 code.google.com/p/mcocoa
ObjC# - www.mono-project.com/ObjCSharp

【问题讨论】：

标签： c# cocoa macos mono

【解决方案1】：

Mono 团队发布了一个名为 MonoMac 的新桥。

它本质上是他们为 iPhone 制作的 MonoTouch 框架的桌面版本。

Miguel 在他的博客上宣布了新桥：http://tirania.org/blog/archive/2010/Apr-19.html

一旦 MonoMac 成熟，我怀疑它将成为人们使用的桥梁。

【讨论】：

【解决方案2】：

我最近一直在尝试使用 F# 的 Monobjc、NObjective 和 MObjc/MCocoa，我将使用 MObjc/MCocoa。

Monobjc 是您编写的最佳文档和打包工具，但与其他两个相比非常 slow 并且不会从 ObjC“重新抛出异常”。

我相信 NObjective 和 MObjc/MCocoa 是仅有的两个从 ObjC 重新抛出异常，这就是为什么我发现它们是唯一真正的替代品。

正如here 讨论的那样，NObjective 使用带有继承的结构，我觉得这很可怕，让我最终选择了 MObjC/MCocoa。

（您也可能有许可证问题。Monobjc 和 NObjective 属于 LGPL，MObjc/MCocoa 属于 MIT ...）

【讨论】：

约翰我从你的答案中删除了接受的答案标志。请不要因此受到冒犯。您的回答仍然很有价值，但我觉得 MonoMac 是前进的方向。我希望这个页面能够反映这一点。
无意冒犯... :) 我也相信 MacMono 的发布改变了这种情况...

【解决方案3】：

我认为 NObjective 是最好的选择，因为它可以为 Objective-C 包装器自动生成代码，可以轻松配置为为 Mac OS 的其他版本重新生成包装器。

【讨论】：

关于您使用它的任何内容或遇到的问题？

【解决方案4】：

好的，我会问：你为什么要这样做？ Cocoa 的 UI 架构，包括 Cocoa-std delgates 和 Cocoa bindngs，与 Objective-C 紧密相关。 Interface Builder 和 Objective-C 的结合非常高效。尽管您可以将 Interface Builder 与许多通往 Objective-C 的桥（包括 PyObjC、MacRuby 和许多 C# 桥）一起使用，但由于框架和您选择的语言之间的任何阻抗不匹配，您将不可避免地降低工作效率。对于 C#，这种不匹配很重要。由于您正在编写本机 UI，因此失去了您将从 C# 中获得的任何跨平台优势，因此我将使用 Objective-C。对于一个称职的 C/C++/C#/Java/等。程序员，通常需要 2-3 天的时间才能在 Objective-C 中变得舒适和高效。

【讨论】：

简短回答：我不是从零开始。我想为现有的 C# 应用程序构建一个 Cocoa UI（而不是使用 GTK# 或 WinForms）。不值得在 Objective C 中复制我当前的代码，然后继续维护两组等效代码。
但是您仍然可以将 Objective-C 用于 UI，并使用您的问题中列出的桥梁之一来重用您现有的模型代码。这是在 OS X 上为跨平台应用推荐的方法。
我现在已经用了 2-3 天多一点的 Objective-C，虽然我发现它比 C++ 更干净，但它仍然比 C# 低得多。作为一名 Python 程序员，即使是 C# 也感觉非常低级和冗长。通过使用更高级别的语言，您确实获得了很多生产力。一个写得很好的 C#-Objc 桥可以让你拥有大部分蛋糕并吃掉它。
当不得不使用冗长的低级语言进行编码时，我们甚至更不用提 CTS 的真正风险（是的，Xcode 补全在一定程度上缓解了这种情况）......人们可以开始明白为什么比 ObjC 更高级的语言是 Cocoa 程序员非常渴望的目标。

【解决方案5】：

Mono-OSX 邮件列表上对各种桥接器进行了相当长的讨论。

讨论从here 与 Miguel 开始：

宣布 Cocoa# 将不再由 Novell 维护。
尝试统一社区中的剩余工作。

如果您阅读了讨论的其余部分，Mono 社区似乎倾向于 Monoobjc 或 MObjc / MCocoa；因此，如果您自己进行调查，这些可能是您需要关注的。

【讨论】：

我为这个问题添加了一个新的答案，专注于 MonoMac。如果细节对那些对 MonoMac 是如何产生感兴趣的人有用，我会保留这个答案。

【解决方案6】：

不会问为什么，因为我相信你有你的理由。

我会看一下 Unity3D 项目，看看你是否能弄清楚他们是如何做到的。看起来，嗯，很难。

【讨论】：

感谢您的回复。实际上我对已经存在的桥梁感兴趣，而不是写一个新的......