Результаты поиска

.net решение подрывной лучшие практики?

Есть так много примеров того, как настроить свои проекты dotnet, но ни один из них не соответствовал нашей ситуации.

У нас есть одно решение с несколькими приложениями, несколькими зависимостями. В настоящее время мы находимся на SourceSafe и планируем перейти к subversion, но нам трудно правильно организовать наш источник.

• Пример решения

  • Приложения app1
  • Приложения app2
  • BizObjects
  • DataAccess
  • CustomControls

• Зависимости

  • BizObjects - >DataAccess
  • Приложения app1->CustomControls
  • Приложения app1->BizObjects
  • Приложения app1->DataAccess
  • Приложения app2->CustomControls
  • Приложения app2->BizObjects

У нас также есть система управления конфигурацией, которая развертывается (через копию из базы данных) в зависимости от рабочей нагрузки оператора. Мы отмечаем приложение "release" с версией и к этому выпуску мы добавляем несколько зависимостей файлов. Имейте в виду, что решение, которое мы имеем сейчас,-это попытка использовать старое (разработанное windows 3.1) решение для работы .NET структура файлов / зависимостей.

В случае App1 мы имеем App1.exe, BizObjects.dll, DataAccess.dll и CustomControls.dll. У нас есть тот же набор зависимостей для App2 из-за BizObjects ссылки DataAccess -- но это определяется вручную. У нас нет системы для идентификации дерева зависимостей.

Каждая из зависимостей для "release" - это идентификатор файла и версии. И одно и то же приложение может содержать разные версии каждого файла для разных рабочих нагрузок.

1. Где в мире мы ошиблись? Неужели мы ошиблись?
2. Как мы можем структурировать исходное дерево svn для удовлетворения требований deployment?
   • или
3. как мы можем реструктурировать код, чтобы лучше поддерживать стратегию deployment, которая имеет смысл для нашей установки?

У нас есть старое и чрезмерно разработанное решение (казалось бы) относительно простой проблемы. Может ли кто-нибудь направить меня/нас в правильном направлении?

edit: я прочитал этот вопрос и вспомнил, что у нас также есть те же области dev/test/prod, через которые должен проходить код.