Prior to these changes, I was always deploying the x86 version of onigwrap.dll under Windows environments, which caused issues. For instance, under Visual Studio, running the demo project required the x64 version of the library, whereas the unit test runtime required the x86 version.
To address this, I have made changes to the way the native library is accessed.
Firstly, I have renamed the x86 version of the library to onigwrap-x86.dll, and the x64 version to onigwrap-x64.dll. This naming convention will enable developers to identify the appropriate library version to be used based on the runtime.
Secondly, I have created separate instances of Interop classes, namely InteropWin32, InteropWin64, and InteropUnix. All these classes are wrapped under an interface IOnigInterop, which is initialized statically based on the platform and the runtime. This will ensure that the correct Interop class is used to load the respective native library.
Prior to these changes, I was always deploying the
x86version ofonigwrap.dllunder Windows environments, which caused issues. For instance, under Visual Studio, running the demo project required thex64version of the library, whereas the unit test runtime required thex86version.To address this, I have made changes to the way the native library is accessed.
Firstly, I have renamed the
x86version of the library toonigwrap-x86.dll, and the x64 version toonigwrap-x64.dll. This naming convention will enable developers to identify the appropriate library version to be used based on the runtime.Secondly, I have created separate instances of Interop classes, namely
InteropWin32,InteropWin64, andInteropUnix. All these classes are wrapped under an interfaceIOnigInterop, which is initialized statically based on the platform and the runtime. This will ensure that the correct Interop class is used to load the respective native library.Fixes #51