[ome-devel] [ome-files] Getting Exceptions When Opening Files for setId(...)

[Roger Leigh]

On 25/01/18 02:57, Dennis Ai wrote:
> Upon some further investigation, it looks like I pasted the wrong stack
> trace and exception.  This is the correct one.

Dear Dennis,

I think your open method is fine, and the path is fine.  You should be
able to pass a const char * or const std::string& directly to the setId
method, by the way.  It will be implicitly converted to a
filesystem::path.  (This will eventually become std::filesystem::path
once we add support for C++17.).  Using either "\\" or "/" as a path
separator should work equally well.

If you catch and log the exception's what() output it should tell you
exactly what failed.  I suspect it's throwing here:

 >        OMEFiles.dll!ome::common::module_runtime_path(class
 > std::basic_string<char,struct std::char_traits<char>,class
 > std::allocator<char> > const &)       Unknown

https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/module.cpp#L486

Given the stacktrace, I think it's trying to load the OME-XML schema or
transforms, and failing to find them.  The what() output will tell you
which it is.


There are a few potential causes here, which I'll try to outline.

1) The module-specific paths are registered here during static
initialisation.  When building a shared library on Unix, this happens
automatically.  When building a static library the initialisation
functions can be elided by the linker; there are methods in each
component such as ome::files::register_module_paths() which will trigger
the registration by hand [and also prevents the elision as a
side-effect].  Note that static initialisation hasn't been well tested
on Windows, because we don't yet support building of DLLs, and there may
be improvements to be made in that code.

- you could try adding an explicit call to
ome::files::register_module_paths() before calling .setId or any other
ome-files functions.

2) The installation root might not be detected properly.  If you've
configured and installed into a defined prefix (CMAKE_INSTALL_PREFIX),
that will be the default place to search.  Otherwise, it can introspect
the DLL to find out where it's located.  See
https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/module.h#L250
and module_path().  These can all be overridden with the OME_FILES_HOME
environment variable, or other more specific variables which are
detailed here:
http://docs.openmicroscopy.org/ome-files-cpp/0.5.0/ome-files/manual/html/ome-files-env.html#environment
  As for (1) I would note that because we don't currently support
building DLLs, the GetModuleHandleExW/GetModuleFileNameW logic might
need some improvement, since it's not been used or supported in
practice.  You shouldn't need to use those environment variables for
production use, but they might be useful for diagnosing what's wrong.

- Try using OME_FILES_HOME / OME_XML_SCHEMADIR / OME_XML_TRANSFORMDIR to
explicitly tell it where the datafiles are and bypass the path autodetection
- If you add some logging to the steps in module_runtime_path() it
should show which part(s) are failing and what it thinks the data
directory paths are (which could potentially be wrong)

3) If all of the above are working, it might be that the directory it's
looking for doesn't exist, so it can't load the needed datafiles.  Does
your application have the ome-model XSD and XSL files present in the
installation directory?


Finally, I was very interested to see "OMEFiles.dll" in your stacktrace.
  I would be very interested to know how that was created, and if you
used our standard CMake builds in each component, or your did your own
thing.  We would very much like to support and provide DLLs for the
various components on Windows for ome-common, ome-model and ome-files
etc., but I was under the impression that some of the STL templated
containers and other template usage precluded passing them across DLL
boundaries, several of which are used in our public interfaces.
However, I'm not a DLL expert.  If there's anything we can do to support
building of DLLs, then we would be very welcoming of any suggestions you
have for doing so.  This is why our builds of OME-Files currently only
provide static libraries on Windows, but I would love to remove this
limitation.


Kind regards,
Roger Leigh

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
College of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: (01382) 386364

The University of Dundee is a registered Scottish Charity, No: SC015096