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

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

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

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

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

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

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

вместо:

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

do:

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

Если вам нужно указать разделитель пути, используйте Path.Separator и т. Д.

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

Помните :

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

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

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

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

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

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

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

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

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

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

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

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

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