Hi, I am using boost (1.40) serialization on Windows (VS 2008) to serialize a complex hierarchy of classes. My application is composed of different modules, each having its own serialization library. I have a Core library, with a CoreSerialization library, that defines a bunch of classes and base data types; I also have a Vehicle library, with a separate VehicleSerialization library, the defines some other classes with base classes in Core and that also use some user data types defined in Core. Using static libraries, everything saves and loads perfectly. We recently switched to using DLLs. When loading and saving with an application that only uses core (as Dlls) everything serializes perfectly. We can load files that were generated by an older application (using static libraries), save them and load them back. If the application also uses the Vehicle libraries, it can load older files (generated using static libraries), save them, but fails to load them back. The difference between the files generated with a DLL application and a static link application, lies in the tracking of certain classes. Since the serialization is split between 2 DLLs, the tracking level (by default selectively) will actually depends on what classes are serialized in the DLL and may be different in different DLLs. This seems to be cause by the various singleton that are created, notably pointer_oserializer<T> and oserializer<T>. In a statically linked application, there is only one instance on those singleton, in a DLL linked application, there is one instance of the singleton for each DLL. I've also noticed that in my Core DLL, for certain type, there are both notably pointer_oserializer<T> and oserializer<T>, while in the Vehicle DLL, there is only notably oserializer<T>, hence the difference in tracking level. There is an easy fix here, not to use selective tracking but track always or never, explicitly. But still, there seems to be some data that needs to be shared across various serialization DLLs. I am a bit worry about some other bugs popping out relative to it. Has this bug ever been found? It may be a side effect of putting serialization code in DLLs, the documentation on that subject is a bit sparse. Thanks for any inputs Guy -- Guy Prémont, D.Sc. Architecte logiciel senior / Senior software architect CM Labs Simulations Inc. blocked::http://www.cm-labs.com/ http://www.cm-labs.com/ Tel. 514-287-1166 ext. 237