Several solutions exist to persist data in .Net, but I found that when it comes to many simple user-related and application settings that none of the existing solutions fit well. We have the Microsoft Enterprise Library, but it is very large and requires complicated setup; in return you gets lots of run-time flexibility, but that is often not needed. Built-in .Net framework solutions, like app.config files rely on brittle XML serialization that lacks usability features for developers and can suffer from the well known XML serialization performance problems.
This project is an attempt to provide an eminently usable solution for storing simple settings.
I initially conceived of this project as a way to store settings necessary for skins in a .Net WinForms skinning engine I created. The first iteration used only XML for data storage, and while the read capabilities were complete, the write capabilities were never fully implemented. It was also created for the .Net Framework version 1.1.
The second iteration of this project was done recently to manage database connection strings. Also, rather than use XML data storage, I decided to use SQLite. It proved to be exceptionally useful, and I saw how creating a base library for storage would enable many uses, specifically the database connection management library and a library to automatically handle persistence of GUI settings.
As a developer, I find that I like libraries and can simply start coding with. If I have to read tons of docs and play with examples and figure out some complicated setup, than I am far less likely to use it. The overriding goal for this project is to maintain ease of and low barrier to use while providing the most useful behaviors for a specific purpose.
The plan for this project is to abstract the data store from the serialization method. Implementations will be provided for storing settings in any SQL-compliant database with a ADO.Net v2 feature-complete provider, XML files, and possibly also flat text and/or binary files (though I'm not sure there's any need, and therefore reason, to implement this). Of course, end-users (developers) would be able to easily create their own storage adapter classes to extend this behavior.
Since the first iteration I have implemented my own object-to-text and text-to-object serialization routines. The first iteration used the already available TypeConverter objects when possible, but I am reconsidering this in an effort to avoid dependence on the System.Windows.Forms.Design assembly and concerns about performance of the TypeConverter
I also see it as necessary to provide a way to attach modifiers to the conversion process to allow for services like encryption, so that is one of the high priority additions.
As a pre-alpha status, this project still requires some design decisions, significant coding, and testing. I have implemented lots of pieces of this in previous projects, but this will be a ground-up rewrite and redesign for modularity. Although, the overall project size should be quite small (< 10K lines, maybe) and given adequate available time, I hope to promote it to beta status and start on at least one of two derived projects within a month's time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Several solutions exist to persist data in .Net, but I found that when it comes to many simple user-related and application settings that none of the existing solutions fit well. We have the Microsoft Enterprise Library, but it is very large and requires complicated setup; in return you gets lots of run-time flexibility, but that is often not needed. Built-in .Net framework solutions, like app.config files rely on brittle XML serialization that lacks usability features for developers and can suffer from the well known XML serialization performance problems.
This project is an attempt to provide an eminently usable solution for storing simple settings.
I initially conceived of this project as a way to store settings necessary for skins in a .Net WinForms skinning engine I created. The first iteration used only XML for data storage, and while the read capabilities were complete, the write capabilities were never fully implemented. It was also created for the .Net Framework version 1.1.
The second iteration of this project was done recently to manage database connection strings. Also, rather than use XML data storage, I decided to use SQLite. It proved to be exceptionally useful, and I saw how creating a base library for storage would enable many uses, specifically the database connection management library and a library to automatically handle persistence of GUI settings.
As a developer, I find that I like libraries and can simply start coding with. If I have to read tons of docs and play with examples and figure out some complicated setup, than I am far less likely to use it. The overriding goal for this project is to maintain ease of and low barrier to use while providing the most useful behaviors for a specific purpose.
The plan for this project is to abstract the data store from the serialization method. Implementations will be provided for storing settings in any SQL-compliant database with a ADO.Net v2 feature-complete provider, XML files, and possibly also flat text and/or binary files (though I'm not sure there's any need, and therefore reason, to implement this). Of course, end-users (developers) would be able to easily create their own storage adapter classes to extend this behavior.
Since the first iteration I have implemented my own object-to-text and text-to-object serialization routines. The first iteration used the already available TypeConverter objects when possible, but I am reconsidering this in an effort to avoid dependence on the System.Windows.Forms.Design assembly and concerns about performance of the TypeConverter
I also see it as necessary to provide a way to attach modifiers to the conversion process to allow for services like encryption, so that is one of the high priority additions.
As a pre-alpha status, this project still requires some design decisions, significant coding, and testing. I have implemented lots of pieces of this in previous projects, but this will be a ground-up rewrite and redesign for modularity. Although, the overall project size should be quite small (< 10K lines, maybe) and given adequate available time, I hope to promote it to beta status and start on at least one of two derived projects within a month's time.