Want to give your site the truly professional edge? Then refine it with this selection of optimization tips, error handling tricks, and other sneaky code techniques. From creating your own 404 Page Not Found messages to creating a super-fast page with a couple of caching keywords, it s all here. Starting with...
One of the big first questions that all those developing ASP.NET applications in Visual Studio .NET have is what s the deal with subfolders? I mean, if you ve used FrontPage or ASP to develop sites previously, creating a site subfolder simply involved putting your files in another directory.
But Visual Studio .NET still bases your Web application on the concept of a project. And, for Web applications, all core project files are in the same folder by default.
It s easily overcome , however. Just right-click on your project in the Solution Explorer and select Add New Folder. Give the folder a name , then right-click again and add new files to this subdirectory ”or drag and drop to move existing files to this folder.
It seems so simple when written like this, but the whole concept of dealing with subfolders trips up many of those new to Web applications. They don t all need to be in the same folder. And now you know!
By default, when you create a Web application, your files get stored in the IIS root Web site folder ”typically, c:\inetpub\wwwroot\ . But if you re like me, you won t like storing everything in that one folder. Rather, you have separate folders on separate drives housing separate projects.
How, then, can you get Visual Studio .NET to create and run a Web project from another directory?
Firstly, create the folder you wish to house your project. Next , we need to set this up as a virtual folder, a directory that looks as though it s running from the IIS root Web site folder yet is actually pointing elsewhere.
To do this, right-click on your folder in Windows Explorer and click on Properties. Select the Web Sharing tab and choose the Share this folder option. Enter an alias (see Figure 3-11), then click on OK to the dialog box, and OK again on the Properties page.
Your directory is now accessible via http://localhost/youralias/ (or you can replace localhost with your machine name). In other words, if you put an index.htm file in your newly created directory, it would be displayed when you type the above address into your browser.
Thirdly and finally, create a new Web application in Visual Studio .NET, specifying your new http://localhost/youralias/ address as the location. It ll get created in the folder you want. Not too difficult when you know how!
Download supporting files at www.apress.com .
The files for this tip are in the Ch3 ” Caching folder.
Some pages on your Web site will be awfully expensive to generate. By this, I mean that they take time for your server to put together: perhaps your page grabs the latest stock figures from an external site, perhaps it performs a long company calculation, perhaps it simply delves into your database and retrieves a news story.
Either way, it all takes expensive processor time, and it would be seriously useful if you could just cache those pages once they ve been generated and automatically serve that same page back up for a certain period of time. When the period is up, the page can then run its code once again and refresh.
This sounds like a great method of optimizing your site ”but perhaps not completely easy to implement. Well, actually, it is. In fact, to set the most popular form of ASP.NET caching into action, you ll need only one line of code. Here s how .
If you want to cache your page for, say, ten minutes, first open your ASPX page in Design mode. Next, click on the HTML button (or, from the menu, select View HTML Source). Just above the < %@ Page Language="vb" > directive, add the following line of code:
<%@ OutputCache Duration="600" VaryByParam="None" %>
This tells ASP.NET to cache the page after its first request for ten minutes (600 seconds). You can test caching by creating a page that simply displays the time as it loads, while incorporating an OutputCache directive with a short Duration attribute. Then, keep refreshing the page in your browser. Only after the set Duration will the time update itself.
You may be wondering what the VaryByParam attribute is all about. Well, it tells ASP.NET whether it should cache all requests for this page, or cache separate versions depending on whether the query string changes (in other words, if the parameters to the page change).
For example, if you want two versions of a page cached when someone requests article.aspx?id=10 and article.aspx?id=11 , then you ll want to change your OutputCache directive to
<%@ OutputCache Duration="600" VaryByParam="id" %>
Alternatively, if you want a version of the page cached whenever any parameter alters, simply use a wildcard, as so:
<%@ OutputCache Duration="600" VaryByParam="*" %>
Here, no matter whether you request article.aspx?id=12 or article.aspx?tag=loveshack , a different version of the page will be cached and reserved whenever requested again within the specified duration.
If you re interested in caching just portions of your page, it s interesting to note you can also use this technique in user controls. (See the The Secret Behind User Controls tip earlier in this chapter.) This could perhaps allow you to have certain parts of the page updated with every request, whereas other, more common elements simply refresh every hour or so.
A quick word of warning: be careful not to overuse caching. Used wisely, caching can greatly increase the performance of your Web applications. Used in a crazed, insane fashion ”say, on a free text search page ”it ll bring your server to a grinding halt.
You can learn more about ASP.NET caching by looking up ASP.NET caching in the help index. Surprising, that.
It s terrible when it happens ”but, rest assured, it will happen. You see, debugging Windows programs is a pretty simple process and one not prone to failure. But debugging Web applications is much more fallible.
So, what should you do if you attempt to start debugging a Web application and get the dreaded Unable to start debugging on the Web Server error? Here s your one-stop checklist:
Are you working offline in Internet Explorer? Launch Internet Explorer and look in the File menu. If Work Offline is checked, click on it to deselect the option, restart Visual Studio .NET, and try again.
Does Web.config have any syntax errors? If it does, you won t be able to start debugging. To check this, click on Debug Start Without Debugging and see if your browser reports an error. If it does, fix it and try again.
Are you sure you re running Windows 2000, Windows 2003, or Windows XP? If so, continue to the next step. If you re debugging a remote ASP.NET application under Windows NT4, you ll need to launch the application without debugging, then manually attach to it. Look up debugging ASP.NET Web applications, system requirements in the help index for more information. A word of advice: upgrade .
Are you a member of the Debuggers Users group? You may be logged on as Administrator, but it s still worth checking. If you re not in the group , you may be denied your debugging rights.
Does your Web.config file have its Debug attribute set to True ? If not, you re going nowhere. You might also want to check that the Configuration Manager lists your project as Debug and not Release. (Use the dropdown box on the standard menu to alter, or choose Build Configuration Manager.)
When you created the project, did you specify an IP address rather than a machine name? If so, launch Internet Explorer, choose Internet Options, select the Security tab, and add the IP address to the list of trusted sites. Then try again.
Did you install IIS after Visual Studio .NET? If so, you ll need to do a little fixing. Use the help index to look up installing Internet Information Server . Midway through the software requirements, you ll find instructions telling you how to install IIS. It also provides advice on configuring and repairing IIS after installing Visual Studio .NET. Follow the guidelines.
Are the IIS security settings set up properly? You can check this by launching the Internet Services Manager in Windows 2000/2003, or Internet Information Services in Windows XP (found under the Administrative Tools option on the Programs menu). Navigate to your Web server, locate the Default Web Site node, right-click and select Properties, choose the Directory Security tab, and select Edit. Ensure that Anonymous Access and Integrated Windows Authentication are checked, then click on OK in all open dialog boxes.
And finally, is the Web application virtual folder set up correctly? You can check this by launching the Internet Services Manager in Windows 2000/2003, or Internet Information Services in Windows XP. Navigate to your Web server, expand the Default Web Site node, and find your application folder in the list. If it looks like regular Windows Explorer, it hasn t been set up correctly. To fix this, right-click on the folder, select Properties, click on the Create button, and then click on OK to save.
One of the most beautiful features of ASP.NET is its rich error reporting. When something goes wrong, it highlights the exact lines of offending code, provides an explanation of the problem, and, if it s feeling merry, even suggests a solution from time to time.
The problem is that you really don t want your visitors viewing code behind your applications. For a start, it may breach your site security. For seconds, it s just not pretty . So, how do you stop it from happening?
First off, stop telling VS .NET to create the debug file containing a copy of your code. You can do this by altering the application mode from Debug to Release. Use either the dropdown box on the standard VS .NET menu for this, or select Build Configuration Manager and edit through the dialog box. Next, turn off debugging by editing the Web.config file so the < compilation > element reads < compilation debug="false" / > .
Well, that may stop your code from appearing, but it won t get rid of those awful generic error pages. You can, however, replace them with your own, slightly more elegant apologies. Simply alter the < customErrors > element in Web.config to something like < customErrors mode="On" defaultRedirect="genericerror.aspx" / > . (See Figure 3-12.) No problem!
|TOP TIP|| |
With a defaultRedirect, ASP.NET automatically passes the filename of the page that generated the error in the query string, as a parameter called aspxerrorpath . You may wish to use this in your error page, perhaps to suggest an alternative page or log the request to an errors file.
Download supporting files at www.apress.com .
The files for this tip are in the Ch3 ” Page Not Found folder.
In the last tip, we discovered how to stop your code being displayed when an error occurs. We also found out how to redirect the user to a certain page when such problems arise. Well, this also kicks in with such irritations as the dreaded 404, Page Not Found .
In those situations where a requested page is not found on the Web server, you might want to display your own custom message rather than a generic error message. You can do that easily, just by expanding the < customErrors > element of your Web.config file.
The following snippet shows part of an edited Web.config file that redirects to genericerror.aspx when regular errors occur, or 404.html when a file not found occurs (see Figure 3-13), or 403.html when a permission-denied server error occurs.
<configuration> <system.web> ... <customErrors mode="On" defaultRedirect="genericerror.aspx"> <error statusCode="404" redirect="404.html" /> <error statusCode="403" redirect="403.html" /> </customErrors> ... </system.web> </configuration>