Существует очень много примеров того, как настроить ваши проекты dotnet, но ни один из них не подходит для нашей ситуации.
У нас есть одно решение с несколькими приложениями, несколькими зависимостями. В настоящее время мы работаем с SourceSafe и планируем перейти на Subversion, но нам трудно правильно организовать наш источник.
Пример решения
- App1
- App2
- BizObjects
- DataAccess
- CustomControls
Зависимости
- BizObjects-> DataAccess
- App1-> CustomControls
- App1-> BizObjects
- App1-> DataAccess
- App2-> CustomControls
- App2-> BizObjects
У нас также есть система управления конфигурацией, которая развертывается (посредством копирования из базы данных) в зависимости от того, с какой рабочей нагрузкой работает оператор. Мы помечаем «выпуск» приложения версией и к этому выпуску добавляем несколько файловых зависимостей. Помните, что имеющееся у нас решение - это попытка помочь старому (разработанному для Windows 3.1) решению работать со структурой файлов / зависимостей .NET.
В случае с App1 у нас есть App1.exe, BizObjects.dll, DataAccess.dll и CustomControls.dll.
У нас есть тот же набор зависимостей для App2 из-за BizObjects, ссылающихся на DataAccess, но это определяется вручную. У нас нет системы для определения дерева зависимостей.
Каждая из зависимостей для "релиза" - это файл и идентификатор версии. И одно и то же приложение может содержать разные версии каждого файла для разной рабочей нагрузки.
- Где в мире мы ошиблись? Мы ошиблись?
- Как мы можем структурировать исходное дерево svn для соответствия требованиям развертывания?
- как мы можем реструктурировать код, чтобы лучше поддерживать стратегию развертывания, которая имеет смысл для нашей установки?
У нас есть старое и изощренное решение (казалось бы) относительно простой проблемы. Кто-нибудь может направить меня / нас в правильном направлении?
edit: я прочитал этот вопрос и вспомнил, что у нас также есть те же области dev / test / prod, через которые должен пройти код.