Answering second follow-up question.
First of all, you should know where to persist user data. This is only one fully legitimate way: you need to use special directory create per user, or create and use sub-directory of a special directory.
You need to use
System.Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
method with the parameter. See other members of the enumeration type
Environment.SpecialFolder.LocalApplicationData
. Also, see two overloads of the method
System.Environment.GetFolderPath
.
Now when you have a directory to store your local application data, you may want to create a sub-directory specific to your application to persist the last data chosen by your user.
A second problem is how to persist data. Image files have their own load/store methods, so you can use them. You may need to integrate all your data in one file using some schema. I would highly recommend developing a special set of pure data classes (object graph) and persist it all in one file (most likely, XML). You can keep all image files as separate files, which is convenient but needs some coding effort (unique names, overwriting or keeping old files, etc.). Alternatively, you can embed each image file in your single data file (which is very bulky and not readable; with XML you will need to store binary files in Base64 fragments).
I would hardly recommend using
System.Runtime.Serialization.DataContractSerializer
. This is most non-intrusive and robust solution: you don't have to make your data serializeable or modify in any way. You only need to add attributes [
DataContract
] and [
DataMember
] attributes to your classes and members you want to persist (don't forget to specify you world-unique XML name space in each
DataContract
attribute. See
System.Runtime.Serialization.DataContractAttribute
and
System.Runtime.Serialization.DataMemberAttribute
. The serializer can even persist any object graph which is not a tree (with circular references), which is very robust. It's supportability is mainly based on the fact that if you modify anything in your data classes which is not part of contract, you persisted data will be read. If you migrate your schema incrementally (let's say, by adding new contract members and types but not removing any of the existing ones), your persisted schema will be read anyway. This is like automatic reconciliation of version upgrades. See
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datacontractserializer.aspx[
^].
—SA