Структура проекта и система сборки для .NET, подключенная к git

Question

это вопрос, касающийся структуры проекта с использованием .NET / git и системы сборки, поэтому я постараюсь сделать его кратким:

Установка:

• .NET (C # и VB.NET)
• git (ранее svn, мы не использовали внешние)

следующая структура проекта, которую я пробовал:

• [NameOfApp]
  • .git
  • [NameOfApp - файл решения непосредственно под ним]
    • [Project1]
  • [Config]
  • [Стандарт]: некоторые стандартные конфиги для разработчика (они копируются при первом
    инициализирует репо, но он может их изменить)
  • [Скрипты]: некоторые скрипты, а также скрипт для системы сборки
  • [зависимости]
    • [зависимость 1]: это подмодуль
      • [главная папка]
        • [Solution-файл]
          • [Проекты]
      • [зависимости]
        • [подзависимость 1]
        • [подзависимость 2]
          • [Зависимость 2]: другой подмодуль
          • [Другое решение]: в подмодуле иногда у меня есть маленькие помощники для некоторых проблем во время процесс сборки. Вызывается сценариями сборки.

Я ищу хорошую структуру для всех наших проектов, приведенная выше структура пока используется только для одного проекта.

Итак, мои вопросы:

• выглядит ли это как действительная установка для вас? Я знаю, что это сложный вопрос, но у вас есть похожие настройки или у вас были проблемы с подобными настройками.
• Вы бы использовали подмодули git вообще или есть что-то лучше? Некоторые говорят, что они злые и могут вызвать проблемы. Просто для информации, мои подмодули - это проекты, которые используются многими проектами. Зависимости иногда содержат файлы решений, поэтому у меня есть папки проекта. Проекты внутри тогда упоминаются в моем mainapp. Я не знаю, является ли поддерево адекватным, я слышал также о репо (для Android), возможно, это решение? Или есть другие инструменты для управления зависимостями?
• Иногда мои зависимости тоже имеют зависимости. Поэтому, когда я делаю рекурсивный клон, я получаю несколько странную структуру с подзависимостями (см. Структуру выше). Иногда мне нужно добавить подчиненные зависимости в мое основное приложение, потому что я хочу что-то там изменить, и для зависимости требуется перестройка. Так как же сохранить субзависимости или субзависимости?
• если у вас есть зависимости с открытым исходным кодом (например, от github), используете ли вы dll напрямую? Или вы разветвляетесь и добавляете подмодуль git?
• Добавляете ли вы все свои проекты в качестве ссылки на проект или вы ссылаетесь непосредственно на dll (например, для ваших подподразделений или подузлов, чтобы немного разбить его и не всегда перестраивать все дерево проекта)?
• Какую систему сборки вы предпочитаете?

Я знаю, что это не вопросы с одним "правильным" ответом, но, возможно, вы можете мне немного помочь и поделиться некоторыми мыслями.

Спасибо, Cyber1000

Answer 1

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

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

сохранить подзависимости: не сохраняйте, поскольку наш сервер сборки всегда запускает "git clean" перед каждой сборкой.

open-source-зависимостей: Форки и использование в качестве подмодуля, мы можем иметь незначительные изменения для удовлетворения наших потребностей.Например, файлы проекта VS2005, и мы используем VS2010.Затем мы изменяем файлы проекта и объединяем ветку upstream, когда доступна новая версия.

ссылка на проект: по возможности используйте ссылку на проект большую часть времени.

сборка системы: CruiseControl.NET, asпарень .NET.