Application Data - The WinForms Cookies

The application data folder (%USERPROFILE%\Local Settings\Application Data) is guaranteed to be read-writable and furthermore, it is user specific. Compounded by the ease of use via the IsolatedStorage class in the .NET framework, this sounds like the ideal place to save all your user settings doesn't it?

It is. Just an example, Microsoft Visual Studio caches all your project assemblies there. If Microsoft does it, it has to be correct, right? Yes and no.

While this is one of the most convenient storage locations, there is, however, the issue of - when and how do we remove the data we have stored in app data folder?

Microsoft Visual Studio suffers from this exact problem with its project assemblies - it really shouldn't, but it does. And when that happens, it will drive you nuts. What am I talking about? Here goes.

When a solution is loaded, all the referenced assemblies which have their property "Copy Local" enabled will be cached in %USERPROFILE%\Local Settings\Application Data\Microsoft\VisualStudio\\ProjectAssemblies\. The next time you open the solution, Visual Studio will check the cache for the assemblies and will not recopy the assemblies even if they are out of date. This happens very frequently if you use any third party components / controls with designer support - every time you upgrade to a newer version, your solution breaks as you now have an older version of the assembly in your cache, while the designer expects to work with the version it gets installed with.

The problem arises simply because Visual Studio does not remove the cache when the user closes the solution. It really should not retain the cached assemblies simply because these files will then remain indefinitely in your application data. Imagine every single time you create a little application to test out the behavior of certain components / controls (be it built-in or third party), VS caches all the assemblies. If Microsoft insist on not deleting the files, at least have the courtesy of doing it properly - this is analogous to Intel's Nehalem processor (the successor of Core processor) using stale data from its L3 cache!

In the case of VS, the solution is simple - recopy the assemblies each time the solution is reloaded.

Users of IsolatedStorage though, have a bit more problem in that if we use IsolatedStorage for application settings, when do we clean it up? When the software is uninstalled? Seems like quite a hassle - in the uninstaller, figure out which subfolder is for the application we have installed, enumerate through all the user profiles and delete the data files.

OK. Before we go any further, how do we figure out the subfolder of which our application has used for IsolatedStorage? Is this relative location even the same for all the users? Where's the documentation for this?

Too much hassle means one thing - most developers / companies will simply leave the files in IsolatedStorage after the application gets uninstalled. I suppose that's a bit better than leaving the data in your Windows registry back in the old days.