AnyCPU support - how far are we going? about hdf.pinvoke HOT 18 CLOSED

I'm a little behind the curve on "fat" or dual binaries on Windows. Does Windows support it and would a dual binary hdf5.dll help?

from hdf.pinvoke.

I would clearly prefer 2).
But I never heard of dual (native) binaries for Windows.
Up to now we realized AnyCPU applications using native DLLs by having the DLLs being named differently and P/Invoke the correct one by wrapping each call with a switch(32bit/64bit)...
Which other options exist ?

from hdf.pinvoke.

Dual / fat binaries ... hm. I think on Windows this is called WoW!? ;) No, I am not aware of such option on Windows either.

Options:

1. renaming individual dlls. Not an option if unmanaged dependancies (B) of the dll (A) are needed also. This would require recompiling / relinking (A), hence significant higher maintenance effort.
2. Installer. The official Microsoft way (presumably) is to place the 32 bit set into Windows\SysWOW64. The 64 bit dlls go into \System32\ (no typo ;) ). Potential drawbacks: admin rights needed, dll hell.
3. Subfolders: place the dlls for each platform into subfolders of your application. Let's say: /bin32, /bin64. Implement some mechanism to pick the dlls from the right subfolder at runtime. One easy way would modify the %PATH% environment variable, depending on Environment.Is64BitProcess

I once wrote a blog post about it: http://ilnumerics.net/blog/anycpu-computing-limping-platform-specific-targets-and-a-happy-deployment-end/

from hdf.pinvoke.

You guys have probably tried it already... The AnyCPU configuration builds just fine and all tests pass (I tried it on x64). Would it be premature to remove the x86 and x64 configurations?

from hdf.pinvoke.

I do not see any special reason from the .NET side to have them. I thought there might me one on the hdf side. If not I think we should rely on AnyCPU solely. The decision of the current platform is than to be made via the entry assembly and not via a compiler directive.

Regarding testing and AnyCPU: we should aim towards a setup which tests for both platforms from the start.

from hdf.pinvoke.

Agreed. I'll check your article tomorrow morning. The subfolder idea sounds reasonable.

from hdf.pinvoke.

Just added #18 where subdirectories x86 and/or x64 would hold the native DLLs.
In this case, it is guaranteed, that the path is modified before the first (managed) call to H5.open, but the user cannot change the path for her DLLs.

Is it a requirement, that the user can tweak the directory of the DLL(s) ? If so, we would need a slightly
different approach...

from hdf.pinvoke.

Great work! This is probably an issue in my environment: For the Release build, I can switch the Default Processor Architecture (in Test Settings) between X86 and X64, and everything works just fine. For Debug, I don't see any tests in X86, even when rebuilding the solution. However, all tests show up and work fine for X64. Not a big deal, and I'll do more digging later.

from hdf.pinvoke.

@gheber : I also had this problem. I needed to make sure, that the Project Build-Type equals the Solution-Build Type (in this case Any CPU). Then the Test-Exporer showed me all tests...

from hdf.pinvoke.

Bingo! Just eliminated the [x86,x64] configurations. How about moving DLL32bitPath and DLL64bitPath to Constants.cs?

from hdf.pinvoke.

If we stick to the static constructor approach, then yes, Constants.cs would be the right place for those.

from hdf.pinvoke.

Done cb2147c.

from hdf.pinvoke.

Regarding user definable subfolder names: it might be even better to have the option to specify a folder by absolute path. For ILNumerics we went this way:

Subfolder names are fixed: bin32, bin64
User has config var 'NativeDependenciesAbsolutePath': absolute path, if defined takes precedence for both platforms.

from hdf.pinvoke.

Where would that live? In app.config?

from hdf.pinvoke.

Exactly. T.b. stored in app.config. Access via System.Configuration.ConfigurationManager.AppSettings[settingsName]

from hdf.pinvoke.

A few more thoughts:

• It happened to me, that though the PATH was modified, HDF.PInvoke pulled the hdf5.dll from its installed directory (c:\program files (x86)...). I guess this is due to the load-order of windows detecting DLLs.
• As commented by hokb, we should make the path determination more reliable, and should enclose setting the PATH in try/catch
• I guess ILNumerics users don't want to have both bin86/64 and x86/64 directories, so we could adopt the naming scheme from ILNumerics (all other users won't care if it's x or bin)
• The app.config setting is a good idea.

I'm going to change the H5 static constructor to meet that things. Unfortunately I'm out of office today.

from hdf.pinvoke.

Load order: Potentially the HDF install path is also listed in %PATH% and may comes first?

Consistent naming: Sounds great! At best, even the subfolder names could be configurable. For ILNumerics it is not that big an issue anymore, since our users need to use the installer anyway. It does also install the HDF5 binaries into the corresponding Windows System folders. And for side-by-side situations we provide a binary package which includes hdf5 DLLs also. Personally, I like bin32/ bin64 better due to it being closer to the "bin/Debug" terminology. But thats arbitrary, of course.

from hdf.pinvoke.

We've come a long way

from hdf.pinvoke.