Reputation:
In one project we have a dependency on a legacy system and its .Net assembly which is delivered as a 'x86' and they do not provide a 'Any CPU' and/or 64bit one. Now the project itself juggles with lots of data and we hit the limitations we have with a forced x86 on the whole project due to that one assembly (if we used 64bit/any cpu it would raise a BadImageFormatException once that x86 is loaded on a 64bit machine).
Now is there a (workaround)way to use a x86 assembly in a 64bit .net host app? That tiny dependency on that x86 assembly makes and keeps 99% of the project heavily limited.
Upvotes: 1
Views: 405
Reputation: 942267
You can change this bitness of the assembly with the Corflags.exe utility. Use the Visual Studio Command Prompt shortcut, then:
corflags /32bit- whateverthename.dll
It isn't terribly likely to work, forcing the x86 target is often done because an assembly has a dependency on unmanaged code that's only available in 32-bit. Typically a COM server.
In that case, your only other workaround is to run the assembly in its own process. You'll need to write a little hosting program whose Platform Target you force to x86. You'll need to communicate with the main program using one of the process interop mechanisms supported by .NET. Sockets, named pipes, .NET Remoting, WCF. Beware that this is not especially fast and it will be brittle when the code commonly dies from unhandled exceptions.
Upvotes: 1
Reputation: 19107
You could ask the creators of the legacy system in question to re-compile their assembly for you.
If it is owned by your company, or the company who made it doesn't help (or if you don't care) you could easily disassembe it with Reflector, and with a bit of work, recompile for any cpu or x64.
Upvotes: 0