4th June 2009

MVC is finally installed on my home PC!

For those intrigued by my twitter activity tonight (OK, it was just Dave and I've already told him anyway), but still, I ambiguously cried out:

OMFG really was it that simple? I hate everything right now
http://twitter.com/cargowire/status/2034102008

As a .NET developer who likes to complain about webforms I was pretty keen to get to grips with the MVC framework when it was available. So, so I could play about with it at leisure I began a two step process:

Step 1: Install on work laptop - Done in seconds
Step 2: Install on home PC - Massive Fail

Thus began a process of occasionally coming back to it, searching for a solution, failing to find it then giving up again for a bit.

The majority of sources refer to uninstalling VS addins, ensuring you have 3.5 SP1, ensuring you uninstall any betas etc. I tried these things and failed... Eventually it was this post by Phil Haack that was the spur that led me to the solution. As you'll see I even got to the point of commenting on the poor mans blog.

Several posts, including a response to another request I'd made on the asp.net forums, were even suggesting I reinstall everything, including windows, and start from scratch. Now I really didn't want to do that, and to be honest, thought that should never be necessary to get something to install (imagine having to do that for every installation you undertake on your system).

Having attempted some of the ngen related activities proposed by Phil Haack without success I dug a little deeper into the log I was getting:

ExecNetFx: Error compiling System.Data.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089: Could not find or load a type. (Exception from HRESULT: 0x80131522)

Now without really having any prior experience with these kind of problems I was perhaps naively believing that the MVC install would have catered for dependencies and that if I was getting this error clearly there was some kind of conflict or problem (the whole uninstall-reinstall stuff scenario). This was reinforced by my attempts to run ngen ExecuteQueuedItems and ngen Update (and even an ngen delete at one point) all failing. However tonight I seemingly lucked upon the answer.

Having already previously identified I had the System.Data.Entity library sitting in the GAC (C:\Windows\Assembly) and the dll itself in C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.Entity.dll I was still looking for some other kind of problem. However I tried, virtually on the off chance, to directly ngen the dll myself rather than rely on the MVC installer to do everything for me.

            C:\Windows\Framework\v2.0.50727\ngen install "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.Entity.dll"

Immediately after doing this I started an MVC install - it worked.

And so retrospectively I was annoyed as the action I took in relation to the error I was seeing seems pretty obvious!

Anyway it's all over, I'm off to reinstall my addins. The nice thing about it though was I ended up getting a response from an asp.net team member on forums.asp.net, which reminded me how much I like the openness of Microsofts team i.e. bloggers, forum posters etc.

To save the jump heres some interesting info from Jacques:

In the Beta we only added support to the installer to GAC the assemblies, but starting with the RCs we began to create native images as well.

When the MVC installer runs it automatically performs an ngen update and compiles any assembly that might be deemed to be out of date. Any failure during the ngen process is reported back and the installation will initiate a rollback.
Jacques Eloff