By Scott Johnston – 9/4/2019
Where to store Data for a Windows Application?
When considering application design we often have two distinct aspects to the application data involved. Firstly, there are data related to application control and back end storage, i.e. configuration settings and data. Secondly, are data outputs intended for consumption by the user, i.e. reports, etc.
Windows has a variety of system special folders to support application needs. In .Net, the paths to these folders are available via enumerated constants in the Environment.SpecialFolder namespace. I have created and used subdirectories under ApplicationData, and MyDocumnets but there are many others. I use ApplicationData for backend, and MyDocuments for user consumed files. The thinking here was to isolate the user from the nuts & bolts data, and only expose them the output user data by putting that in a separate MyDocuments folder. They don’t even need to know that the ApplicationData subfolders exist.
For those not familiar, ChronoBeans is a time tracking and invoice generation application for one-person business. A key feature is that the application is installed, and runs, local on windows using a SQL LocalDB. This is quite different to most internet-based applications common today. The real differentiator, besides not needing constant internet connectivity, is that all data is intended to be stored locally, not in the cloud. The output invoices and logs (and backups) generated by the application are output to a ChronoBeans folder under Environment.SpecialFolder.MyDocuments.
Thinking for this post all started with a support request I recently received. A ChronoBeans user had run into an error when trying to do a backup. I believe that at some point, after ChronoBeans was installed and in-use, the user inadvertently switched their Documents folder from local (C:), to OneDrive. ChronoBeans could no longer find the backup directory as the mapping had not originally been created on OneDrive. The fix was simply to create the missing /ChronoBeans/Backup folder. This got me thinking about whether I was doing the right thing storing output application data files under the MyDocuments special folder reference. I also dove further into the Environment.SpecialFolder for options.
Result? I’ve reassessed my thoughts and will now use ApplicationData (or LocalApplicationData) for all files used or created by the application. I’ll introduce this during a future upgrade to ChronoBeans. There will still be a separate folders for Invoices & Logs, and Backups, but these will under the ChronoBeans ApplicationData structure, and partially exposed to the user.
My reasoning is that MyDocuments, is intended for the users personal use (the alternative enumeration is in fact Environment.SpecialFolder.Personal), and users should be free to move/delete/rename anything in that path without it impacting the core functionality of any application.
But I’d be interested in your opinion too. Where should application data reside, especially in light of the transition from C: to OneDrive.
(more Environment.SpecialFolder options can be found here: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=netframework-4.8 )