Architecture question regarding exporting to MS Project

Question

I have a small asp.net web application that allows you to create Projects and Tasks and apply estimates, work, etc to them. I am writing an export feature to allow you to download them as an MS Project file. It's really just an XML file.

I will be writing an import feature afterwards, which allows you to reschedule Task start and stop dates, the assigned resources, etc, but not modify estimates or applied hours. That will be handled solely by the web application.

I am trying to figure out the best architecture to do this. Here are a couple ideas I'm toying with.

1. Add an ExportToProject function on my Project class, and create the XML on the fly.
2. Take the existing class structure and add XML serializer attributes, and serialize the object right into a Project file. However, this leaves me with a few questions. What happens to all of the other Properties I'm not using. How reusble would the serialized object even be if it doesn't include all of the data, and is formatted for MS Project. Can I have multiple serialize views, so to speak?
3. Create a new XmlExport class that gets serialized instead, which would be similar to the above strategy, but with an additional layer of abstraction.
4. Pirate a copy of FogBugz, install it, and move to Costa Rica.

Thanks, any help is appreciated.

Answer 1

I would use 3. or 1b. This gives you the chance to change your internal structure at any time without complications.

1b. would be: Create a Exporter Class which is able to create XMLon the fly. But do not locate that exporter in your Project class but in a separate one. This is also a additional layer of abstraction.

Answer 2

Instead of rolling your own, use MPXJ which provides a handy set of .Net as well as Java libraries. It reads all types of MS Project formats and writes to .MPX and the newer XML based file formats.

It's a robust library based on POI and will save you a lot of work.