Recently, I discovered that the "Web.Config" file contains an <appSettings> section which seemed good for storing one's Application Settings. Heck, it even has a programmatic way to access the file thru a standard System library. So being all clever, I wrote an Interface to access it and then a Concrete implementation of the interface, shown here:
public interface IAppSettings
{
IEnumerable<string> GetValues(string componentName, string settingName);
IEnumerable<KeyValuePair<string, string>> GetValuePairs(string componentName, string settingName);
void SetValues(string componentName, string settingName, IEnumerable<string> valueList, bool append);
void SetValuePairs(string componentName, string settingName, IEnumerable<KeyValuePair<string, string>> pairList, bool append);
}
Then I came to discover that saving settings back to "web.config" while the application is running causes the entire application to re-start. This seems completely unreasonable to me because if I'm writing back to web.config a lot and the application is restarting each time, then things like HttpRuntime.Cache get completely emptied effectively making my Cache useless because it's constantly emptying and repopulating.
So I'm wondering: Where should I store my Application Settings?
Is there a good solution out there for this so that I don't have to roll my own?
EDIT:
Okay, thanks to everyone who suggested using a DB and a potential table schema. I think I'm going to go with the following schema:
settings:
index NUMBER NOT NULL AUTO_INCREMENT <== Primary Key
component NVARCHAR(255) NOT NULL
setting NVARCHAR(255) NOT NULL
key NVARCHAR(255)
value NVARCHAR(255) NOT NULL
Though I don't think I'll make the "setting" the P-Key, but use an Auto-Incr Index instead. This way if I have an application that needs to mail something to multiple managers, I can store many:
index component setting value
1 RequestModule ManagerEmail manager1#someplace
2 RequestModule ManagerEmail manager2#someplace
And then I can use:
IEnumerable<string> GetValues(string componentName, string settingName);
And it will return a list of email addresses, rather than just a single value.
Does this make sense?
web.config is generally used for read-only settings, ie. the settings set during deployment of the application by the system administrator.
If you want to read and write the settings, the most obvious way is to use the database. By the way, this has an advantage: an application can be hosted on several servers and will still read and write the settings correctly,
You can also implement your custom storage for the settings, but it will be probably more difficult to implement and not much faster.
To answer your second question, the structure of your database depends on the type of settings you want to store.
If you need to store heterogeneous unique entries like this:
Mail address of an administrator,
Maximum number of entries to display on home page of the website,
Text to display on "About us" page,
Boolean value indicating whether public comments are enabled or not,
then you have to use varchars or other more or less friendly types as keys to identify the entries (rather than to refer to them by their index).
On the other hand, if your purpose is to store the mail addresses of several managers, you should create a Manager table containing their mail addresses, names, datetime of their last connection, etc.
You really shouldn't mix both. In theory, you can refer to the entry in settings by component/setting pair. In practice, it makes things harder and creates a bunch of problems:
What if, further, you will need, for every manager, to store a boolean value indicating whether she/he wants to receive alerts from you? With your current structure, this will be impossible.
Since the same setting can have multiple values, how do you intend to handle the settings which must be unique? For example, there must be only a single value of text to display on "About us" page. What if there are two values stored in database?
Storing settings in web.config is useful because it makes it easy to have different settings in different environments. However, as you say, this is no use if you are likely to want to change the settings in a live environment.
A simple database table is the most useful way to do this if you need to change the values.
eg.
create table Settings
(Name varchar(50) primary key,
Value varchar(50))
If you're using SQL Server, you can set to the Value column to be sql_variant which will allow you to store a variety of datatypes.
It is meant for application settings, but not settings that are meant to be dynamically changed during runtime. Rather, it is for settings that change only occasionally, and where you would expect (and even desire) an app restart when they change.
For more ephemeral settings, you may want to just use a simple database system - even a flat file/XML in the App_Data dir can work, if your app doesn't use a database otherwise.
Yes.Changing the web.config will reset the application.I usually maintain a settings table to store key-value pairs for the settings and access it from there.
SETTINGS
SETTING_NAME VARCHAR(100)PRIMARY KEY
SETTING_VALUE VARCHAR(100)
Then write a class which can Insert,Delete,Update values to this table.
Ex Data for the SETTINGS table
SETTING_NAME SETTING_VALUE
AdminEmail admin#mysite.com
ErrorTrackingEmail errors#mysite.com
I usually add a "type" field to my settings table so that I only retrieve the group of settings needed this works for me as a way of grouping like settings and retrieving them at once.
Create a key-valued table like this:
settings:
name NVARCHAR(255) PRIMARY KEY
value NVARCHAR(255) NOT NULL
First of all, it's not unreasonable at all when you consider what information is supposed to be stored in the web.config file. When you change things like assembly information, connection strings, etc., your application needs to stop and reload the values to run with those settings.
If you're storing application wide settings, then you can create a Settings table in your database or even use a separate text file to store the settings.
If you're talking about storing per-user settings, you shoul check out ASP.NET Profile Properties.
Application-wide settings should certainly be stored in this section of the web.config file, as it prevents hard-coding values which may change over time. There's no need to read them out using your own code, as there's a built-in method: use the System.Configuration.ConfigurationManager.AppSettings array to retrieve them (you'll need to add a reference to the System.Configuration assembly in your project). You can edit AppSettings through the ASP.NET Web Site Administration Tool, too (Project menu -> ASP.NET Configuration).
For values which you envisage changing more often and while the site is up and running, it's reasonable to use an XML file, lightweight database (such as SQLite or SQL Server Compact) or even a text file for these settings.
If you need to save settings, you can always save them in a custom configuration file.
I did just that a while back, and I have the code available to do it here.
Related
I'm currently handling a .Net system that was developed in Linq for its data retrieval structure. This system was developed by other developers last time and I'm dealing a big problem now.
One of the bad practice (or i just not sure why must the developer do that) i found from this system is that, inside /AppData/DataContext/, there are alot of .dbml files and in the .designer.vb, for example Product.designer.vb file, consists of this piece of code:
Private Shared mappingSource As System.Data.Linq.Mapping.MappingSource = New AttributeMappingSource
Public Sub New()
MyBase.New(Global.System.Configuration.ConfigurationManager.ConnectionStrings("DBconstr").ConnectionString, mappingSource)
OnCreated
End Sub
My current major challenge is, I need to change to a new connection string name for all DBconstr and point to another database while keeping the current "Dbconstr" setting in web.config. There are over 400 lines in the entire system I need to find and replace if i have to do it manually. So I need advice if there is any way i can change all hard-coded connection string using one or few direct methods instead of changing all 400 plus lines manually?
I had thought about calling certain method in .Master page and override the value of .ConnectionString for all the child pages but not sure if this is possible.
Please advice. Thanks
You should have a look at this: http://blogs.msdn.com/b/webdev/archive/2009/05/04/web-deployment-web-config-transformation.aspx. It explains how to use web.config transformation. It basically allows modifying the value of a setting (ie. connection strings) depending on your solution/build configuration.
Modifying the configuration file "on the fly" is much easier than trying to modify it in the code.
You should also check these two answers I provided on the same topic:
How to have different web.config settings for my local machine? -
https://stackoverflow.com/a/19294499/375304
Applying web.config transformations locally - https://stackoverflow.com/a/19301084/375304
Where would be the best place to store static values.
And how would I access it.
I want to be able to access static values from any page. But only have to define them in one place.
For example 'email' and 'phoneNumber'
I have tried things like Session and PageData, and defining the variables in my header (used by all pages) but this does not work.
The partial is initialised after the page, so it either doesnt work at all, or doesnt work on first time load.
E.g. First time Load:
Page Loaded <- Tries to Access variable. Not initialised.
Header Partial Loaded <- Variable initalised.
Result. Page does not show variable.
I have considered storing it in the config file. But I have no idea how to access this from Webmatrix 2.
I could just create a txt/ini file or something but surely parsing a file isn't the best way to do it. - I have since tried this and it doesnt seem valid like in mvc3 (config),and txt files are not practical to read for each request.
By "static", if you mean values that don't change across the lifetime of the application, you would normally use HelperPage.App property for storage. It is based on the dynamic type so you can create arbitrary properties:
App.Email = "someone#somewhere.com";
Or you can use the more traditional name/value collection approach with AppState:
AppState["email"] = "someone#somewhere.com";
However, if your "static" variables are user-specific, you should use Session as that is scoped to the user. Or use a database if you want to store them permanently.
You can set session values in _PageStart.cshtml (may need creating), or in the Session_Start event of the global.asax file and then access them in any partial / view you desire.
A problem appears when two users are logged on to our service system at the same time and looking at the service list gridview. If user1 does a search to filter the gridview and user2 happens to click to another page user2 sees the results from the search performed by user1. That means one company can see another company's data.
It's an ASP.NET application that was developed in house with C#/ASP.NET 3.5. The data is stored in a SQL 2000 database and relies very heavily on stored procedures to update, select, and delete data. There are multiple user types that are restricted to what data they can see. For example, we have a company use that can only see data relavant to that company.
From what I've seen, the security is handled through If statements in the front end. Example, if userlevel = 1 then do this, if userlevel = 2 do this. These statments are used to show or hide columns in a grid, run queries to return data, and any other restrictions needed. For a company user the code behind gets the companyid assigned to the user and uses that in a query to return the results of all the data associated with that companyid (services, ships, etc).
Any recommendations for fixing this will be highly appreciated.
It's hard to say without seeing any implementation details, but on the surface it appears that there maybe some company level caching. Check for OutputCache settings, DataSource caching, explicit caching with Page.Cache, etc.
This article is a little dated, but at a glance it looks like most information is still relevant in ASP.NET 4.0.
ASP.NET Caching: Techniques and Best Practices
In addition to jrummerll's answer, check the Data Acces Layer of our app and make sure that you don't have any static variables defined. Having a static variable defined could cause this sort of issue too, since 2 contending requests may overwrite the value of the CompanyID, for example.
You basic model should work. What you've told us is not enough to diagnose the problem. But, I've got a few guesses. Most likely your code is confusing UserID or CompanyID values.
Are you mistakenly storing the CompanyID in the Cache, rather than the session?
Is the CompanyID stored in a static variable? A common (and disastrous!) pitfall in web applications is that a value stored in a static variable will remain the same for all users! In general, don't use static variables in asp.net apps.
Maybe your db caching or output caching doesn't vary properly by session or other variables. So, a 2nd user will see what was created for the previous user. Stop any caching that's happening and see if that fixes it, but debug from there.
Other variations on the above themes: maybe the query is stored in a static variable. Maybe these user-related values are stored in the cache or db, but the key for that record (UserID?) is stored in a static variable?
You can put that if statements in a thread. Threading provides you the option that only 1 user can access the application or gridview in your case.
See this link: http://msdn.microsoft.com/en-us/library/ms173179.aspx
Here is some sample code that is throughout the entire application that is used for filtering results. What is the best way to fix this so that when one user logs on, the other user doesn't see those results?
protected void PopulategvServiceRequestListing(string _whereclause)
{
_dsGlobalDatasource = new TelemarServiceRequestListing().GetServiceRequestListingDatasource(_whereclause);
if(_dsGlobalDatasource.Tables[0].Rows.Count!=0)
{
gv_ServiceRequest.DataSource = _dsGlobalDatasource;
gv_ServiceRequest.DataBind();
}
else
{
gv_ServiceRequest.DataSource=new TelemarServiceRequestListing().DummyDataset();
gv_ServiceRequest.DataBind();
gv_ServiceRequest.Rows[0].Visible = false;
gv_ServiceRequest.HeaderStyle.Font.Bold = true;
}
}
Generally when implementing some sort of role based access control, we have the following well-known concepts:
Role
User
Permission
And users would be assigned to roles each of which have a set of permissions (to perform an operation / access a resource etc).
So users gain permissions to perform operations by being assigned to one or more roles (which have been assigned a set of permissions).
In any given application, permissions are defined at compile time since the code actually enforces the permissions at various places where access to resources .
My thinking is that if the set of possible permissions/operations changes – it requires changes to the code and recompilation any way, so having a lookup/reference table in the database won’t really provide any value beyond the fact that a db admin could do a quick sql query to list all permissions used by an app.
Yet most applications I’ve seen create a lookup table for the permissions and -also- map it to a enum in the code.
Given this, is there any reason to actually have a database table representing the list of possible permissions (other than the fact that it is probably easier for some to look in the db as opposed to digging into the code to find the list/enum of permissions)?
Checklist:
1) Do you need to make changes while the website is online, without downtime?
2) Will you be using built-in role/membership provider?
3) You want to use attributes (like mvc [Authorize]) etc?
4) You want to allow users to programatically change permissions/roles?
Any of the above means you have to store the info on DB.
For smaller scale apps I prefer to just create some static methods that also use some kind of inheritance, ie:
isadmin()
{
if (usernameArray.Contains[currentname])
return true;
[...]
}
ispublisher()
{
if (isadmin()) return true;
[...]
}
And a table with permissions for each user pseudo-class.
Update: DB schema for specific access: (* is key, & is foreign key)
Users:
Username *
[...]
UserClasses (EG: admin...)
ID *
description
AccessTypes (EG: can delete)
ID *
description
UserClassesAssign
classid *&
username *&
AccessPerClass
accessid *&
classid *&
So anytime you want to see if 'username' is able to 'CanDelete' you have to check if the User 'username' is linked to any classes that are linked to the access 'CanDelete', and these links can of course change during runtime
i'm building my web application to connect with db.
so far i have managed to deal with it, (although i didn't build BLL & DAL).
i have a table which has column "id". i know there is a way to declare it in the SQL Server to be incremented automatically. ( but i don't want it).
i want to declare a global application variable that will hold the value.
i have 2 questions:
how i declare it?
where i create it and initialize it ? (i have several login pages).
THANKS!
p.s
it would be helpful if someone will tell me how do i build the DAL with my stored procedures?
and for what i need yo use BLL which i cant do in the DAL?
You can use the Application object - it is part of the HttpContext and is directly accessible on any page.
If you don't want to use it, you may want to write a Globals class (or whatever name you like) that holds static members.
public class Globals
{
public static int Counter { get; set;}
}
// accessed from other classes:
Globals.Counter++;
Either approach will not work of you have a web farm or several web applications and will not survive restarts.
Regardless of these options, the right solution (even if you don't want to use it - can you explain why?), is to use the ID field with the IDENTITY clause.
Storing the variable is the easy part. Managing your own ID generation and the contention and concurrency issues is the hard part. Good luck.
There really is no such thing as a global variable in ASP.NET. Remember, HTTP is stateless.
The closest you can come is storing something in the Application object:
Application["myvar" ] = x;
x = Application["myvar"];
But even here, this variable is lost when the app needs to restart, which it can do from time to time.
A much better solution for what you describe is a database value.
Incrementing an integer and then throwing that incremented ID into the db is fraught with danger. Multithreading? What happens when the application bounces? Do dev and prod deployments share the same set of numbers?
It sounds like you need a globally unique identifier and can be created outside of the database. That sounds like a job for a GUID. Sure, it takes up more space in the db, but it probably isn't the worst thing you are going to do to the database.