Как я могу условно скомпилировать мой C# для Mono и Microsoft .NET?
Ответы 2
Компилятор Mono определяет __MonoCS__
НО НО НО, весь смысл Mono в том, что вы можете взять сборку, созданную с помощью VS, и запустить ее в Mono, или наоборот.
Мне кажется, что если вам нужно иметь различия между Mono и MS.NET, тогда вам нужно принимать эти решения во время выполнения.
Стандартный способ обнаружения Mono во время выполнения:
bool runningOnMono = Type.GetType ("Mono.Runtime") != null;
Одним из вариантов использования является графический интерфейс GTK # в Mono и графический интерфейс Windows.Forms в .Net.
Будет - проблема, с которой я столкнулся, заключалась в поведении WinForms BindingSources, привязанных к объектам, реализующим INotifyPropertyChanged. Очевидно, это было некоторое время назад, и, может быть, сейчас все в порядке.
Если вы используете развертывание одним щелчком мыши и у вас есть глобальный обработчик ошибок, который захватывает информацию одним щелчком мыши из System.Deployment, в противном случае вам придется условно скомпилировать.
Иногда необходимо использовать макрос, поскольку Mono не сможет скомпилировать то, что хорошо компилируется в Windows. Например: AppDomain.CurrentDomain.FirstChanceException просто не определен в Mono.
@Will Dean Иногда вам нужно использовать условные компиляции. Например. Mono не поддерживает атрибут; ViewStateModeById, который вызывает сбой во время выполнения, если вы пометили им класс. То, что вы говорите, не совсем верно ...
Я не знаком с этим атрибутом, но мне все еще кажется, что будущее присутствие или отсутствие атрибута ViewStateModeById не является чем-то, что напрямую коррелирует с компилятором, который использовался для компиляции ваших сборок. Но всегда есть MonoCS, если это так ...
@Will Это вызовет сбой во время выполнения при попытке загрузить сборку ... :( Но в целом я согласен с вами, хотя это не всегда возможно ...
НО НО НО суть Mono не в том, что вы можете взять сборку, созданную с помощью VS, и запустить ее в Mono, или наоборот. Это зависит от платформы .... как насчет продуктов Xamarins для Mac и мобильных ??? они изобрели моно, и они этого не делают. Значит, вы явно ошибаетесь. Иногда это работает, но с другими не работает.
@AnthonyLambert - Посмотрите на дату моего ответа - он был написан еще до того, как появился Xamarin.
Вау, ты прав ... время не летит ... в любом случае, все меняется, и если оставить это так, то это неверно и неправильно для сегодняшней аудитории.
Я хочу скомпилировать код в Mono, который использует сборку, которой нет в Mono using System.Deployment.Application; - это не может работать во время выполнения, потому что оператор using не компилируется в Mono. С переключателем компиляции я могу это сделать.
Ясно, что бывают случаи, когда код на одной платформе будет отличаться от кода на другой, и вы можете захотеть сделать это во время выполнения или, возможно, во время компиляции. Иногда это невозможно сделать во время выполнения.
Например:
Mono используется в качестве основы для наборов инструментов Xamarin для iOS, Android и Mac. Хотя у них много общего кода, у них также есть классы, которые появляются только на одной платформе. При разработке с помощью этих наборов инструментов вы разрабатываете собственные пакеты, которые не подлежат обмену между платформами.
Простой случай - имена файлов и пути. Они различаются на каждой платформе. Я просто мог бы иметь небольшое условие, чтобы загружать струны по-разному на каждой платформе. Некоторые платформы имеют имена файлов, зависящие от регистра, некоторые - нет.
Было бы неплохо, если бы был небольшой фрагмент кода, который возвращал бы текущую платформу - будь то UNIX, iOS, Mac, X86, X64, XBox и т. д.
В .NET уже есть абстракции для переносимой обработки путей. System.IO.Path.DirectorySeparatorChar, например. Таким образом, нет необходимости создавать собственную логику для обработки различных возможностей ОС в этом случае.
Поймите суть дела, но у Mono есть чем наверстать упущенное, и нет смысла наказывать сборку MS ... Хороший совет, хотя спасибо