So when you install MVC into Visual Studio it puts the MVC dlls into the GAC. Thus they do not need to be in the file system of your project to allow the project to build.
When we deploy this to live and our continuous integration server the required dependencies for MVC and Razor are not in version control. Quite why Microsoft has made this so complicated is beyond me.
I am one for automating everything I can so I am wondering what the best way is to solve the issue of the missing dlls.
Now for the ASP.Net MVC projects I have solved this using bin deployment as mentioned here http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx on Phil Haack's blog. This works fine but I also have some library projects that reference System.Web.Mvc that will not compile on the build server and the bin deploy options in Visual Studio are not available for Library Projects.
I think the correct thing to do is use NuGet
Install-Package Microsoft.AspNet.Mvc -Version 3.0.20105.1
However, what is the best practice and are there any pitfalls to using NuGet in this way? e.g. Should I switch all my ASP.Net MVC web projects to utilise this Package from NuGet instead of bin deploying the dlls in the GAC?
We have done something similar in a MVC 4 project.
We installed MVC using NuGet, then enabled package restore on the project, committing the .nuget folder to the repository. 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
When the project is built on the build server, the missing packages are downloaded from nuget, when deploying they are included in the bin directory automatically.
I would say your approach is correct rather than using the bin deploy method and committing the required assemblies to the repository.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With