Packaging - BadImageFormatException when running in 32 Bit mode

[andrekoehler]

I get a

System.BadImageFormatException
HResult=0x8007000B
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=Urho
StackTrace:
at Urho.Context.Context_Context()
at Urho.Context..ctor()
at Urho.Application..ctor(ApplicationOptions options)
at the first line of my code that uses Urho

This only occurs when running with the x86 build or the AnyCPU+Prefer32 build.

The reason for this lies in here:

urho/Nuget/Desktop/UrhoSharp.targets

Lines 7 to 14 in db5206b

	<None Include="$(MSBuildThisFileDirectory)\..\..\native\Win64\mono-urho.dll">
	<Link>mono-urho.dll</Link>
	<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
	</None>
	<None Include="$(MSBuildThisFileDirectory)\..\..\native\Win32\mono-urho.dll">
	<Link>mono-urho_32bit.dll</Link>
	<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
	</None>

And the Platform Invoke code uses a compile time constant instead of deciding the name of the DLL at runtime:

urho/Bindings/Portable/Consts.cs

Lines 6 to 9 in 426eb85

	internal static class Consts
	{
	#if DESKTOP
	public const string NativeImport = "mono-urho";

It would be great, if the UrhoSharp wrapper could decide at runtime which architecture of the native DLL to load.

[andrekoehler]

Here is a workaround for the case where you want to use UrhoSharp in a 32 bit only application:
Add the following lines in the project properties of your C# project under "Build Events" -> "Post-build event command line:"

DEL "$(TargetDir)mono-urho.dll"
RENAME "$(TargetDir)mono-urho_32bit.dll" "mono-urho.dll"

[migueldeicaza]

This is generally a problem with .NET that has a very inflexible system for loading libraries.

There are some proposals to look into this:

https://github.com/dotnet/coreclr/issues/12707

So at this point, I would just wait for this to be fixed at the core.

[EgorBo]

Usually on Windows developers solve this problem by ugly MSBuild hacks like "post-build tasks" 🙁

[andrekoehler]

You could also use a small hack like this one: https://stackoverflow.com/a/30646096/2955654

[EgorBo]

@andrekoehler perfect, thanks, it will also allow to switch between OpenGL and DirectX easily via ApplicationOptions

[dotMorten]

I have a much better way to handle this. The trick is to deploy both the x64 and x86 DLL in sub-folders, and make the two DLLs named the same. You then call SetDllDirectory based on the running architecture. You can see how I do that here:
https://github.com/dotMorten/IoTivityDotNet/blob/master/src/IotivityDotNet.Interop/Init.cs

Then in the nuget package you add a .targets file that xcopy deploys the correct one or both based on your anycpu/prefer32bit/x86/x64 build settings. You can see an example of my targets file here:
https://github.com/dotMorten/IoTivityDotNet/blob/master/src/IotivityDotNet.Interop/build/net452/dotMorten.IoTivity.Interop.targets

This approach allows users to create AnyCPU apps and run the same app on both x86 and x64 platforms.