I am making an application that persists several different user settings. The way I have done it is just to serialize my collections (with the settings in them) to XML files.
As they are changed I update the saved file so that when the user runs again, the settings are saved.
As I get going with this style of persistence, I am finding that I have a lot of XML files.
Is this normal? Is it ok to litter my installed directory with configuration xmls files?
Is there a way to hide these files? Maybe a trick to save them as a resource under one file name?
This is not a really urgent issue. It does not really bug me to have the XML files there, but I thought I would ask.
I am using C# and VS 2008.
Can you not at least put them in their own folder? "/App_Data" for example? Beyond that... If you are getting a lot of files, what are the chances of being able to switch to a database? (SQLLite or something along those lines)
Related
Where does VSCode store its Most Recently Used (MRU) list of .NET projects and solutions on Windows?
And also is there some open source code to fetch VSCode's MRUs?
I scanned all files in this dir (recursive) C:\Users\pat\AppData\Roaming\Code with no luck
For you it should be in C:\Users\pat\AppData\Roaming\Code\User\globalStorage\state.vscdb; this file is an SQLite database and you can look around for tools that open this kind of file (because it won't be readable as plain text) to see what's inside and decide whether you can sync it across machines (if that's what you're after).
Also reference this answer, there's very useful stuff over there.
Edit: Thanks this is indeed the file I was looking for.
It can be read with the tool SQLitebrowser.
I didn't easily found a .NET library to read the state.vscdb file + we are very reluctant in embedding a whole library in our product for a small feature.
Hopefully state.vscdb contains the MRU file list in clear textual JSON.
So what I did is just open this file as text, and locate the JSON and read it. Clearly it is ugly but JSON shouldn't be crypted anytime soon in such file and if it fails one day, this feature is not critical for us, just a convenient helper for the user.
The JSON to locate looks like:
{"entries":[
{"fileUri":"file:///c%3A/Dir/treeItem.ts"},
{"fileUri":"file:///c%3A/Dir/YourSolution.sln"},
...
When I wanted to export the model I was working on as a Java application, I encountered an error regarding the databases I loaded into the model. When I said OK to the error, I realized that all the files in the folder I wanted to create the Java application were deleted. That folder was desktop by the way.
Right now all the files (i mean all of them!) on my desktop are deleted and they don't even show up in the recycle bin. How are we going to solve this situation? How can AnyLogic have the authority to delete all files in that folder? How is this authority not shared with me and not warned beforehand?
When you work with software in general, you need to have a version control in place that will allow you to recover your information. These problems occur, and if AnyLogic has access to your computer it's because you grant the permission and it needs the permission. If you make your desktop your project folder, then i would say you are to blame.. why would you do that...
Using GIT as Ben commented, is always a good idea... but it requires you to be conscious about when you commit a version.
What I do, is I use dropbox and all my projects are done in a dropbox folder... the good thing is that dropbox always saves automatically all the files on the folder... this has saved my life multiple times and I suggest you to do something like that in the future. So on one hand you have the autosaving features, which is useful, but sometimes you erase everything by mistake, and the autosave is not useful, but dropbox saves no matter what.
so I've seen this
How to prevent Eclipse from cleaning the bin folder for every build?
but I have a different problem. (i.e. if it was just resources, I could use that ability to copy them into place each time).
I'm generating files (ala sqlite databases) and they are getting cleaned up. I could move them around (and probably will eventually), but for now I want them within this structure for developing purposes.
is there no way to prevent eclipse from deleting these files (it doesn't seem to happen all the time, perhaps just on build error?), as I really need them to persist.
This is a solution for a different problem, but I think it would help here ;)
When generating resource files, (including DB files) do not put them into the /bin folder, especially if they are not going to change with every build, put them in a subfolder of your /src folder.
I have done so for webservice stubs, version numbers and other resources and regard it as the best practice.
If, however, you should decide to stick to your practice, take a look at the eclipse-generated build.xml file and modify it, making ant remove only the files you don't want.
I think the answer is in preferences
Java->Compiler-Building->Scrub output folders when cleaning project (i.e. not set, will hopefully find out soon).
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
We have a file share on a debian server which people will be putting mostly small plain text, word, excel, pdf, misc, files into. We want to keep file level versioning of everything placed in that file share. We'd like all of the versioning to happen automatically in the background every time a change is made to a file.
What's the easiest open source way to do this? What's the best versioning system to do this with? Is there an automated versioning system like this out there somewhere?
I'm not asking for complete instructions. I'm just looking for recommendations or keywords to search with (other than "automatic versioning files" which didn't find me much).
We're already backing up the volume many times a day. We don't want to do volume snapshots etc. We're looking for some kind of automated file level versioning.
Update:
Using incron to autocommit changes in a folder:
http://andrew.mcmillan.net.nz/blog/using_incron_to_autoversion_a_directory
Thanks to using the new keyword "autoversioning" I found the above which I'm interested in. It's a script which is triggered from incron every time a file changes. One problem is incron isn't recursive.
I would try a versioned filesystem, such as ext3cow or nilfs.
I have no experience with them, but they have always looked like a very interesting idea to me.
The SVNAutoVersioning directive to mod_dav_svn is one solution.