tags:

views:

76

answers:

2

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.

A: 

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.

Venemo
Depending on what that library does it may not even be possible to use 64-bit, though
Joey
Unfortunately this is not an option. The 3rd Party vendor refuses to provide an updated assembly and as strange as the underlying architecture looks, I would rather not disassemble and recompile. I'm looking for an 'official' way
Jörg B.
The library does a rather odd "x86 .net assembly" > COM > java > corba path. Basically the .net assembly is a just a wrapper around the actual library/api that is delivered as a java .jar and the .net process starts a java process and they both talk over com with each other and the java part does the actual client/server communication. I can't comment on that 'architecture' but since so many cornerstones are included I'd rather not touch it. Leave alone official support.
Jörg B.
+1  A: 

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.

Hans Passant
Thanks for the corflags tip! Writing a hosting / proxy server was what I had in mind as ultimate fall back, too, but not one I really anticipated due to the sheer volume of conversion necessary.
Jörg B.