Wednesday 19 February 2014

64-bit Considered Harmful...

Thought I should write about a problem I ran into last month in the hope that it saves someone else some heartache (or potentially someone tells me how to fix it...)

A few weeks ago, while I was searching for something else in Visual Studio's Settings, I ran across this option:
I run on 64-bit Windows, so I figured this would be a sensible option to set and switched it on. And all was good in the world.

Until I started on a new project a couple of weeks later, that is, when running it up for the first time I was puzzled to see this YSOD:
Invalid program? What the hell's that coming from? The only thing that I could immediately think of was that the last thing I did before hitting F5 was to install Ninject. I cast around for an hour or so trying assorted types of restarting processes/PCs etc, before going to Twitter...

Fran quickly replied with this:

which was the clue I needed:
And yep, as soon as I turned off 64-bit IIS Express the world righted itself...

So I'm interested to know what causes this and whether there's a way to successfully run Ninject in 64-bit code (I'm quite prepared for this to be something related to my inexperience with Ninject).

1 comment:

Doug said...

This is caused by your referencing a 32bit dll while running in 64bit more.

dependencies that are built using managed code in "Any CPU" will work fine in both modes. Binaries that are either not built using Any CPU, or maybe written using unmanaged code (c++, c etc) then you are required to reference the write version. Most .net libraries that aren't written using managed code are often installed in the GAC, allowing the .Net runtime to load the appropriate one for the version of .Net you're running.

In your case, your application must have a dependency that is 32bit only, limiting your options to:

- only ever running your application in 32bit mode.
- if you wrote the dependency, ensuring it's built in "ANY CPU" mode.
- installing both the 32bit and 64bit versions of your assembly's in the GAC and letting the .net framework decide which one to use dynamically.

Either way, this is a very fundamental problem and one that the GAC is designed to solve - you usually only face it when you're using unmanaged libraries (image manipulation, com, com wrappers).

64bit of not considered harmful - your application just needs to either decide to only use Any CPU managed assemblies, or only reference the ones that apply to the runtime environment.