在 OSX 和 Mono 上使用 C# 进行开发
我即将启动一个需要我编写 C# 代码的项目。问题是，我有一台 Mac。
我想知道在 OSX 10.6 上使用 mono 进行 c# 开发是否存在任何陷阱，
我认为该页面很清楚，实现很清晰，但另一方面，我读到人们安装 VMWare 或类似的东西来使用 Windows。如果可能的话我想避免这种情况。
注意
我将在一个团队和所有的人中工作 其他人有 Windows 机器
谢谢
I'm about to start a project that requires me to write c# code. The thing is, I've got a mac.
I was wondering if there are any pitfalls involved in c# development using mono on OSX 10.6
I think the page is clear that the implementation is crisp, but on the other hand I've read that people install VMWare or something like it to use Windows. I'd like to avoid that if possible.
Note
I'll be working on a team and all the
other guys have Windows machines
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据您对 HiVoltRock 的回答（ASP.NET 开发）的评论，我想说 Mono 2.10.1 和 MonoDevelop 就可以了（MonoDevelop 的稳定版本工作得很好，但对于 OS X 上的开发，我更喜欢使用这我从 Git 编译的最新版本）。
有一些事情需要考虑，例如文件路径（即：如果 Windows 开发人员正在编写静态路径，例如
ApplicationsInstallDirectory + "\data\templates\foo.bar";您将遇到问题是，Mac 操作系统上的目录分隔符是正斜杠。此外，如果现有代码使用 P/Invoke 或其他特定 Window 功能，您将遇到麻烦。最后，如果您的代码库使用需要 Windows 的第三方库，这可能会导致问题。
供参考我们的产品从第一天起就要求它在 Linux 或 OS X 上的 Mono 上运行。考虑到这一点，我们确保考虑到跨平台执行的一切，如果您要加入现有产品，可能没有考虑到同样的问题，这意味着许多现有代码与 Mono 不兼容
。分析器将帮助确定是否你有任何不兼容的代码。
关于在 Mono 下进行开发，存在一些争议。我们的项目是一个带有 Razor 的 MVC3，使用 NHibernate、StructureMap 等运行 .NET 4，并且在非 Windows 计算机上开发时没有出现太多问题。
Based on your comment to HiVoltRock's answer (ASP.NET development), I'd say Mono 2.10.1 and MonoDevelop will be just fine (the stable release of MonoDevelop works just fine, but for development on OS X I prefer to use the most recent version which I compile from Git).
There are some things to take into account, such as file paths (ie: if the windows devs are writing static paths such as
ApplicationsInstallDirectory + "\data\templates\foo.bar";you will run into problems as directory separators on Mac OS are forward slashes. Also if existing code is using P/Invoke or other specific Window's functionality you'll be in trouble.Finally if your code base uses third party libraries that requires Windows this could cause you issues.
For reference our product has been designed since day one with a requirement that it runs on Mono on Linux or OS X. With that in mind we've made sure to consider everything with cross-platform execution in mind. If you're joining an existing product, the same considerations might not have been given, meaning a lot of the existing code isn't compatible with Mono.
The Mono Migration Analyser will help determine if you've got any incompatible code.
There is a bit of fud out there about developing under Mono. Our project is an MVC3 with Razor, running .NET 4 using NHibernate, StructureMap etc and there haven't been that many issues developing on a non-Windows machine.
请注意，Microsoft 的 .NET 库和 Mono 中的实现“大多数时候”是兼容的。如果您在团队中工作，您可能会遇到与这些兼容性问题相关的一些头痛问题（此外，如果您在编写的任何 .NET 应用程序中使用任何第三方插件，您也可能会遇到问题。） 。如果您不想运行虚拟机，我就直接进入 Windows 进行训练。如果您非常习惯 OSX UI，它可能会扰乱您的流程，但如果您团队的其他成员使用 Windows，我会这样做只是为了避免兼容性问题。
Be aware that the .NET libraries from Microsoft and the implementations in Mono are compatible "most of the time." If you're working in a team, you may run into some headache related to these compatibility issues (also, if you're using any third party plugins to any .NET application you're writing, you may have issues as well.). If you didn't want to run a virtual machine, I'd just bootcamp into Windows. It might disrupt your flow if you're very used to the OSX UI, but if the rest of your team is using Windows, I'd do that just to avoid compatibility issues.
我在 Mono（当然是 Linux）上开发的最重要的东西是 GUI。大多数无 GUI 的代码都可以正常运行。我唯一要做的就是捕获一些不同的异常。然而，图形用户界面将是一个完全不同的野兽，所以根本不要指望它们能很好地翻译。
The biggest thing I've had developing on Mono (admittedly on Linux) was GUIs. The majority of GUI-less code will run just fine. The only thing I've had to do is catch a few different exceptions. GUIs, however, would be a whole different beast, so don't expect those to translate well at all.
我强烈建议通过 vmware 使用 Windows，而不是尝试使用一些不稳定的 osx 程序进行编码。在 Mac 上编写几个小时的代码，然后意识到您的代码在任何 Windows 机器上都不起作用，或者 GUI 看起来与您的计算机上完全不同，这并不酷。始终为正确的问题选择正确的工具和语言。此外，Visual Studio 在大多数情况下都非常适合使用。
I would highly recommend using windows thru vmware rather than trying to code with some unstable osx programs. It's not cool to code for hours on a mac and then realize that none of your code works on any windows machine or that the gui looks totally different than on your computer.Always choose the right tools and languages for the right problem. Besides, visual studio is pretty nice to work with most of the time.
我遇到过一些奇怪的情况，即在 Windows 上编译代码并按原样放入 Mono Linbox 时出现内存泄漏和段错误。我在使用 xbuild 编译 .csproj 文件时也遇到了问题，其中有一些 xbuild 不熟悉的 MS 怪癖。
如果我没记错的话，这两个编译器有时会做一些略有不同的事情，这与运行时的细微实现差异有关。这很可能是我遇到的段错误和内存泄漏的原因。
我的底线是，在与运行时相同的平台上进行编译。因此，对于本地测试，你应该没问题（你在 Mac 上的 Mono 上编译并在 Mac 上使用 Mono 运行/测试）。但不要在 Mac 上构建项目，然后将生成的 Mono 二进制文件发布到运行 MS .NET 运行时的 Windows 服务器（反之亦然）。如果您有构建服务器，最好坚持下去（无论如何我们都应该这样做......对吗？）。
如果您的团队没有构建流程，并且您必须构建要发布的二进制文件，那么我将使用 Windows VM 来完成最后一步。
I've come across odd cases of memory leaks and segfaults with code compiled on Windows and dropped onto a Mono Linbox as-is. I've also had issues compiling .csproj files with xbuild that had some MS quirk that xbuild wasn't familiar with.
If I'm not mistaken, the two compilers do slightly different things at times, which are related to subtle implementation differences in the runtimes. This is most likely the cause of the segfaults and memory leaks I've come across.
My bottom line is, compile on the same platform as the runtime. So for local testing, you should be fine (you compile on mono on your mac and run/test with mono on your mac). But don't build the project on your mac and then release the resulting Mono binaries to Windows servers running MS .NET runtime (or vice versa). If you have a build server best would be to stick to that (which we all should do anyway... right?).
If your team doesn't have a build process and you must build the binaries you are going to release, I would use a Windows VM for that final step.