Develop Reference

When to use Properties.Settings.Default in C#

What are the best practices for using the Properties.Settings.Default config settings in C#? I see it commonly, but I often don't know when to utilize it vs. when I should just hard code values. Thanks!

Basically, I try to avoid hardcoding values in code, mainly because if there's ever a need to change their value it requires a re-compile of the app.
It's usually beneficial to have some sort of common object that exposes all your settings via public properties so that you are referencing the settings the same way throughout the app.
Example:
public static SomeReferenceClass
{
public static string TimeOfDay { get{ return Properties.Settings.Default.TimeOfDay; }}
}
Then Later on to call it
SomeReferenceClass.TimeOfDay;

My rule of thumb has always been that if the values of the properties need to change without modifying the code then make them an external/configurable property. If you will never need to change their value, then they're a constant and can be hard-coded.
Basically, if these values need to be configured/changed put them in Properties.Settings.Default. You can hard code constants.

personally, I use the default setting when the user or application setting are not specified or persisted.
I'd never hardcode a setting that might change based on any number of variables such as environment, user, application, or whatever.
I generally create settings providers that implement an interface. That way, you can easily change out how to gather your configuration settings without changing the business logic.

How to define Variable similer to Session variable in ASP.NET

I want to define a variable or object like session, to stored data about each user, and i want to access this object in many pages,
could u please tell me if there is a way.
thanks

You have onlyy a few choices, really. URL parameters, hidden form inputs, cookies, session (be careful in a load-balanced scenario) or just store/retrieve stuff from a database. RaveDB is bloomin' brilliant for this because it's so fast and document-based.

You can store data in a cookie and then in your codebehind parse the specific cookie into something like a System.Collections.Generic.Dictionary
But you should use sessions.
Edit
IF if's a KeyValuePair<String,TValue> you can set Session[kvp.Key] = kvp.Value;, if not Session["KVP"] = kvp;

If u really don't want to use session use Database mind that this is a slow method...

i've had a few situations where I wanted to minimize/eliminate session storage (due to users being on a horrible wifi connection). to handle this situation I used an encrypted query string with only their ID in the string. in the base page I would decrypt the string and pull information I needed from the database. This information would be populated into objects that I defined and since the objects were in the base page I could access the information from any pages that inherited it.

Session instead of viewsate

I have found many questions here about storing values in viewstate, but haven't found a good answer.
I have a situation when i retrieve large amount of data from database. Then i filter and manipulate the data according to my needs (so it is a preety heavy process). Then I put the result inside a list of custom class. For example lets say this class will be Person
List<Person> persons = new List<Person>();
private void FillPersons()
{
//Call to webservice
persons = ws.GetPersonsList();
//Do all kind of custom filtering
//Manipulate the data
}
Now the whole FillPersons() method is a heavy process that returns pretty small amount of data. And unfortunately it can't be moved to SQL and the heaviness is in the process, but that is not the point.
The point is that i need to reuse this data on the page between post backs.
Right now in order to spare the additional call to FillPersons() I mark Person class as serializeable and store the list in the viewstate, that works fine except the fact that the page becomes 1mb size because of the viewstate. According to what i have read, it is not so acceptable approach i.e. it is not secure and it blows the source code making the page heavy etc. (second is what most concerns me)
So it leaves me with a session. However session is persisted not only between postbacks, but much after it, even when user leaves the page. Or worst- the session will end before user decide to postback. So finding the best time span for session lifetime is mission impossible.
My question is what is the best practice to reuse "datasets" between postbacks?
What you guys do in such cases?
Thanks.
PS: hidden fields etc. is not an option.

You can store this kind of data in the Cache. It is application wide, so depending on what you add use the key accordingly.
var key = UserID + "_personList";
Cache.Add(key, personList, null,
DateTime.Now.AddSeconds(60),
Cache.NoSlidingExpiration,
CacheItemPriority.High,
null);
Note that you can never assume that the data is in the cache (it might have been flushed) so always check if it returns null and than refill it.

Viewstate is not a good way of storing large objects. As you mentioned your page size will get bigger and every postback will take lots of time.
I would suggest using cache. By using cache your list wont be saved there till end of session and you can set how much time it should be stored there. For caching you may use HttpCache or some distibuted caching system like AppFabric or MemCached . This nuget package will help using these cache systems.
this link will help how to configure AppFabric.
I should edit with some code to make it more helpful.
https://bitbucket.org/glav/cacheadapter/wiki/Home
var cacheProvider = AppServices.Cache; // will pick cachadapter using web.config ( can be Http, Memory, AppFabric or MemCached)
var data1 = cacheProvider.Get<SomeData>("cache-key", DateTime.Now.AddSeconds(3), () =>
{
// This is the anonymous function which gets called if the data is not in the cache.
// This method is executed and whatever is returned, is added to the cache with the
// passed in expiry time.
Console.WriteLine("... => Adding data to the cache... 1st call");
var someData = new SomeData() { SomeText = "cache example1", SomeNumber = 1 };
return someData;
});

Other than a cache (good idea by Magnus), the only other way I can think of is to keep the results of your heavy operation stored in the database server.
You mention that it takes a lot of time to retrieve the data. Once done, store it in a purposely established table with some type of access key. Give that key to the browser and use it for pulling what pieces you need back out.
Of course, without knowing the full architecture it's really hard to give a solution. So, in order of preference:
Store it back in the database with a unique key for this user.
Store it in a remote cache
Store it in a local cache
Under no circumstance would I store it in the page (viewstate), cookie (sounds too big anyway), or in session.

Have you considered using ASP.NET caching?
You should choose a key that will suite your exact needs and you will have your data stored in the server memory. But keep in mind cache is application specific and is valid for all users.
If the data you process is not often changed, the processing algorithm doesn't depend on user specific settings and it is not critical to always have the latest data maybe this is the best option I can think of.

Store your filtered collection on disk in a file. Give the file the same name as a key you can store in viewstate. Use that key to retrieve the file on postbacks. In order to keep the file system from filling up, have two folders. Alternate the days for which folder you save the files to. That way you can wipe out the contents of the folder that is not being used that day. This method has extremely good performance, and can scale with a web farm if your folder locations are identified by a network path.

I think personlist is a shared object. Does everyone use the same list? You can store on Application.
Application["PersonList"] =persons;
persons = (List<"Person">)Application["PersonList"]
Or you can Store on Static class.
public static class PersonList { public static List<"Person"> Get {get;set;} }
You should write this code to Application_Start on Global.asax file
PersonList.Get = ws.GetPersonsList();
And you can get List by using this code
persons = PersonList.Get;

How can I create a variable with project-wide scope in ASP .NET?

I want to declare a variable in such a way that I can access that particular variable and its value in all the asp pages in the project. Can anyone tell me how to declare a variable in C# such that it has project-wide scope?

You have a couple of choices and the best may require more specific information about what you are trying to accomplish. For example, do you need to be able to write to this variable as well?
But a simple approach is just to store it in the application object: Application["mydata"] = value;
Note that you can lose this data if your application is reset, which can happen from time to time. You can look at using cookies or a database to persist across resets.

Declare it as a "static" variable in a static class anywhere in the projects. You can declare it either as "internal" or "public".
However, you should always be careful about such a thing. If you need this, your design might need some work.

You can use a public property in the global.asax. That way you will be able to retrieve it from anywhere in the project.
global.asax:
private string _myvar = "";
public static string MyVar{ get { return _myvar; } set { _myvar = value; } }
any page code-behind:
string text = MyClassName.Global.MyVar

Based on what you said, I supose you want some kind of global variable.
If tha's the case you should learn about the Application object and, probably, initialize your variable in the Application_Start method of global.asax file

If you need some generic approach. Create a project in your solution called Common as class library. Add a class file and add some public static members there . Compile it to dll, and you are now ready to use the members within the solution and if you wnt to use the same in some other application you can use too by adding reference.
But if you need it for some specific time you can use either of them stated above. In addition you can also use Session["MyObject"] = object_value. All have cons and pros. Google and use what ever suits you best. You have various options now, :)

Application scope defined within your global.ascx file.
Thus: Application["VariableName"] = value.

If it is user and session specific, you could always store it in a session. It's simple as: Session["VarName"] = object;

You can use the HttpContext to store items that need to be accessed throughout the lifecycle.
Example:
HttpContext.Items["myVariableKey"] = "my value";
The item put into that collection are only available for the current request.

ASP.NET Server Side Viewstate

I have read some approaches to storing viewstate on the server:
Here is one
Here is another
But they are sort of complicated. I am looking for a way to persist an object without having to serialize it. I could use session state, but if a user opens more than one window, there could be overwrites of the object.
Is there a simple solution to this?

In this situation I would put store the object in the session using a unique key and tie the key to the page. All this can be abstracted into properties on the page class.
public string PersistanceKey
{
get {
if(ViewState["PersistanceKey"] == null)
ViewState["PersistanceKey"] = "Object" + Guid.NewGuid().ToString();
return (string)ViewState["PersistanceKey"];
}
}
public PersistanceObject Persistance
{
get {
if(Session[this.PersistanceKey] == null)
Session[this.PersistanceKey] = new PersistanceObject();
return (PersistanceObject)Session[this.PersistanceKey];
}
The different session keys would allow different objects on a per-page basis. Alternately, instead of using the Session object, you could consider using the application cache (the Cache object) to automatically remove stale entries out of memory, but this has its own caveats.
It should be noted that Joel's warnings on his answer about memory usage are entirely accurate. This might not be the best idea for low-memory, high-usage, or large-persistance-object scenarios.

I am looking for a way to persist an object without having to serialize it.
Be careful with that. This will have a dramatic impact on the memory use of your site, and memory use is often the biggest impediment to scalability.

Assign a number to each window the user might open. Append that number to the session key. You should also store the number somewhere in page (querystring or a hidden input) to be able to retrieve the appropriate session variable.