Hi there,

I am developing a simple application using C#, which perform simple function to the user,
it must save some information about the user , the info needed to be permanently saved (but could be changed from time to time by the user) but the application cant work unless those info. are there,

the first idea to use a data base, I am using SQL , but when I am ready to deploy the application, prepared the setup file and every thing ,
But I do not know how to deal with the data base, (where the user dose not have to download the SQL server):S ,

Exaple: I am using a traditional connection to database(connextion string, commands,...)
but I wonder what would be the server name in the connection string for example,( I am using my computer's name because I am developing the application on my computer, ??

I.e: what should I do in order to deploy my application that uses a database for users ,

OR is there another way to do what I need to , with out the use of DB:-/

I hope I made my self clear ,
please any help, all what I need is some hints

Thanks in advance

Why not store the information in a file? It's amazingly trivial to serialize objects into XML in .NET, so you might consider that path.

Another idea that so many folks forget it there is the Property.Settings capability in VS.
See the Settings.settings item in your project (Solution Explorer).
It is actually an XML file that can be deployed with the application. Its advantage is that you do not need to write your own configuration file parsing routines.
When you use the data designer, it places the database connection string in the settings file.

In my own applications, I store many other things in there. You can place an item such as HasBeenSetup, and when the application first starts up on the client machine, check this setting, provide setup functionality such as asking for the name of the SQL Server), and set this HasBeenSetup setting to know they have the application setup.

Just a thought,

AYK - Microsoft recommends not using the registry, and some client environments are locked down so that access to the registry can be fraught with problems.
The Property.settings does not use the registry. It reads from the config (XML) file, and writes a user config file in the local settings dir...well somewhere in the user's local settings path.

// Jerry

I agree with Jerry. Use the built in settings. It's pretty simple to use if you haven't got the time to code your own parsing methods.

As for registry, it's best not to store settings for your application in there if you can help it. Also, as Jerry says, Microsoft recommends not to use it. Makes me a little suspicous that they're planning to phase it out. Oh well.

The Property.settings does not use the registry. It reads from the config (XML) file, and writes a user config file in the local settings dir...well somewhere in the user's local settings path.

// Jerry

Thanks all for reply,
Jerry, I am fraid that I do not know exactly from where can I change the Property.setting
and how can I deal with it inoreder to do what I need, actually I am new to that,
so , please if there is a source I can read and learn how to implement this idea or any other way to help, could you send me that ,

thanks , your help is needed

I agree with Narue.

I had a similar problem and opted for streaming.

Just include the

using System.IO;

at the top of your file and you are ready to go.

Here's a link with a complete tutorial on the subject if you want to read more.


Good luck and Enjoy :)



I have question, do you mean that I use files to store every thing , what the file is is not problem, is it?

and what possiblly could be the drawbacks of the use of files, especially in the case when I need the property of id in the database, ?

the URL seems good and helpful,

I really need this to be solved as soon as possible , thanks

If you need ID values from the database, then you should stick with using the database. Values in a database can change especially if the database is accessed from multiple computers.
The drawbacks of using a file system are:
It requires Disk IO which can be slower than an SQL connection (when pulling large amounts of data).
It can be a security risk.
Can get out of synch with the "source of truth".
Can become corrupted.
File sharing issues.

//JMO - Jerry

This article has been dead for over six months. Start a new discussion instead.