答案 0 :(得分：15)
我讨厌“最佳实践”一词，因为似乎某些实践在任何情况下都是最好的，这是一个冒险的事情，但我会告诉我我认为多平台代码的“好习惯”（对于大多数其他类型的开发）：
始终为所有目标平台使用持续集成引擎和构建。
听起来太复杂了？好吧，如果你真的需要支持多个平台，那就更好了。无论你对代码和库的使用有多么小心，如果你测试得太晚，你会发现自己花了很多时间来重新处理应用程序的大部分内容。
答案 1 :(得分：14)
我实际上使用了winforms，它很好。这很糟糕，但它确实有效。
显然，不要使用P / Invoke或任何win32之类的东西，比如注册表。还要注意任何第三方DLL。例如，我们使用第三方SQLite dll，它实际上包含本机代码，如果我们想在OSX / linux上运行，我们必须换掉它。
答案 2 :(得分：11)
注意与文件名和路径操作有关的任何事情，并使用System.IO.Path中的可移植.NET方法，即
而不是：
string myfile = somepath + "\\file.txt";
做的：
string myfile = Path.Combine(somepath, "file.txt");
如果您需要指定路径分隔符，那么您将使用 Path.Separator 等
答案 3 :(得分：10)
不要将“\ r \ n”用于新行。使用 Environment.NewLine
记住：
L.E。：似乎一些较新的MacOS不再使用“\ r”行分隔符了。
答案 4 :(得分：6)
不要将Windows.Forms用于GUI，但Mono可能已经提到过。对于跨平台GUI，Gtk＃更加一致和可靠。
答案 5 :(得分：3)
几年前，我会建议你在跨平台的.NET上自己购买book的副本，但由于这本书有点过时，你现在真的需要坚持这些信息Mono网站。
Mono Migration Analyzer (MoMA)工具非常适合分析现有的.NET应用程序并警告您可移植性问题，但新代码的最佳选择是使用最新的稳定版Mono进行开发工作。
正如Orion所说，在使用第三方DLL时需要小心，尽管我的共同作者编写了一个NativeProbe工具来分析P / Invoke dependenecies的DLL，如果你想快速检查第三方软件的话。 / p>
如果您决定在MS .NET上开发，那么您应该尝试确保在Mono上构建和单元测试，并且还应该注意许多Windows特定的命名空间，例如Microsoft.Win32和System。管理命名空间。
答案 6 :(得分：1)
如果您希望代码可移植，则需要仔细查看Mono网站上已完成功能的列表。他们详细介绍了框架中的每个类以及完整性的级别。在设计过程中，您必须考虑这些因素，这样您就不会走得太远而发现关键功能尚未实现。
答案 7 :(得分：1)
还有其他一些简单的事情。喜欢不假设路径字符。或newlines。
我是在Linux或OSX上经常在Mono上编译NUnit的人之一。
另外，不要假设编译器的工作方式完全相同。我们最近发现了一个问题，即MS C＃编译器似乎包含了Mono没有的东西，在我们的构建脚本中需要额外的引用。
除此之外，它非常简单。我记得我们第一次得到the GUI running on Mono/Linux - 这非常令人兴奋（即使 非常丑陋）
答案 8 :(得分：1)
缺少一项：确保文件名区分大小写。 File.Open（“MyFile.txt”）;如果您的文件名为myfile.txt，则无法在Unix上运行。