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

Thu Jan 25 23:56:59 GMT 2018

Hi Roger,

Sorry for not responding earlier, I guess I wasn't subscribed to the list so
I didn't see your response in my email.  Had to find it manually via the
archive list.  Following your advice, I tried:

To give some context, my goal is to create a C# wrapper around ome-files (or
at least certain functionality in ome-files), so that I can read/write
OME-TIFF files.  What I have done so far is:
1.       Download OME Files 0.5.0
<https://www.openmicroscopy.org/ome-files/downloads/>  (Windows VC14 64-bit,
self-contained super build) into a directory "C:\Users\...\Documents\Visual
Studio 2015\Projects\OMEFilesSharp\External".
2.       Created a C++ DLL project in Visual Studio 2015 (hence the
"OMEFiles.dll") that effectively creates a wrapper around OMETIFFReader and
OMETIFFWriter, and VariantPixelBuffer to get basic functionality working.  I
followed the instructions here
<https://www.openmicroscopy.org/community/viewtopic.php?f=13&t=8233&p=18005&
hilit=ome+files+tutorial#p18005>  for getting the project to build properly.
3.       The reason that the C++ DLL is necessary is that I needed to make
the API compatible with C types, so that I could use CppSharp
<https://github.com/mono/CppSharp>  to generate automatic C# bindings.

I tried to following your instructions, and did the following:

4.       Adding ome::files::register_module_paths(); before I called
setId(.).  This resulted in the same stack trace and exceptions that I
relayed before.
5.       I set the OME_FILES_HOME environment variable to the root directory
("C:\Users\...\Documents\Visual Studio
2015\Projects\OMEFilesSharp\External\ome-files"), and to the binary
sub-directory (""C:\Users\...\Documents\Visual Studio
2015\Projects\OMEFilesSharp\External\ome-files\bin"), along with adding the
ome::files::register_module_paths() call, but that resulted in the same
stack trace and exceptions that I relayed before too.
6.       I did a search for "ome-model.xsl" and ""ome-model.xsd" and found
neither in the downloaded super build.

To be honest, C++ is not my strong suit.  If there's a better way to get set
up in Windows, I'm all ears.

Thanks,
Dennis

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#L2
50
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

Dennis Ai

Senior Strategic Advisor, SRI Biosciences

SRI International

333 Ravenswood Ave

Menlo Park, CA 94025

(847) 440-4765

SRI BiosciencesT

A DIVISION OF SRI INTERNATIONAL

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20180125/898aaec3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5112 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20180125/898aaec3/attachment.p7s>