We Keep Coding

windows phone 8, applicationsettings not persisted

I have the following strange behaviour in my Windows phone 8, C# App.
I am saving a Setting with:
private void SaveProperty<T>(T property, string propertyName)
{
if (IsolatedStorageSettings.ApplicationSettings.Contains(propertyName))
IsolatedStorageSettings.ApplicationSettings[propertyName] = property;
else
IsolatedStorageSettings.ApplicationSettings.Add(propertyName, property);
IsolatedStorageSettings.ApplicationSettings.Save();
}
When the app runs, I can read all settings I stored in IsolatedStorageSettings.ApplicationSettings.
But when I re-open my app (open it from the app list), the IsolatedStorageSettings.ApplicationSettings-Dictionary contains Zero (0) Keys and Values.
Am I missing something?
I used the ISETool.exe to take snapshots of the IsolatedStorage of my app (thanks to chepene).
I saw this behaviour: when I wrote the Settings (that means after the SaveProperty<T>() function finished), and the app is still running, I have the Settings saved in _ApplicationSettings. This agrees with my Observation that I can read from the IsolatedStorageSettings.ApplicationSettings when the app is running.
The _ApplicationSettings-file also exists when the is tombstoned or not running (when I can Access it by Holding the back-button of the phone and when the app is closed with the back-button).
But when the app is opened again (via the app list), the _ApplicationSettings-file is gone...
I also see that, when I'm writing a file into the IsolatedStorage with:
SharedStorageAccessManager.CopySharedFileAsync(
Windows.Storage.ApplicationData.Current.LocalFolder, fileName+"orig",
Windows.Storage.NameCollisionOption.ReplaceExisting, fileID);
and when I then don't read this file, it is gone when I open the app the next time.
By the way, to avoid confusion: I am not reinstalling the app each time I open it.
If you need more Information please ask.
Any help appreciated.

With AppSettings, I've seen something similar on WP7/7.5, but it happened only when my property-value's type was a class that was not known to the serializer.
Are you sure that there were no exceptions:
during Save
during App Exit (since the App may dump the settings at that point)
during the time that App loads the settings for the first time after launch?
Note that this doesn't necessarily must mean the app crashing. I mean, any exceptions, those internally silenced or user-handled too. Please check the VisualStudio's Output panel for "first chance exceptions" log. If any I/O or security or serialization exception shows up, then investigate there. If i remember well, there's even a whole set of isolated-storage exceptions that are easily interceptable from debug/exceptions menu.
However, the issues I had with unknown or nonserializable types does not explain at all why your extra non-appsettings files would evaporate.
Another thought: maybe some additional tool performs something like 'clean deploy' for you? I don't remember exactly, but I think that VisualStudio's deployment cycle was quite plain:
rebuild
remove/uninstall old app from device -- so probably purges isolatedstorage
install new app onto device
So, maybe that's the cause? Hm.. on afterthought and re-reading your question again, you've said about running the app from the applist, so that rather is not the case. Be sure to check firstchance exceptions then!

Thanks to quetzalcoatl I found the solution:
I am storing all my files in the root Folder of my app. At the start I am then reading all my files (via a DataContractSerializer) and casting it to my model. Since it happens sometimes that my files get corrupt, I delete every file which throws a SerialzationException. But as I read every file, and since _ApplicationSettings is not castable to my model, I am deleting _ApplicationSettings automatically.... So I learned that the ApplicationSettings are,just a file in the root folder, which I am allowed to read and delete. So the quintessence is to never write into the root Folder.

General file attribute to identify file without its path or even name

I am working on an application that keeps track and uses files stored on the file system. Users are allowed to open, create, delete and move files in the file system. Meanwhile my application is not constantly running so I can't keep track of all changes real-time. Afterwards my application has to find out what file is whom (i.c. as identified in my application).
The most preferred solution for the users is that the application solves every change itself. Each user-interaction is less preferred.
One of my ideas was to use an attribute of a file and assign a key-value to it so when it has been identified once, it can always been recognized afterwards. But I don't know if there is such an attribute. This article didn't give much hope: There is in Windows file systems a pre computed hash for each file?.
Does somebody know if there is such an attribute I can use? And how can I used it in C#?
Is there anyone who is running up against this problem? And how did you solve it?
I'd like to hear good suggestions.
regards, Jaap

If your files don't leave NTFS, this is easily achievable by alternative data streams, where you can store your data along with files. This is more-or-less good article about ADS: http://www.flexhex.com/docs/articles/alternate-streams.phtml
There is another suitable method - it's very efficient, but also very complicated to use, it requires quite good knowledge about NTFS internals - USN Change Journal; see http://msdn.microsoft.com/en-us/library/windows/desktop/aa363798.aspx. With USN Change Journal, you can "get" very efficiently all files that were changed (even all change events) within specified time period.
Nevertheless, if your files leave NTFS realm, e.g. if it's copied to FAT32, contents of ADS is lost.

Relying on a File attribute is "dangerous" in that some user could alter the attribute while your program isn't running. This could lead you to believe that a certain file is (or isn't) tracked by the program while it really isn't.
I would suggest to keep track of the files in a database, XML, or some other file. When your application starts you read the file/db and check for new/deleted/editted files.
You could store a Hash of the files to find out if a file has been moved/editted. Keeping track of files that are moved AND editted is going to be pretty difficult. (I have no clue how you could achieve it)
PS: Have you considered making your application a Windows service? Having the file-management running in the background no matter if the GUI part of your application is running or not?

Where to store the user Id, while using a network database

We have a C#.Net application which uses a network database. I mean to say that many instances of the application will access the same db from different machines. So if I have to store the user-id to show the user while re-logging in, where can I store it?
The options i have are:
- Storing it in a local file in application directory. (But the problem is that the application is installed using Click Once. When the application is updated the application directory is being changed. May be I am missing something here.)
- Storing in the registry. Are there any other?
Can some one please suggest what to do? Correct me if I am wrong.

There are buil-int locations for this kind of stuff see Environment - specifically:
ApplicationData (user-specific roaming)
LocalApplicationData (user-specific non-roaming)
CommonApplicationData (not user-specific)

Generally you want to store any data that needs to persist between sessions, and is user specific in the registry, or the user AppData folder. Normally for small things (i.e. ids, basic settings etc....) the registry is the best place. Just make sure to stick it under HKCU\Software\Your company name\your program name. Although if the data is sensitive you should be careful where you place it, and it should be encryptedto protect it from basic snooping. If it's data that isn't sensitive though then the registry is a good place to put it.
This assumes of course that the installation and configuration doesn't need to be xcopy portable (i.e. a user could just copy the installation folder to a new place/computer and have everything work as normal). If that's the case then you'll want to store it under the installation directory.

If you need to store the UserID on the local, keep it in some kind of configuration file, mabe under a "LastLogin" entry. Check out this question and specifically this answer for more information.

Consider using Isolated Storage

how to store data in c# application in a portable form?

I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason

If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.

Do not modify the executable. Adding a single SQLite database is a much better solution.

Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it

SQLite is what your looking for and is compatible with c#

If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.

I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.

Where to store configuration for a simple .NET application?

I'm programming a fairly simple application which I want to cut to just one simple EXE file + some data storage (XML for example).
My question is regarding configuration files. Where to put those files? I saw a few applications that have just an EXE file (uTorrent, Media Player Classic - I can use them without any installation), but they store their config somewhere else. How to achieve this?
How would you approach such situation? Is it better to try to achieve the thing I described above, or simply use a configuration file and data storage in the same directory as the EXE file?

Creating or using a file in the same folder (or in the App_Data) is pretty standard practice.
You use an installer like Inno Setup (free) to create a single exe installer (http://www.jrsoftware.org/isinfo.php)
If you want a DB rather than XML, have a look at SQLite (http://www.sqlite.org/) a file based DB or use an MS Access DB.

I think you want to take a look at Application Settings. This is an API which allows you to save user or application settings using a strongly typed API. Under the hood the settings are stored via XML serialization.
This API works with virtually every type of .Net application including low permission Click Once versions. It does the work of finding the place on disk appropriate for storing the data and completely hides it from you. It also has a nice GUI integration into Visual Studio.

EXE-only programs store their data either in the Windows Registry or in the user's Application Data/AppData folder. Although this may appear cleaner at first, it just hides the ugliness of scattering all your data around. I would suggest just going with a simple XML/INI/text data file that is generated when needed and easy to migrate.

Please see: WPF/C#: Where should I be saving user preferences files?

You could use the app.config file for storing your configuration. For the data, I would sugest something like db4o or SQLite.
Edit
This tutorial can show you how simple is to use db40 to store and retrieve your data.

Do not forget Isolated Storage. It gives you a place to read and write files to without the need for you to specify a location. Sometimes it is the only way sandboxed applications (like Silverlight) can store user or machine specific data locally. See here for an example.

I would store them in the same directory. That just seems easier to me, at least that's the way I always do it.