Comments on: Alternative to ApplicationSettings in .NET

By: eburke

eburke — Tue, 14 Feb 2012 18:27:52 +0000

@aaron I would probably do what you did and rewrite a very simple settings framework that could store different settings based on a key (such as a user ID), as well as generic settings that are not user-specific.

At startup we could then say LoadSettings(key) and pass in the user ID that we are loading up, which would load them.

I would make the serialization technology swappable so that you could use XML, JSON, binary, database, etc. That way it’s useful for mobile apps, too.

By: Aaron

Aaron — Thu, 09 Feb 2012 02:36:50 +0000

@eburke — what would you use instead if you did it all over?

By: eburke

eburke — Wed, 08 Feb 2012 15:13:34 +0000

Aaron, great post. We used the .NET settings way back in a large scale WPF project and though it was useful, we had a number of issues:

+ you can’t easily save user settings on a per-application-userid basis since they are persisted to the store for the Windows user. We had so subclass the application settings base classes to help us.

+ along with that, we had to modify the settings upgrade path to ensure we brought along all the users’ data.

+ the use of XmlSerialization under the covers caused us startup performance pain, which we got around by pre-rolling serialization DLLs, but that was more pain. :)

I definitely think the .NET core settings framework has its advantages in simple cases where you have no complex types in the settings and not many settings, but beyond that it’s hard to manage.