首页 / 知识

关于mono：便携式C＃的最佳做法

2023-04-14 03:16:00

我正在寻找为linux / windows / mac /任何其他平台编写一些C＃代码的方法，并正在寻找可移植代码的最佳实践。

Mono项目有一些很棒的移植资源。

便携式C＃的最佳做法是什么？

我讨厌"最佳实践"一词，因为似乎某些实践在任何情况下都可能是最好的，这是一个冒险的事情，但是我将告诉我我认为多平台代码(以及大多数情况下)的"最佳实践"其他类型的开发)：

使用持续集成引擎并始终为所有目标平台进行构建。

听起来太复杂了吗？好吧，如果您确实需要支持多个平台，那么最好这样做。不管您对代码和库的使用有多么谨慎，如果测试太晚，就会发现自己花费大量时间来重新编写应用程序的大部分内容。

我实际上使用过winforms，这很好。这是丑陋的，但是奏效了。

显然，不要使用P / Invoke或诸如注册表之类的任何win32东西。还应注意任何第三方DLL。例如，我们使用了第三方SQLite dll，它实际上包含本机代码，如果要在OSX / linux上运行，则必须交换本机代码。

注意与文件名和路径操作有关的所有内容，并利用System.IO.Path中的可移植.NET方法。

代替：

1	string myfile = somepath +"\\\\file.txt";

做：

1	string myfile = Path.Combine(somepath,"file.txt");

如果您需要指定路径分隔符，则可以使用Path.Separator等

不要在新行中使用" \ r \ n"。使用Environment.NewLine

请记住：

L.E .：似乎某些较新的MacOS不再使用" \ r"行分隔符。

不要将Windows.Forms用于GUI，但是Mono可能已经提到了。对于跨平台的GUI，Gtk＃更加一致和可靠。

几年前，我曾建议您给自己买一本跨平台.NET的书，但由于该书已经过时，您现在确实需要坚持Mono网站的信息。

Mono迁移分析器(MoMA)工具非常适合分析现有的.NET应用程序并警告您可移植性问题，但是新代码的最佳选择是为开发工作使用Mono的最新稳定版本。

正如Orion所说，在使用第三方DLL时需要小心，尽管我的合著者编写了NativeProbe工具来分析DLL的P / Invoke相关性，如果您想快速检查第三方软件的话。

如果确定要在MS .NET上进行开发，则应尝试确保在Mono上进行构建和单元测试，并且还应注意许多Windows特定的命名空间，例如Microsoft.Win32和System.Management命名空间。

遗漏的一项：确保文件名区分大小写。 File.Open(" MyFile.txt");如果您的文件名为myfile.txt，则无法在Unix上使用。

还有其他一些简单的事情。就像不要假设路径字符。或换行符。

我是定期在Linux或OSX上的Mono上编译NUnit的人之一。

另外，不要假设编译器的工作原理完全相同。我们最近发现了一个问题，其中MS C＃编译器似乎包含了Mono一个不包含的内容，这需要在我们的构建脚本中进行额外的引用。

除此之外，它非常简单。我记得我们第一次让GUI在Mono / Linux上运行-这非常令人兴奋(即使它很丑陋)

如果您希望代码具有可移植性，则需要仔细查看Mono网站上已完成功能的列表。他们详细介绍了框架中的每个类以及完整性级别。在设计过程中，您将不得不考虑这些因素，以免您走得太远并且发现尚未实现关键功能。