Лучшие практики для переносимого C#

Не используйте Windows.Forms для графического интерфейса, но Mono, вероятно, уже упоминал об этом. Gtk # намного более согласован и надежен для кроссплатформенных графических интерфейсов.

Если вы хотите, чтобы код был переносимым, вам необходимо внимательно просмотреть список завершенных функций на сайте Mono. Они подробно описывают каждый класс в структуре и уровень полноты. Вам нужно будет принять это во внимание в процессе проектирования, чтобы не зайти слишком далеко и не обнаружить, что критически важная функция еще не реализована.

Я действительно использовал winforms, и это было нормально. Это было НО УЖАСНО, но сработало.

Очевидно, не используйте P / Invoke или какие-либо вещи win32, такие как реестр. Также помните о любых сторонних DLL. Например, мы используем стороннюю библиотеку SQLite, которая фактически содержит собственный код, который мы должны заменить, если мы хотим работать в OSX / Linux.

Я ненавижу термин «Лучшая практика», потому что кажется, что некоторые методы могут быть лучшими в любом контексте, что является рискованным делом, но я расскажу, что я считаю «Хорошей практикой» для многоплатформенного кода (и для большинства другой тип развития):

Используйте механизм непрерывной интеграции и постоянно строить для всех целевых платформ.

Звучит слишком сложно? Что ж, если вам действительно нужно поддерживать несколько платформ, лучше сделать это. Независимо от того, насколько осторожны вы со своим кодом и использованием библиотеки, если вы начнете тестирование слишком поздно, вы обнаружите, что потратите слишком много часов на переработку больших частей приложения.

Несколько лет назад я бы посоветовал вам купить себе копию моего книга на кроссплатформенной .NET, но, поскольку книга несколько устарела, вам действительно нужно придерживаться информации с сайта Mono.

Инструмент Моно-анализатор миграции (MoMA) очень хорош для анализа существующего приложения .NET и предупреждения о проблемах с переносимостью, но лучший вариант для нового кода - использовать последнюю стабильную версию Mono для разработки.

Как сказал Орион, вам нужно быть осторожным при использовании сторонних DLL, хотя мой соавтор написал инструмент NativeProbe для анализа библиотек DLL на предмет зависимостей P / Invoke, если вы действительно хотите быстро проверить стороннее программное обеспечение.

Если вы полны решимости разрабатывать на MS .NET, вам следует попробовать и убедиться, что вы также создаете и модульное тестирование на Mono, и вы также должны следить за рядом пространств имен Windows, таких как пространства имен Microsoft.Win32 и System.Management.

Есть и другие простые вещи. Например, не предполагайте символы пути. Или новые строки.

Я один из тех, кто регулярно компилирует NUnit на Mono под Linux или OSX.

Также не думайте, что компиляторы работают точно так же. Недавно мы обнаружили проблему, из-за которой компилятор MS C#, похоже, включает вещи, которых нет в Mono, и требует дополнительных ссылок в нашем сценарии сборки.

В остальном это было довольно просто. Я помню, как мы впервые получили графический интерфейс, работающий на Mono / Linux - это было довольно интересно (даже если был довольно некрасиво)

Остерегайтесь всего, что связано с манипуляциями с именами файлов и путями, и используйте переносимые методы .NET в System.IO.Path, т.е.

вместо:

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

делать:

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

Если вам нужно указать разделитель путей, вы должны использовать Путь. Разделитель и т. д.

Не используйте "\ r \ n" для новой строки. Используйте Environment.NewLine

Помните :

• * NIX использует только символ новой строки ("\ n")
• Windows использует "\ r \ n"
• Макинтош использует "\ r" (я не совсем уверен в этом - не стесняйтесь поправлять меня).

Л.Э .: Похоже, что некоторые новые MacOS больше не используют разделитель строк "\ r".

Один недостающий элемент: убедитесь, что имена файлов чувствительны к регистру. File.Open ("MyFile.txt"); не будет работать в Unix, если ваш файл называется myfile.txt.