Theory
Where do the settings go?
FestConnect needs a database connection string, and probably a few other settings: an admin email, a page size, whether the site is in maintenance mode. Where should these live? Not buried inside your compiled C#, because then changing the database server would mean editing code and rebuilding the whole app.
ASP.NET's answer is web.config: a single settings file for the application. This lesson covers what it holds and why keeping configuration out of code is such a good habit.
Theory
What web.config is
web.config is an XML file that configures your ASP.NET application. It sits in the application's root folder (and any subfolder can have its own to override settings for that area).
Among the things it commonly holds: connectionStrings (how to reach the database), appSettings (your own custom key-value settings), authentication and authorization rules (who may access what), custom error pages, and session settings. It is the one place to look for how the app is configured. Crucially, ASP.NET reads it at runtime, so changing a setting does not require recompiling the code.
Practical
A slice of FestConnect's web.config
<configuration>
<connectionStrings>
<add name="FestDb"
connectionString="Server=.;Database=FestConnect;Trusted_Connection=True;" />
</connectionStrings>
<appSettings>
<add key="AdminEmail" value="admin@festconnect.example" />
<add key="EventsPerPage" value="10" />
</appSettings>
</configuration>This example runs in Gri-Learn on the web, where you can edit it and see the output.
Practical
Reading those settings in code
// Read the connection string by name (not hard-coded in the C#)
string cs = ConfigurationManager.ConnectionStrings["FestDb"].ConnectionString;
// Read a custom setting
string adminEmail = ConfigurationManager.AppSettings["AdminEmail"];
int perPage = int.Parse(ConfigurationManager.AppSettings["EventsPerPage"]);Formula
Configuration, not code
The point of web.config is to keep configuration separate from code. Settings that might change, especially between your development machine and the real server, live in the config file, and your code reads them by name.
So moving FestConnect to a new database server is a one-line edit in web.config, with no code change and no rebuild. This is the same 'define it once, in the right place' principle behind code-behind and master pages, applied to settings.
Quiz
Why keep the database connection string in web.config instead of writing it directly in your C# code?
- Because C# cannot contain text strings
- So the connection can be changed without editing or recompiling the code, and it lives in one known place
- Because web.config runs faster than code
- Because connection strings are not allowed on the server
Show the answer
So the connection can be changed without editing or recompiling the code, and it lives in one known place
Keeping the connection string in web.config means you can change it, for example when moving to a different database server, by editing the config file alone, with no code change and no recompile, and everyone knows the one place to find it. Option A is nonsense: C# handles strings fine; the issue is maintainability, not capability. Option C is wrong: web.config is a settings file, not something that 'runs faster'; performance is not the reason. Option D is invented. The real benefit is separating configuration from code: settings that vary (especially between your machine and production) belong in config, read by name at runtime.
Think first
What breaks when you hard-code settings into the app?
Suppose you paste the connection string straight into your C# on every page. What goes wrong later? Then tap.
Show the answer
Several painful things. First, MOVING or CHANGING becomes a code edit: when you deploy FestConnect from your laptop to the college server, the database address changes, and now you must hunt through the code, edit every hard-coded string, and REBUILD the whole application, instead of changing one line of config. Second, DUPLICATION and DRIFT: if the connection string is pasted in many files, you will eventually miss one, and part of the app talks to the wrong database. Third, SECURITY and SEPARATION: mixing environment-specific secrets into compiled code makes them harder to manage and to keep out of source control. Centralising the setting in web.config fixes all of this: one authoritative value, changeable without recompiling, read by name wherever it is needed. It is the configuration version of a single source of truth, the same reason you separated layout from logic and centralised styles. Never hard-code what is going to change.
Summary
Key takeaways
- web.config is an XML configuration file for an ASP.NET application, in the app root (subfolders can override).
- It holds connectionStrings, appSettings (custom key-value settings), authentication and authorization rules, custom error pages, and session settings.
- ASP.NET reads it at runtime, so changing a setting needs no recompile.
- Read settings in code by name: ConfigurationManager.ConnectionStrings[...] and ConfigurationManager.AppSettings[...].
- The benefit is separating configuration from code: change the database or a setting without editing or rebuilding the app.
- Hard-coding settings causes code edits on every move, duplication and drift, and security problems.
- Memory hook: web.config keeps the things that change out of the code.