Concurrency Problem? Loosing Settings in Production

[simader]

Hi,
I am a little bit desperate, because some of our users are loosing a very important setting during working and i can't reproduce it.
However I have only one string setting looking like this

[
{
"Type": "System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"Name": "CustomerName",
"Value": "dev"
}
]

And on some Windows PCs this settings gets something like this, even though it was filled correctly before.
[
{
"Type": null,
"Name": "CustomerName",
"Value": null
}
]

Do you have any idea how this could happen, and how I could try to reproduce it?

[anakic]

Hey @simader, it certainly looks like it might be a concurrency issue. Here's what I suggest:

1. Right now, the TrackingConfiguration class is not thread-safe at all. To make it thread safe, you should lock Apply/Persist/AddProperty etc... methods. Just declare a key object and use it to lock those methods. If you do, please feel free to submit a pull request with the change.
2. There are Trace.WriteLine calls in the TrackingConfiguration object. They currently don't log the value that's being read/stored but it's easy to include it in the string. You can also include a ThreadID in the log. You can then register a new TraceListener in your application and dump the log data into a file. Then you can ask your clients to send you this file and figure out what's going on.

If concurrency is the problem, point 1 should solve it.