tag:blogger.com,1999:blog-1902158034220893892.post5815614254860180016..comments2023-09-01T11:04:47.569+01:00Comments on Diary of a DotNet Developer: 64-bit Considered Harmful...Philhttp://www.blogger.com/profile/03175106028217224674noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-1902158034220893892.post-28547758061041992922014-02-19T12:09:36.818+00:002014-02-19T12:09:36.818+00:00This is caused by your referencing a 32bit dll whi...This is caused by your referencing a 32bit dll while running in 64bit more.<br /><br />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.<br /><br />In your case, your application must have a dependency that is 32bit only, limiting your options to:<br /><br />- only ever running your application in 32bit mode.<br />- if you wrote the dependency, ensuring it's built in "ANY CPU" mode.<br />- 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.<br /><br />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).<br /><br />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.Doughttps://www.blogger.com/profile/11500853279315228852noreply@blogger.com