[xsd-users] Issue with VS2017

[rjl at third-monday.com]

Ack!  Spoke tooooo soon.  Now I'm getting the following:

error C2872: 'DOMDocument': ambiguous symbol

I see some other messages in this mailing list that says this is fixed 
in a pre-release binary (4.1.0).

For now, I'll move back to XSD 3.3.0.

r

On 2019-03-29 11:48, rjl at third-monday.com wrote:
> This morning's updates:
> 
> 1) I upgraded to XSD 4.0.0 - no need to upgrade Xerces (from 3.1.1) as
> far as I can tell.
> 
> 2) I implemented the updates to the XML code generation as described
> in the 1st note below (added ' --export-xml-schema --hxx-prologue
> "\#include \"model/util/Defines.h\"" --export-symbol MODEL_EXPORTAPI)
> to the xmlSchema.h generation.
> 
> 3) Pushed on the 'static debug' build for the model n engine libraries
> to make sure they were, indeed, 'debug'-worthy builds.
> 
> 4) Figgered out how to make my app programs depend on the libraries
> using Qt qmake variables so they're relinked should any of the
> libraries change.
> 
> Everything seems to work.  Point '2)' really isn't needed now as I'm
> building my libs statically.
> 
> I think I can enter the weekend with something accomplished!  This has
> been bugging me for days....
> 
> Thanks again for the explanation about the VS changes w.r.t. 
> 'std::string'.
> 
> r
> 
> On 2019-03-29 09:57, rjl at third-monday.com wrote:
>> Thanks for the response.
>> 
>> Yes, I can upgrade to the latest XSD.  Will that require an upgrade to
>> Xerces, as well?
>> 
>> All of the XSD Tree generated code is linked into the 'model'
>> DLL/library.  The 'engine' DLL/library and all of the apps use those
>> structures from the model library.
>> 
>> VS2017 complains mightly about classes in a DLL library with
>> 'dllexport' that contain 'std::string' attributes (e.g., 'private:
>> std::string _name;' in the class).
>> 
>> That's what that 'NamedObject' class looks like as I referenced in my
>> original msg.
>> 
>> I like using DLLs for development because they simplify building as
>> I'm working - no need to re-link apps when some lines in a library
>> changed.
>> 
>> However, I think I may have made progress by doing away with DLLs
>> during development.  I think I can build 'static debug' libraries and
>> apps.  That'll increase development time (e.g,. must wait for apps to
>> re-link) but it'll save the rest of the hair on my head as I move
>> forward.
>> 
>> I'll let you know what I find after upgrading and reading the
>> discussions listed below.
>> 
>> Thanks again,
>> r
>> 
>> On 2019-03-29 09:32, Boris Kolpackov wrote:
>>> rjl at third-monday.com <rjl at third-monday.com> writes:
>>> 
>>>> I'm using XSD 3.3.0 and Xerces 3.1 on Windows.
>>>> 
>>>> [...]
>>>> 
>>>> I'm migrating to VS2017 [...]
>>> 
>>> As a first step, I would suggest that you upgrade to at least XSD 
>>> 4.0.0,
>>> or even to the next version pre-release:
>>> 
>>> https://codesynthesis.com/~boris/tmp/xsd/4.1.0.a11/
>>> 
>>> 
>>>> I'm getting some rather strange LNK2005 errors on std::string 
>>>> methods
>>>> and operators.
>>> 
>>> In a nutshell, the reason for these errors is:
>>> 
>>> 1. XSD implements certain basic types by deriving from std::string
>>>    (because they have the 'is-a' relationship to xsd:string in XML
>>>    Schema).
>>> 
>>> 2. MSVC automatically applies the dllimport/dllexport of a derived
>>>    class to a base class that doesn't have its own (and which
>>>    std::string doesn't).
>>> 
>>> 3. In MSVC 2017 (but not 2008) the implementation of std::string
>>>    now contains non-inline member functions (or inline ones that
>>>    the compiler chooses not to inline in Debug).
>>> 
>>> 4. If you have two or more DLLs that include the generated code,
>>>    then you may end up with duplicate std::string symbols because
>>>    they both export them (see 2 above).
>>> 
>>> There are various ways to solve this problem with the easiest
>>> being to place all the generated code into a single DLL. For
>>> other ways see this earlier post:
>>> 
>>> http://www.codesynthesis.com/pipermail/xsd-users/2010-September/003011.html
>>> 
>>> With this email containing more analysis/information on the problem:
>>> 
>>> http://www.codesynthesis.com/pipermail/xsd-users/2010-September/003019.html