Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 336
  • Last Modified:

Local storage options for .NET Windows Service

Hi,

I'm just starting to write a very simple windows service in .NET and I have a requirement to store data, from the last calculation to disk so that I can compare data even if the service or server is restarted.

I think SQL Server is over kill for this, so I thought about using LocalDB or IsolatedStorage as I have done in the past, but wondered if there is a better solution for such simple storage.

Thanks
0
wint100
Asked:
wint100
  • 4
  • 4
  • 3
  • +1
2 Solutions
 
it_saigeDeveloperCommented:
You can store your data to the LocalApplicationData directory that is accessed via System.Environment, e.g. -
System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData)

Open in new window


In windows vista and higher this will return:
// For LocalSystem user
C:\Windows\ServiceProfiles\LocalService\AppData\Local

// For user named Peter
C:\Users\Peter\AppData\Local

Open in new window


-saige-
0
 
Chris StanyonCommented:
Depends on what data you want to store. As well as local file storage, you've also got the registry
0
 
wint100Author Commented:
Thanks for the suggestions. I'll be storing
a list of objects and a timestamp, the list may have around 100 entries.
0
Learn Veeam advantages over legacy backup

Every day, more and more legacy backup customers switch to Veeam. Technologies designed for the client-server era cannot restore any IT service running in the hybrid cloud within seconds. Learn top Veeam advantages over legacy backup and get Veeam for the price of your renewal

 
Daniel KlineCommented:
I recommend you look at wrapping the file access in a mutex so that multiple concurrent service calls can't create a deadlock problem of failed request.

Where to place the data is based on a number of unspecified requirements, the most important of which is security.
0
 
wint100Author Commented:
Security isn't an issue, it isn't sensitive data at all.
0
 
Daniel KlineCommented:
It's hard to say what would be best in your scenario, but it sounds very much like a state saving function that I created in the old days of mainframes and minis.  

In my solution, I saved the entire state of the application, including all internal variables to a disk storage immediately before running the update from the application.  If the server or connectivity failed during processing, the application when restarted would look for the recovery state and load the application from exactly the state before the update failure so the user could continue.  If the application ended normally, the recovery state record was deleted so that the application would initialize to a clean state when started.

Like your case, the information in the state was not sensitive and so a file storage was more than adequate.  The state recovery record was keyed with the user ID so that multiple concurrent users sessions could be managed.

The solution is simple but robust and file storage (which is persistent across sessions)  is all that was required.
0
 
wint100Author Commented:
How about isolated storage? I always found this worked well but didn't knownifnit was a good solution?
0
 
Daniel KlineCommented:
"
 

--------------------------------------------------------------------------------
 
It seems like overkill and overly complex:

"When an application stores data in a file, the file name and storage location must be carefully chosen to minimize the possibility that the storage location will be known to another application and, therefore, will be vulnerable to corruption. Without a standard system in place to manage these problems, developing ad hoc techniques that minimize storage conflicts can be complex, and the results can be unreliable.

With isolated storage, data is always isolated by user and by assembly. Credentials such as the origin or the strong name of the assembly determine assembly identity. Data can also be isolated by application domain, using similar credentials."
0
 
it_saigeDeveloperCommented:
I would have to agree with Daniel.  Using isolated storage is either going to be overkill or overly complex.  As Daniel pointed out, your only concern right now should be what is accessing the data with regards to your service[s] and their respective threads.

-saige-
0
 
wint100Author Commented:
It is a very basic process running every 30mins, reads an email and parses out a value in the subject from lotus notes and saves that info to a file. That is it.

I mentioned isolatedstorage because inhale a class from another app I could simply copy over to handle all of the save and restore for me without much work at all. I do agree it can be complex but I wouldn't be starting from scratch.

I've not heard of 'mutex' before
0
 
Daniel KlineCommented:
A Mutex, which probably is not needed in your scenario, is for "Mutual Exclusion".  In other words, only one at a time.  It a pattern for making sure that only one request or session can access a resource at a time ... protecting it from corruption by collisions and conflicting state data.  Put it on the pile for investigation later.  It doesn't look like the need is immediate.

Isolated storage could work in your situation, but it is more complex than necessary.  I have a philosophy of using the simplest solution possible, because you never know who will follow you and if they will have the skills to understand what you have created.  In the end, it's your choice.  That's one of the pleasures of being a developer.
0
 
it_saigeDeveloperCommented:
Code reusability is a staple of good design.  As for a mutex, a mutex (Mutual Exclusion) is a thread synchronization mechanism used to ensure that:
No two concurrent processes are in their critical section at the same time; it is a basic requirement in concurrency control, to prevent race conditions.

Quoted source

-saige-
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 4
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now