Ce fichier permet de définir pour une application ASP.NET ou pour un répertoire particulier de celle-ci. Il comprend divers paramètres comme le type de compilation, le type d'authentification, la manière de garder la valeur des variables de sessions, ... Il est également possible d'y placer des valeurs qui sont ainsi modifiables sans recompilation de l'application. Un Web.config bien configuré permet, tout comme le Global.asax, de simplifier la mise en oeuvre de l'application ainsi que d'améliorer les performances.

Il est possible de placer un fichier Web.Config par répertoire. La portée du Web.Config est ainsi ce répertoire et tous ses sous-répertoires sauf si un autre fichier Web.Config se trouve dans un de ses sous-répertoires. Dans ce cas, le Web.Config correspondant sera pris en compte.

Pour changer le timeout d'une application web, dans le fichier web.config :

<configuration> 
	<system.web> 
		<customErrors mode="Off"/> 
		<compilation debug="true"/> 
		<httpRuntime maxRequestLength="8096"   executionTimeout="600"/> 
	</system.web> 
</configuration>

Si vous voulez modifier le timeout d'une seule page, au début de la page aspx :

<% 
Server.ScriptTimeout=200 
%>

Dans votre fichier web.config, par défaut vous avez :

<configuration> 
	<system.web> 
		<httpRuntime maxRequestLength="4096" /> 
	</system.web> 
</configuration>

Si ceci ne s'y trouve pas, la valeur 4096 est prise par défaut.

Il faut changer la valeur de httpRuntime maxRequestLength suivant vos besoins.

La réponse se trouve dans le Web.Config au sein du tag customErrors. Ce tag a diverses propriétés dont, entre autres, le Mode. Celui-ci peut valoir
- On: les erreurs personnalisées sont activées. Si la valeur de la propriété defaultRedirect n'est pas redéfinie, les utilisateurs reçoivent une erreur générique
- Off: les erreurs détaillées sont affichées
- RemoteOnly: spécifie que les erreurs personnalisées ne sont affichées qu'aux utilisateurs distants. Les erreurs ASP.NET sont affichées sur le localhost. Il s'agit de la valeur par défaut.

Ces deux fichiers sont les seuls qui ne sont pas compilés dans une application web. On serait ainsi tentés de télécharger les fichiers pour essayer un quelconque piratage. Alors est-ce possible? La réponse est non. Ils sont automatiquement configurés pour éviter ce genre de choses.

Non. D'ailleurs dans VS.NET 2005 il n'y est pas d'office. Dans ce cas, le fichier de config pris en compte est le machine.config.

Par défaut, lorsque le navigateur est Internet Explorer, IIS envoie des tags formattés différemment que lorsqu'il s'agit de Firefox ou tout autre navigateur. (les largeurs de composants ne sont pas toujours envoyées à un client Firefox)

Pour éviter cela, il est possible de préciser dans le web.config d'envoyer des tags identiques quelque soit le navigateur. Il faut donc ajouter un fils au noeud "system.web".

<browserCaps>TagWriter=System.Web.UI.HtmlTextWriter</browserCaps>

Dans le fichier web.config de votre application :

<configuration> 
	<system.web> 
		<customErrors defaultRedirect="erreurinconnue.htm" mode="RemoteOnly"> 
			<error statusCode="500" redirect="500.htm"/> 
			<error statusCode="404" redirect="404.htm"/> 
		</customErrors> 
	</system.web> 
</configuration>

Il existe plusieurs réponses possibles à cette question:
1° dans le code, à chaque fois que l'on crèe un objet XXXConnection
2° dans le code, dans une variable statique dans chaque page
3° dans le code, dans une variable statique et publique dans une des pages
4° dans le Global.asax
5° dans le Web.Config
6° un mix des deux dernières solutions

De 1 à 3, ce sont des solutions à proscrire car toutes modifications sur la base (changement de serveur, changement du mot de passe ou du login ou encore du type de sécurité mise en place) nécessite une recompilation de toute l'application.

Pour le point 4, la solution est très interressante car il est possible de définir une variable statique comme ci dessous:

Public Shared ConnectionString As String = "la chaine de connexion"

L'appel dans le code se fait alors par:

Dim cs As String = Global.ConnectionString

Cependant toute modification du fichier nécessite un redémarrage de l'application (effectué implicitement).

Le point 5, avec l'utilisation des attributs <appSetting> est très interressant puisqu'il est possible de modifier la valeur à chaud, sans redémarrage de l'application.

Pour lire la valeur:

System.Configuration.ConfigurationManager.AppSettings("clé")

A chaque appel, il y a un accès au fichier Web.Config. + !! probleme de string !!

En utilisant les avantages de l'un et de l'autre, on arrive à la situation suivante:
On ne lit qu'une fois le Web.Config et on garde la valeur en mémoire, à l'aide d'une variable au sein de la classe Global.