The first round of ASP.Net Quick Tips was very successful. I have about 30 or so tips jotted down, but I am always looking for more. I am leaning towards doing them by theme/topic with state management/cache, data access, web controls, accessibility/standards, and tips from around the web are in the queue. But as the title suggests, today is all about the web.config.
Tip: *(#debug)Set debug = “false” before you go to production. *
This really is not a tip, it is a must. NEVER go to production with debug purposely set to true.
<compilation defaultLanguage=“c#” debug=“false” />
As ScottGu points out (click through for a lot information on the topic)
- The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
- Code can execute slower (since some additional debug paths are enabled)
- Much more memory is used within the application at runtime
- Scripts and images downloaded from the WebResources.axd handler are not cached
Tip: If you do not control your production environment, set your trust level to medium.
<trust level = “Medium” />
More and more ISP’s and server administrators are setting the ASP.Net trust level to medium. There are quite a few things you cannot do in ASP.Net while using Medium Trust. In most cases, you can work around this, but it is better to know while you are writing the code than when a customer sends you an error message that simply states their was a security exception. (In addition, the term security exception generally freaks them out).
One of the hardest tasks we ever had to complete on Community Server was to get it to function properly under Medium trust after we had written a substantial amount of code. Our checked in web.config now has the trust level set to medium which makes these issues very apparent as soon as they are created.
Note: By far, the most frequent case of medium trust issues is external HttpRequests. Under medium trust it is not possible to make an external HttpRequest without changes to your local policy or via a proxy. For Community Server, we recommend you use a proxy which is supported out of the box. Because of these extra configurations steps, out of the box, the Community Server web.config does not force medium trust.
Tip: Disable session state when not in use.
<sessionState mode=“Off” />
I will not get into the virtues/issues with session, but needless to say, most applications can be written to not use it (we make no use of session in Community Server). If you are not using it, turn it off. The overhead is minor, but it is something that happens on every request.
Tip: Disable ViewState
<pages enableViewState=“false” />
The usage of view state is way overrated. You almost never need it and even in times when you think you need it, you really do not need it. Viewstate is a wonderful concept but it also leads it self to huge unnecessary page requests. The common way it is abused is on databound controls (Repeater, DataList, DataView, and DataGrid). These controls are loaded on the initial page load. Something on the page requires a postback (either the databound control) or another form item. Instead of rebinding the controls, data stored in the ViewState is used.
- If the data is useful to more than one user, consider using the Cache API. This will save you multiple trips to the database and not force a heavy payload on the users
- If the data is not used by more than one user and does not require significant data processing, consider simply re-fetching the data from the database.
If you later find you simply cannot proceed without view state enabled, you can do so on a page by page basis:
<%@ Page Language=“C#” EnableViewState=“True” %>
Or is can be done per control:
<asp:DataView enableViewState = “true” …
Finally, keep in mind that controls like the TextBox do NOT need view state enabled to maintain their state.
Tip: Declare your Custom Server Controls
Declaring your custom server controls in the web.config allows you to skip the step of adding a Register directive at the top of any page which uses the controls. In addition, it adds a bit of consistency since the TagPrefix is always the same.
You can also do this for server controls defined in a web project, but you will need to explicitly set a namespace.
_Note: Hat tip to Lance Hunt who reminded me to use this tip._
Tip: Declare your User Controls
This tip is very similar to the custom server controls except for a slightly different syntax.
Tip: Know when to use configSource attribute
The configSource attribute lets you move entire sections of your web.config to another file.
<connectionStrings configSource=“connectionStrings.config” />
There are two main reasons for using this feature:
- It lets you isolate locally changeable sections which can make source code management easier. As an example, most of the core Community Sever development team works remotely. We do not use a shared database so everyone’s local database configuration/connectionstring is a little different. We chose to move our connectionstrings to a separate file which makes it very easy to skip during a checkin/merge.
- It just makes the web.config easier to read. It is very easy (especially with the new membership features) for your web.config to be quite long. As wonderful as XML is as a feature, it is still a PITA to read. Using configSource allows you to break it up into many smaller more readable chunks.
_Note: In my experience, ASP.Net generally does not reload the external configuration sections when they are modified. You will usually need to “touch” the web.config to see your changes propagated. _
Tip: Use ASHX files for HttpHandlers
Instead of configuring a path and type in the HttpHandlers section, simply add an ASHX file and use it instead. ASHX files have existed since ASP.Net 1.0, but were rarely used since inline intellisence was not available until Visual Studio 2005.
There are still times when you need to use the web.config method (a single handler for multiple paths, a different handler by verb, etc), but in most cases such as serving RSS or handling images you can very easily use the ASHX file.
In addition, you do not have to put the code inline. You can still place your handler code in a compiled assembly and then use ASHX file to wire it up. This makes it much easier to move a file around, use a rewriting engine like UrlRewriter.Net, or even an Isapi Filter since your web.config does not have to be changed when path is updated. We use this approach quite a bit in Community Server.
<%@ WebHandler Language=“C#” Class=“CommunityServer.Blogs.Components.WeblogRssHandler” %>
If you have any additional web.config tips, please add a comment below. Also feel free to ping me at email@example.com with any other tips you would like to see included in the next addition.