I agree, the DLL case seems to be the most useful. I double-checked and the test that comes closest to this scenario (test_dll_exported.vcproj) is using template-based definitions of the serialization functions. The test project illustrating my question is very similar to test_dll_exported.vcproj but it doesn't use any template definition. Please find it attached to this message. Just let me know if there is any other way I can help. Thank you, Bogdan

...

Thank you for your reply. The serialization functions are not inline: their bodies are defined inside the DLL.

I did the following experiments:

- I skipped manually the registration exception in the debugger and it turns out that all the serialized classes have their serializers registered twice. - if in the main function I do not call serialize/deserialize, the program runs ok; I agree with you, the program doesn't do anything but it proves that the registration is triggered by the actual usage of the serialization functionality and not by any eventual inline.

I am under the impression I followed all the directions in the documentation and yet I keep hitting that glitch.

I thought I included demos and tests to implement this very scenario. Look through the demos/tests and double check this. If there is a demo/test that works and emulates your situation maybe we're done. If not, perhaps you might want to modify the demo/test so it fails and then send it to me.

Robert Ramey

...

Thank you,

Bogdan

PS. As for the case where boost serialization links as a static inside a user DLL, it fails, indeed, due to the compile stripping out code. Is there a workaround for this you would suggest?

The serialization library uses boost/serialization/force_include.hpp to implement this. This might be made to work but is a compiler dependent hack. I would prefer we get to the bottom of why the DLL situation doesn't work as I would expect.

Robert Ramey