You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the library is used in a project compiled with AnyCPU which is compiled on a x64 bit system the applications fails with a BadImageFormatException on 32bit PC as the Yubico.NativeShims.dll in the build output folder is the x64 version. The same thing happens when setting the Prefer32Bit flag.
The Yubico.NativeShims.targets file in the Yubico.NativeShims nuget package copies the file over depending of the architecture of the build system.
Expected Behavior
When a project is build with AnyCPU the build output should contain the x86 and the x64 bit of the dll.
And the dll to load should be detected on runtime. For example by using the LoadLibrary method of kernel32.dll. For the moment we worked around the issue with copying both dlls to the build output and then with a code similar to this:
romerod
changed the title
[BUG] BadImageFormatException when using the library in a .NET 4.7 project compiled with AnyCPU on 32bit PC.
[BUG] BadImageFormatException when using the library in a .NET 4.7 project, compiled on a 64bit PC with AnyCPU and executed on 32bit PC.
Sep 27, 2024
Is there an existing issue for this?
Current Behavior
When the library is used in a project compiled with AnyCPU which is compiled on a x64 bit system the applications fails with a BadImageFormatException on 32bit PC as the Yubico.NativeShims.dll in the build output folder is the x64 version. The same thing happens when setting the Prefer32Bit flag.
The Yubico.NativeShims.targets file in the Yubico.NativeShims nuget package copies the file over depending of the architecture of the build system.
Expected Behavior
When a project is build with AnyCPU the build output should contain the x86 and the x64 bit of the dll.
And the dll to load should be detected on runtime. For example by using the LoadLibrary method of kernel32.dll. For the moment we worked around the issue with copying both dlls to the build output and then with a code similar to this:
before calling any of the library methods.
Steps To Reproduce
Can also be reproduced by setting the
<Prefer32Bit>true</Prefer32Bit>
instead of running it on 32Bit system.Version
1.11.0
Version
5.4.3
Anything else?
No response
The text was updated successfully, but these errors were encountered: