A few weeks ago, while I was searching for something else in Visual Studio's Settings, I ran across this option:
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:
With #ninject, has anyone seen this error? 'Common Language Runtime detected an invalid program.' More importantly, anyone know how 2 fixit
— Phil Pursglove (@philpursglove) January 20, 2014
Fran quickly replied with this:
@philpursglove ... yes, but I cant remember the details. Sounds a bit like a 32bit app/dll trying to reference a 64bit dll?
— Fran Hoey (@franhoey) January 20, 2014
which was the clue I needed:
@franhoey ooh, you might be onto something there - let me check... // @brightoniant
— Phil Pursglove (@philpursglove) January 20, 2014
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:
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.
Post a Comment