Tuesday, 14 October 2008

Problems with MVC and Continuous Integration

It seems I don't have much time to write these days, but I've finally got another worthwhile piece to share. After sorting out our issues with MVC Preview 5 on VS2008, we promptly ran into trouble when adding our MVC projects to the Continuous Integration process. The MVC project would not build because of missing DLL references. Steve had installed MVC Preview 5 on the build-server, so this was more than a little odd.

However, after digging around for a while Steve found that this wasn't really an issue with missing DLLs on the build server at all. Rather, it was an issue with a couple of hintpaths in the MVC project file. The project file had stuff in it like this:




Do you see what's going on here? The hint-path is relative, and points to \Program Files\ on the C:\ drive! This is an issue for us, because the actual build happens on the E:\ drive of our build server. So... what to do?

We use Subversion as our source repository, and frequently apply svn:externals to our project repos to pull in common third-party DLLs (such as Moq, NUnit, NInject etc). So why not use the same approach for the culprit MVC DLLs? That's exactly what we did and it solved the problem nicely.

We've got a separate repository called BinaryDependencies which holds all our third-party DLLs. Whenever one or more of these DLLs are required we add a svn:external reference to the BinaryDependecies repository to pull in the relevant DLLs to the local project, and then it's simply a matter of replacing the existing references to Microsoft.Web.Mvc.dll (and any other offending reference that's broken) with a local reference. Simple!

Of course, this isn't a lasting solution because you'll have to update the DLLs in the BinaryDependencies repository every time a new version of MVC comes out. BUT, it does get you up and runnig for now - and besides, MVC's soon going to be in Beta and first release... and I assume these particular problems will have been fixed by then!

4 comments:

Pathik Thaker said...

Hi

I did the same thing. Created a folder named "Lib" and added all libraries to this folder. After adding all dll to this folder, added reference from this folder and my project shows hintpath relative to Lib folder. But still it is throwing me an error. Do you have any idea ????

Øyvind Valland said...

Hello Pathik,

I don't want to seem to be avoiding your question, but it appears that the reference problems in Preview5 have been fixed in the most recent beta release. Try downloading and installing that and see if it fixes your issues?

Cheers,
Øyvind

Pathik Thaker said...

Thanks, It worked. I spent around 2 days in searching solution for this.

Jeremy Simmons said...

sorry to open/repost on old thread.
We use a similar approach storing third party libs in a separate repository.
http://scmserver/svn/thirdparty/NUnit/trunk/
http://scmserver/svn/thirdparty/Log4Net/trunk/
The key is to make a tag for each version of Lib, and reference that tag in the svn:externals in your main project.
http://scmserver/svn/thirdparty/NUnit/tags/2.5,http://scmserver/svn/thirdparty/NUnit/tags/2.6 etc.
in our project
http://scmserver/svn/Product/trunk/Lib/NUnit, the svn:externals property of NUnit can be either http://scmserver/svn/thirdparty/NUnit/tags/2.5 or later http://scmserver/svn/thirdparty/NUnit/tags/2.6
We get full versioning on the lib, and our specific version of
http://scmserver/svn/Product/trunk/ is only tied to a single version of the Lib, which we are sure won't change.