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