Рекомендации по переносимости C#

Question

Я ищу, чтобы написать код C# для linux/windows/mac/любой другой платформы, и я ищу лучшие практики для портативного кода.

Проект mono имеет некоторые отличные ресурсы porting.

Каковы наилучшие практики для портативных C#?

Answer 1

Я действительно использовал winforms, и все было в порядке. Это была БУТЬ УГЛИ, но это сработало.

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

вместо:

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

сделать:

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

Если вам необходимо указать разделитель пути, то вы бы использовать Path.Separator и т.д.

Answer 8

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

Помните:

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

L.E .: Кажется, что некоторые новые MacOSes больше не используют разделитель строк «\ r».

Answer 9

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