All,
We use an in-house .Net wrapper for Hdf5. At the time we wanted such a
thing, the HdfDotNet lib looked stalled, so we rolled our own. Lately,
we've noticed some instability among our Windows users that may be due
to errors in the way we wrapped the "unmanaged" code. Most of the
development of the wrapper was done on Linux, the Windows users have
pretty much taken what they've got, and up to now this seems to have
worked. As they start to use more of the features in the .Net library,
it is possible they have exposed errors.
My question, admittedly rather vague, is whether there are fundamental
differences in the Windows 64-bit Hdf library as compared to the Linux
64-bit library that may lead to instability in interop calls? The kind
of thing I am thinking of is sizes of constants (32-bit on one system,
64 on another), or perhaps values of constants (we hardwire a number
of datatype primitives that perhaps we should not). We have a fairly
extensive test suite around the library, so it is probably something
subtle.
I've noticed a fair amount of recent activity here on the list
regarding Hdf via .Net, so I thought I would see if someone here had
an idea of where potential gotcha's might be lurking. I realize there
are many ways to screw this up, and I have given precious little
information to go on. If anyone would like to discuss details, or
discuss more generally how we went about wrappng the Hdf library I'd
be happy to, though perhaps it would be better done off list (or not,
doesn't matter to me).
Thanks for any help,
Matt