Подтвердить что ты не робот

Непрерывная интеграция с ASP.Net MVC

Поэтому, когда вы устанавливаете MVC в Visual Studio, он помещает DLL MVC в GAC. Таким образом, они не обязательно должны находиться в файловой системе вашего проекта, чтобы проект был создан.

Когда мы развертываем это для жизни и наш сервер непрерывной интеграции, требуемые зависимости для MVC и Razor не находятся в управлении версиями. Достаточно, почему Microsoft сделала это настолько сложным, что это вне меня.

Я один для автоматизации всего, что могу, поэтому мне интересно, как лучше всего решить проблему с отсутствующими DLL.

Теперь для проектов ASP.Net MVC я решил это с помощью развертывания bin, как указано здесь http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx в блоге Phil Haack. Это отлично работает, но у меня также есть некоторые проекты библиотек, которые ссылаются на System.Web.Mvc, которые не будут компилироваться на сервере сборки, а опции развертывания bin в Visual Studio недоступны для проектов библиотеки.

Я думаю, что правильная вещь - использовать NuGet

Install-Package Microsoft.AspNet.Mvc -Version 3.0.20105.1

Однако, какова наилучшая практика и есть ли какие-либо проблемы с использованием NuGet таким образом? например Должен ли я переключать все мои веб-проекты ASP.Net MVC для использования этого пакета из NuGet вместо bin, развертывающего DLL в GAC?

4b9b3361

Ответ 1

Мы сделали что-то подобное в проекте MVC 4.

Мы установили MVC с помощью NuGet, затем включили восстановление пакета в проекте, установив папку .nuget в репозиторий. http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html

Install-Package Microsoft.AspNet.Mvc 
Install-Package NuGetPowerTools
Enable-PackageRestore 

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

Я бы сказал, что ваш подход правильный, а не использование метода развертывания bin и передача необходимых сборок в репозиторий.