TL;DR: If 3rd party assemblies unnecessarily target an inconvenient bitness, either convince the 3rd party of AnyCpu or force AnyCpu on the assembly yourself (with permission from legal).
The situation was as follows: we had a process that was happily using a 32-bit 3rd party assembly to use a corresponding 3rd party product.
And for a while, it was good.
Then the 3rd party decided to switch to 64 bit and release new versions of their assembly as 64-bit only.
Our process needed to be compatible with old and new versions of the 3rd party product, i. e. both 32-bit and 64-bit versions of the assembly.
Since the process needed to load the 3rd party assembly itself, it was not feasible to build it as AnyCpu (which would have been a solution for a plugin that does not load the 3rd party assembly itself).
Having both a 32 bit version and a 64 bit version of our process would have caused both developing costs and a considerable increase in runtime complexity.
It was not feasible.
What to do?
Check if assembly bitness is really necessary
At first, I checked if there was any real reason for the 3rd party assembly to have a bitness at all.
Tools like dotPeek will show relevant metadata for the assembly:
The set ILOnly flag tells us that the assembly itself only contains managed code and is thus bit-agnostic.
So far, so good.
Next, we check the assembly references.
We can see that the assembly references no native assemblies.
Furthermore, it only references assemblies from the .NET Framework.
Those will be available on the target system in any (if any) bitness.
Thus, its assembly references also do not require it to have any specific bitness.
In conclusion, the 3rd party assembly does not need a specific bitness to work.
It just was unnecessarily built targeting a 64-bit runtime.
It can just as well be built as AnyCpu.
Either convince the 3rd party
In our case we were able to convince the 3rd party to change their build process and provide AnyCpu assemblies instead of the 64-bit ones.
We were able to keep our 32-bit library and did not have to do anything.
Or force the bitness yourself
But what if the 3rd party had continued to publish a 64-bit assembly?
We already established that there is no reason for the assembly to target any bitness.
We could have — in theory — decompiled it using ildasm and then recompiled it as AnyCpu using ilasm, like this:
ildasm ThirdPartyAssembly.dll /out=ildasmfile.il ilasm.exe /dll ildasmfile.il
I write “in theory”, because recompiling a third party assembly may be in violation of the contract with the 3rd party.
We would have had to get written permission from the 3rd party and would have consulted our legal department before going forward.
Lucky for us, that was not necessary, but it would have been the next-best solution, also requiring no development work.
