What is Web.config? What is its' relation to ASP.net? What are the advantages of using such configuration? Or is there a better configuration you can use to make you work more efficient?

I am using webconfig to make global connection so that I dont have to repeat connection on each page.

u can disable HTTP/POST and HTTP/GET Protocols
by the following code
Unless you specify otherwise, .NET will attempt to bind your Web services to three separate protocols: HTTP/POST, HTTP/GET, and SOAP. We say attempt, because depending on the parameter and return types for a service, the HTTP/GET protocol may not be possible. Bindings for these three protocols will be included in the WSDL file automatically generated by .NET, and consumer clients will have the option of choosing any one of them for communication with your service.

You can easily remove these bindings by adding the following section to your Web.config file:


<webservices>
<protocols>
<remove name="HttpPost" />
<remove name="HttpGet" />
</protocols>
</webservice>
his section will tell the WSDL generator not to include bindings for HTTP/POST and HTTP/GET. The two remove sections specify that HttpPost and HttpGet should not be supported.

Security and interoperability are two good reasons to avoid exposing your Web services using HTTP/POST or HTTP/GET. HTTP/GET is less secure than SOAP, and since HTTP/GET is commonly used for Web linking, a malicious user could potentially trick someone into unknowingly calling a Web service using their security credentials when they thought they were clicking a Web link.

With regard to interoperability, where SOAP is a widely-used standard for Web service communication, HTTP/GET and HTTP/POST are not. As a result, many automatic proxy generation tools weren't designed to "understand" the HTTP/GET and HTTP/POST bindings included by default in a .NET-generated WSDL document. If your service doesn't make use of these bindings, removing them can increase your service's interoperability.

__________________
Shaalini.S
Be the Best of Whatever you are...

Web.config

Web.config acts as a central location for storing the information to be accessed by web pages. This information could be a Connection String stored at a centralized location so that it can be accessed in a data-driven page. If the connection string changes its just a matter of changing it at one place.

In classic ASP such global information was typically stored as an application variable.

In the sample we'll read the information from web.config using ASP.NET and ASP as there could be a possibility of project having ASP and ASP.NET pages.

web.config:

Contains a key-value pair.
web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="ConnectionString1" value="server=localhost;uid=sa;pwd=;database=north wind" />
<add key="ConnectionString2" value="server=localhost;uid=sa;pwd=;database=pubs" />
</appSettings>
</configuration>

In ASP.NET:

We can just using Configuration.AppSettings(<key>) gives the Value.(Namespace:System.Configuration)

VB.NET

Dim strConnection As String
strConnection = ConfigurationSettings.AppSettings("ConnectionStrin g1")
Response.Write(strConnection)

C#

string strConnection;
strConnection = ConfigurationSettings.AppSettings["ConnectionString1"];
Response.Write(strConnection);

ThankQ
KiruthikaSambandam

Web.config

ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.

The <appSettings> element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings will change as you move your application from a testing and staging server into production.

As an example, let’s examine this minimal web.config with an appSetting entry to hold our connection string:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

<compilation defaultLanguage="c#" debug="true" />

</system.web>

<appSettings>

<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrate d Security=SSPI" />

</appSettings>

</configuration>

To read the key we use the ConfigurationSettings class from the System.Configuration namespace, as shown below.

private void Page_Load(object sender, EventArgs e)
{

string connectionInfo = ConfigurationSettings.AppSettings["ConnectionInfo"];
using(SqlConnection connection = new SqlConnection(connectionInfo))
{

connection.Open();
// perform work with connection
}

}

Some applications will duplicate these lines of code in many places. If we think about how the above code will evolve over time, we might see a handful of weaknesses. First, we have a hard coded string in place to fetch connection information from the web.config. Hard coded strings can be easy to mistype and difficult to track down if the key ever changes. Secondly, the code will tie us forever to the appSettings section of the web.config file. Although web.config is designed for just such a setting, we might find in the future that we need to pull configuration settings from a database, or change a setting from being application-wide to being a per-user configuration item kept in the Session or in a cookie.

Encapsulation

Let’s abstract away the source of the connection string using a class with a static property.

using System.Configuration;

namespace aspnet.config

{

public class Configuration

{

public static string ConnectionInfo

{

get

{

return ConfigurationSettings.AppSettings["ConnectionInfo"];

}


}

}

}

Now in Page_Load method looks like the following.

private void Page_Load(object sender, EventArgs e)

{

using(SqlConnection connection = new SqlConnection(Configuration.ConnectionInfo))

{

connection.Open();

// perform work with connection

}

}

The changes we made to the above code were relatively small - but powerful. Now the Page_Load function doesn’t know where the connection string comes from. We could easily change the ConnectionInfo property to retrieve the string from a different source without modifying any other code in the application. We also no longer have to remember the key string and hard code the string at various points in the application. Instead, we can utilize Visual Studio Intellisense when accessing the Configuration class to find the setting we need. The key value only appears once – inside the ConnectionInfo property – so we could again change the key name in the web.config and have only one line of code to update.

Of course this approach only works if all of the code in the application goes to the Configuration class instead of directly to web.config to retrieve settings. For each appSetting entry added to web.config we would add a corresponding property to the Configuration class.

Another advantage to this approach becomes apparent if we have an application setting that is not a string, but a date, integer, or other primitive type. In this case we could have the corresponding Configuration property parse the string from the web.config file and return the appropriate type.

You’ll notice we provided a read-only property for ConnectionInfo. The web.config file is not designed for constant updates. When an ASP.NET application launches a watch is put on the web.config file. ASP.NET will detect if the web.config changes while the application is running. When ASP.NET detects a change it will spin up a new version of the application with the new settings in effect. Any in process information, such as data kept in Session, Application, and Cache will be lost (assuming session state is InProc and not using a state server or database).

Next, let’s take a look at a little known feature of appSettings that can give us even more flexibility.

Multiple File Configuration

The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

<compilation defaultLanguage="c#" debug="true" />

</system.web>

<appSettings file="testlabsettings.config"/>

</configuration>

Next, we can create the external file ‘testlabsettings.config’ and add an appSettings section with our connection information.

<appSettings>

<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrate d Security=SSPI" />

</appSettings>

if the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.

The feature demonstrated above is useful when you keep user-specific or environment-specific settings in the external file. Let web.config contain those settings that are global to all the installed instances of your application, while each user or installed site contains their own settings in an external file. This approach makes it easier to move around global web.config changes and keep web.config checked into source control, while each developer can get their own settings separate.

I hope this answer has given you some tips on using the Web.config.

Thanks
Sathian.K

Appsetting is older fashion....Current versions are supporting the separate ConnectionString element to maintain the connection string in Web.config

<connectionStrings>
<add name="Conn" connectionString="Data Source=server;Initial Catalog=DB;uid=uid;pwd=password;"

the above connectin string is accessed by

ConfigurationManager.ConnectionStrings["Conn"].Name

Use the appSettings part of the Web.Config to store connection strings. This xml can then be modified anytime later and the next time a user browses to the site it will pick this new setting up.

One connection string is to Oracle and the Other is to SQL server

<appSettings>
<add key="ORACLEConnectionString" value="Provider=OraOLEDB.Oracle.1;
Persist Security Info=False;Password=blah;User ID=greg;Data Source=sph;" />
<add key="SQLConnectionString" value="data source=SQL1;initial catalog=ID_V;
integrated security=SSPI;persist security info=False;
packet size=4096"/>
<appSettings>


To get the values of the connections trings you would use

string conn = ConfigurationSettings.AppSettings["ORACLEConnectionString"];
OleDbConnection myConnection = new OleDbConnection(conn);


When the site goes live change the debug setting to false which will make the site have a little better performance.

<compilation defaultLanguage="C#" debug="true" />


Customer errors can be handled be turned off but I prefer them to be turned on as below.

<customErrors mode="Off" />


Or

<customErrors defaultRedirect="ErrorPage.aspx" mode="On">
<error statusCode="500" redirect="servererror.aspx" />
<error statusCode="404" redirect="filenotfound.aspx" />
<error statusCode="403" redirect="AccessDenied.aspx" />
</customErrors>


Application Tracing can be set up while shows the output times and all sorts of info of every page if you set it the values to true below. Local only would mean only onthe webserver hosting the site. You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.

<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime"
localOnly="true"/>

Thanks
Sathian.K

Specifying Classes of Application-Wide Settings

<configuration>
<configSections>
<section name="MyAppSettings"
type="System.Configuration.NameValueFileSectionHan dler,
System, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</configSections>

...
</configuration>

Note that the value of the type attribute of the <section ... /> tag must all appear on one line... the line breaks are in there for better formatting.

This <section ... /> tag indicates that we are going to be adding a custom tag named MyAppSettings. Now we can add a <MyAppSettings> tag to our Web.config file and add <add ... /> tags to add application-wide parameters, like so:

<configuration>
<configSections>
<section name="MyAppSettings"
type="System.Configuration.NameValueFileSectionHan dler,
System, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</configSections>

<MyAppSettings>
<add key="connString" value="connection string" />
</MyAppSettings>


...
</configuration>

Finally, to read this custom value from an ASP.NET Web page we use the following syntax:

ConfigurationSettings.GetConfig("MyAppSettings")(" connString")

Thanks
Sathian.K