I have a reasonably large data feed that must be preprocessed to reduce workload on the rendering web server, and this is currently accomplished through binary serialization. The serialization app (which is run on a job server) holds a reference to the render-time class, present on both the job server and the render servers. The class being serialized implements ISerializable fully--all types are manually serialized; little object graph tracing is done at runtime by the CLR.
The console app performs these steps: 1. reads in the various feed files 2. cross-indexes the data (creates multiple hashes on the data) 3. creates a Manager object based upon the feed & indices. The Manager object is defined in the render-time DLL. 4. serializes the Manager object to disk The render-time DLL holds an ASP.NET cache dependency to the serialized file; any changes to that file trigger a deserialization of the file to a Manager object, which is stored in the ASP.NET cache. We recently started signing our assemblies (both the console app and the DLL are signed), however, and this has thrown a wrench into the serialization/deserialization routine, vv. the serialized object now is very sensitive to assembly version changes. If I serialize in 1.0.101.25969, I must also deserialize in 1.0.101.25969. This is a headache, because every time someone wants to rebuild their render-time project they must also now regenerate the serialized data, and all of the old serialized data cannot be reused/repurposed. Is there a way to make the deserializing assembly less sensitive to the version of the serialized object? TIA, Peter Rosser You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
