В настоящее время у нас есть 2 веб-приложения MVC, работающие совершенно независимо друг от друга.Цель состоит в том, чтобы связать эти 2 сайта в какой-то внутренней сети с общей авторизацией и т. Д. И с какой-то ссылкой на домашнюю страницу.
До сих пор мы создали 3-е приложение MVC и добавили оба существующихсайты как области MVC к этому, который работает хорошо.Нам также удалось разделить каждую область на свои собственные проекты Visual Studio в рамках одного решения.
Каждая из этих двух областей определяется совершенно разными отделами бизнеса и (как правило) разрабатываются разными разработчиками и будутнеобходимо следовать независимым циклам выпуска.
Текущий подход состоит в том, чтобы каждая область имела отдельные пути к хранилищу и чтобы сервер сборки извлекал соответствующую ветку для каждой области, создавал главное веб-приложение (элемент домашней страницы интрасети), которое, в свою очередь, собирало ссылочную область.проекты.Проблема в том, что мы должны всегда развертывать все 3 проекта каждый раз, даже если только одна область хочет релиза.
Это не очень сложно (если мы случайно не развернем новый, непроверенныйвыпуск основного веб-приложения для интрасети вместе с областью), но это также означает, что сервер сборки будет отмечать все сборок конкретной сборки с одинаковым номером версии.
Второй подход былдля основного проекта интрасети ссылаться только на сборки региональных проектов, а не на сами проекты, поэтому он может быть построен сам по себе, без необходимости повторного создания каждой области или наоборот.2 проблемы с этим, я не вижу способа с MS WebDeploy (используется сервером сборки для публикации нашего кода) публиковать только определенные сборки.Во-вторых, области MVC в отдельных сборках, по-видимому, должны быть добавлены как ссылки на проекты, а не просто как ссылки на сборки, поскольку представления не динамически компилируются должным образом (отсутствует ~ / Views / web.config?)
Существуют ли более подходящие подходык этому?
РЕДАКТИРОВАТЬ: мне удалось заставить основное веб-приложение работать с регулярными ссылками на ассемблеры областей, а не ссылками на проекты (не совсем уверен, как, это просто работает).Это означает, что теперь я могу строить области независимо от основного приложения по мере необходимости.
Следующая проблема - это развертывание всей партии с помощью MSDeploy.Сборка области развернута с основным приложением в каталоге / bin, но view / scripts / content области не включены.Я смотрю на различные методы компиляции представлений в самих сборках, но пока не могу заставить это работать.