Jun 16, 2011

WPF and Ninject

I waited a while before embracing WPF hoping to avoid a lot of bleeding edge pain. I must not have waited long enough. I haven't been using Visual Studio 2010 that long but it appeared to be pretty stable for WinForm applications. Now that I'm working on WPF it crashes about three times a day. (Update 8/2011– I'm not sure what changed, but the crashing has gotten much less frequent) Nothing I can repeat, I'll just do something outrageous like click on a tab and BOOM goes the dynamite and crash goes VS. I then wait several minutes while it communicates with Redmond and it will work again for several more hours.

Aside from that things have gone reasonably well with WPF until I added Ninject to the project and my XAML designers started barfing "The type universe cannot resolve assembly: Ninject" over my XAML designer preview window.

image

 

Foiled by a Blockhead

SNAGHTML57ec702Oh well the best laid plans of bugs by men: scouring the internet makes it look like this particular problem is fairly easy to fix and the result of a Windows 7 (and Vista) "feature". It seems that .zip files downloaded from the Internet are "blocked" by the OS. In typical MS anti-discoverability style you don't get any indication of this. You can unzip and move these files around to your hearts' content but the blockheadedness will follow the unzipped files. When you use these unsafe .dlls in Visual Studio it doesn't seem to cause any problems until you get to the XAML designer windows. Even then it didn't show up immediately. Once I right-clicked and Unblocked the file as shown in the image,  I took the following step:

  1. Removed the references to Ninject from my project
  2. Deleted the  unzipped Ninject folder.
  3. Unblocked the zip file.
  4. Unzipped the unblocked zip file
  5. Copied the Ninject files to my project's lib folder (optional)
  6. Created new references for Ninject.

 

So far so good.  This is really all I had to do but others complaining of similar problems indicated that they had to put a copy of the Ninject files in a path that VS automatically discovers. One such path is:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies

I don't particularly like this idea since I like to keep the version of Ninject I use coupled to the project. With any luck my problems won't reappear and the unblocking fix will suffice.

Readers' Most Popular Posts