[xsd-users] Parsing exception with XSD hierarchy - No type information available for a type

[Boris Kolpackov]

Hi Jürgen,

Jürgen Waser <jwaser at vrvis.at> writes:

> In our case, it works without the --export-symbol option in the plugin  
> dlls because we do not include the generated plugin schema classes  
> outside the plugin.

Ok, I think this could work.


> We have a theory why this could be going wrong. The executable (using  
> --import-maps) creates the factory map at the time of static  
> initialization. In this map, the TestSettings are registered. However,  
> at this point, base.dll has been loaded but it's static initialization  
> has not yet happened. Since base.dll has --export-maps specified, it  
> creates its own factory. This second factory is used when parsing but it  
> lacks the TestSettings entry. Could that be the problem?

I don't think this is what happens. The polymorphic maps use the 
initialization technique that does not depend on the order of 
initialization of individual object files within the same
executable or across multiple DLLs. In the end each map is
represented as a pointer to the map class and is static-initialized
to 0. This works across multiple DLLs if this pointer is defined
and exported from the 'root' DLL (that's what the --export-maps
option does) and is imported by everybody else (--import-maps).
Things break if you have, for example, a DLL and an executable that
both have such a pointer.  

I suggest that you double check that every single schema in your 
project, except for the ones in the 'root' DLL, is compiled with 
the --import-maps option. This problem can be caused by a single
"stray" schema that is not compiled with this option. Perhaps you
have another schema somewhere, unrelated to your plugin architecture,
that you compile differently?

If none of this helps, you can try to analyze your DLLs, executables
and individual object files with the dumpbin[1] utility that comes
with Visual Studio. It has a number of options that show which
symbols are defined by an executable as well as which ones are
exported/imported from DLLs. The idea here is to make sure that
the map pointer mentioned above is exported from the 'root' DLL
and is imported by everyone else and none of the executables
define their own copies of these pointers.   

[1] http://support.microsoft.com/kb/177429

Boris