Каков стандартный способ организации проектов Visual Studio и кода для .NET. Кросс-платформенная разработка

Question

У меня довольно большое решение проектов C# в Visual Studio. Я хочу перенести некоторые из этих проектов на работу в МОНО и запустить на MAC. Конечно, некоторые вещи не работают, и некоторые вещи, которые я не хочу переносить, потому что они не применимы к MAC.

Один из подходов - это решение и проектные конфигурации. Это позволяет мне исключать проекты, которые я не хочу создавать (к сожалению, Visual Studio не делает это легко видимым, но в любом случае ...).

Второй подход, который мог бы работать в тандеме с первым, - использовать пред компиляторные директивы, такие как #if MONO, а затем сделать что-то в этой точке. Это хорошо, но затем создает несколько версий одной и той же сборки. Как отличить два от друг друга после компиляции? Это проблема?

Даже если работают два лучших подхода, иногда я хочу часть большого проекта. Я не хочу проходить через 20 или около того файлов и помещать #if MONO? Я могу захватить файл проекта вручную, но на визуальной студии нет видимости. Никто в команде не может сказать, что происходит, если они не выгружают проект и не открывают XML и не смотрят. Это звучит довольно сумасшедшим. Чтобы усугубить ситуацию, иногда проект ссылается на что-то, и я хочу исключить ссылку для МОНО. Теперь мне нужно отредактировать csproj.

Я могу разделить проект, но что, если в какой-то момент я хочу портировать еще одну платформу. Пересечениям платформы требуется, какой код может сходить с ума. Чтобы усугубить ситуацию, у меня могут быть проекты, ссылающиеся на этот крупный проект, который затем может также разделиться. Это все работает, но это вызовет перегрузку проекта, не так ли?

Я не могу найти хорошее чистое решение. Какие-нибудь советы? Есть ли стандарт для этого, я могу следовать. Если у VS было больше видимости в редактировании файла csproj, это может сработать.

Answer 1

Это хорошо известная проблема программирования, если решение существует, обычно требуется какая-то работа и даже больше, когда проект не разработан с нуля, чтобы быть портативным. Как вы правильно указали, предварительно обработанное заявление быстро станет накладными расходами и реальной болью для поддержания и расширения с течением времени.

Однако ответить на этот вопрос непросто, поскольку решение, которое вы ищете, может сильно зависело от вашей реализации. Вообще говоря, я бы посоветовал вам широко использовать хорошо известный шаблон проектирования, такие как Abstract Factory, Bridge, Facade и т.д.

Как exmaple, начните с определения каждый кусок кода, который зависит от платформы, определения интерфейсов API, отвечающие чтобы справиться с этими особенностями в вашем основном проекте и внедрить их в специализированные проекты - обычно по одной на платформу. Как только это будет сделано, вернитесь к своему основному проекту и определите интерфейс, который будет содержать фабричные методы для создания экземпляров этих конкретных классов. Снова реализует конкретные заводы в своих соответствующих проектах.

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

Answer 2

Как правило, держите проекты в решении небольшими и краткими; платформенно-зависимые биты в идеале должны быть реализованы в отдельных проектах в целом.Возможно, вам захочется взглянуть на методы создания программного обеспечения, такие как шаблон фабрики Аннотация, чтобы поддерживать зависящие от платформы зависимости, кластерные и проверенные.

На абстрактном уровне одним из подходов к разработке монитора является использование Team Foundation Server (TFS). Он в основном обеспечивает функциональность git для разработки Visual Studio, поэтому вы можете легко отслеживать csproj. Если у вас есть команда, работающая на Java или Android и т. Д. Через Eclipse, вы можете использовать TFS через плагин TFS, чтобы держать всех на одной странице и отслеживать изменения и изменения в проектах и ​​в вашем общем решении.

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

Надеюсь, что это поможет.

Answer 3

Вы также можете настроить структуру папок и разделить решение на общее решение, которое содержит независимые от платформы проекты и решения для платформы, которые содержат проекты, ориентированные на платформу.

Так например application.sln, содержащий все ваши общие проекты и ради аргумента, у нас также есть решение для iOS и Android.

• корневую папку
  • приложения (папки)
  • application.Droid (папка)
  • application.Ios (папка)
  • application.sln
  • application.Droid.sln
  • application.Ios.sln

В рамках решений, ориентированных на платформу, вы можете ссылаться на общие проекты, добавляя, например, папку [[application] »с дополнительными общими подпапками проекта для ваших проектов на платформе. Последовательное добавление всех необходимых общих файлов в качестве ссылок.

выше ответ один из возможностей вы можете также:

• Создать портативную библиотеку классов, которые вы публикуете среди платформ конкретных проектов
• Используйте MvvmCross (MvvmCross GitHub), так что у вас есть основной проект, который может ссылаться в ваших конкретных проектах на платформе