Beginning ASP.NET 2

Deployment, Builds, and Finishing Up

Figure 16-6

Before .NET, if you needed to install a component or control, this would require copying your component to the appropriate folder and registering that component via some ugly low-level tools we don’t want to talk about here. In .NET, to install the component all you have to do is to copy the component’s file into the bin folder of your application which occasionally had some unexpected and unpleasant side-effects, however in .NET 2.0 dropping components into the App_Code folder is all you need to do to be able to start using the component immediately.

XCOPY Deployment

There is a second way to deploy applications in .NET, if you don’t have Visual Studio.NET. This is known as XCOPY deployment. This is a command-line tool that can be used to copy your site from one location to another. It takes a number of options, as detailed in the next section.

XCopy Options

/ E copies folders, subfolders, and files, including empty ones.

/ H copies both hidden files and system files in addition to the unhidden and non-system files.

/ I specifies that the destination is a folder and to create the folder if it does not already exist.

/ K keeps all of the existing file and folder attributes such as read-only, which would otherwise be lost.

/ O retains all of the security-related permission ACLs (Access Control Lists — rules for who gets access to a particular resource) of the file and folders.

/ R overwrites files marked as read-only.

All you need to do is provide the location of where you want to copy the web site from and where you need to copy the web site to, and along with the relevant options, it will copy everything that you need. So typing in the following command would copy all files and folders to the WroxUnited3 folder:

XCOPY C:\Inetpub\wwwroot\WroxUnited C:\Inetpub\wwwroot\WroxUnited3 /E

You can see how that works in the following Try It Out.

609

Chapter 16

XCOPY C:\Inetpub\wwwroot\WroxUnited C:\Inetpub\wwwroot\WroxUnited3 /E

3.You are presented with the screen shown in Figure 16-7, and asked whether the target is a file name or directory. Press d because it is a directory. XCOPY will now copy all the files over.

Figure 16-7

4.Close the command prompt.

5.Open Visual Web Developer, choose File Open Web Site, and select WroxUnited3.

6.Run the new web site; it should look just like the last one (see Figure 16-8).

610

Deployment, Builds, and Finishing Up

Figure 16-8

How It Works

The XCOPY option works in the exactly the same way as the Copy Web Site option in Visual Web Developer. It copies all of the files from one location to another. The two main differences are that you don’t need Visual Web Developer installed to do it, which is useful if you have been forwarded a web site from someone else in a zip file and want to, say, install it locally and test it and then deploy it. The second difference is that because it is a command-line tool it gives you more options on which files to copy and which files not to copy, with settings like /R to overwrite existing files that are marked as read-only.

Common Problems Encountered When Deploying a Site

So, you shouldn’t have any problems with the physical act of deployment itself. However, what happens if you copy all of the files over, install all of the relevant components and install the third-party ones, and do it correctly and deployment still doesn’t work?

With a fairly new technology it’s harder to compile a definitive list of problems, bugs, and glitches the user might experience; these things are put together from years of user frustrations. However, on our travels in the beta versions of ASP.NET 2.0 we came across a couple of gotchas that could break your site that are worth talking about now.

611

Chapter 16

Enabling App Data Permissions

If you are getting errors whenever the user runs a page that accesses a database, then suspect permissions problems immediately. Every time you move a database to a new server that uses SQL Server, you have to set up the relevant permissions for the NETWORK SERVICE for the App_Data folder. The reason you have to do this is ASP.NET 2.0 runs under this particular service, and so if ASP.NET 2.0 wants to access the database, a request to access it will come from this particular service.

In ASP.NET 1.1 you would add permissions for the ASPNET account to do this; in ASP.NET 2.0 the NETWORK SERVICE account does the same. However, there have been occasions in the beta where enabling NETWORK SERVICE didn’t work and ASPNET permissions had to be enabled as well. If, after enabling permissions for NETWORK SERVICE, things still don’t work in the way intended, you might want to enable permissions for the ASPNET account as well, in the same way as outlined next for the NETWORK SERVICE account.

You can enable these permissions in two ways, either via Windows Explorer or via SQL Server Enterprise Manager.

Enabling Permissions via Windows Explorer

Go to the folder of your web application in Windows Explorer, right-click your application and select the Properties, and click the Security tab, which is shown in Figure 16-9.

Figure 16-9

612

Deployment, Builds, and Finishing Up

Important note for Windows XP Home Edition users: There is no Security tab visible because something called Simple File Sharing is enabled by default. To turn off Simple File Sharing, you need to restart your PC in Safe Mode (by pressing F8 before XP starts) and then log in as Administrator. You’ll get a warning about running in Safe Mode. Click Yes to accept it and locate the folder whose permissions you want to change, then right-click that folder, select Properties, and change the permissions. You can find more details about this in Appendix B.

Click the Add button to bring up the Select Users or Groups dialog (see Figure 16-10). Type Network Service and click Check Names (if you don’t type in the correct case, it will capitalize the name for you).

Figure 16-10

Click OK. In the Properties dialog (refer to Figure 16-9), make sure the Write checkbox is checked (it is unchecked by default) and click Apply. It’s as simple as that.

If the machine is joined to a domain, the user must select the Locations button and pick the current machine, rather than the domain. That’s because NETWORK SERVICE is an account on your machine. By default the dialog will attempt to add the domain name, rather than the machine name.

Enabling Permissions via SQL Server Enterprise Manager

The alternative way will only work if you have SQL Server installed. If you bring up SQL Query Analyzer you can run the following script (just type in the following code to SQL Analyzer), substituting in the name of the database you want to grant access to:

sp_grantlogin ‘NT AUTHORITY\NETWORK SERVICE’

USE aspnetdb GO

sp_grantdbaccess ‘NT AUTHORITY\Network Service’, ‘NETWORK SERVICE’

USE aspnetdb GO

sp_addrolemember ‘database_you_wish_to_grant_access_to, ‘NETWORK SERVICE’

613

Chapter 16

Click Run to run the query, and this will have the same effect as the previous instructions.

Is Your Application Offline? (Using App_Offline.htm)

This is one of those things that I saw in the beta that really tripped me up; on one occasion I ran my Wrox United application to test it and was staggered to find that every single page returned an HTTP 404 error. Even stranger, I was browsing them from within Visual Web Developer at the time. It took me a few hours and help from the other people on the book to figure out what had happened. It actually turned out to be a really useful feature.

If you need to take your site offline very quickly, you can place a file called app_offline.htm in your main application folder to make your web site unavailable to everybody. You can place in the HTML file the text that you want your users to be able to view for the duration of the site’s downtime. The advantage is that ASP.NET is working throughout this downtime, and you are able to test the site without having to worry about what users can see in the outside world. However, there are times when this file is created for you, which led to the problems I had.

Apparently during some operations, the app_offline.htm file is temporarily copied to your application folder and then in theory it should be removed when the operation is completed. A crash during an operation can leave the file behind. Unfortunately, this was a zero-length file in beta 2, and this provided no clue to the user as to what occurred. The user was just left with every single page in his or her site returning 404 errors. Normally, the app_offline.htm file should not be left behind, but unfortunately in some cases it gets left over. In the final release of ASP.NET 2.0 there is a message informing users of what happened so they know to remove the offending item (see Figure 16-11).

Figure 16-11

This can turn up quite a few times if your application is being unruly, so be warned. It will turn up in the root folder of your application folder. In Figure 16-11 you see the version of it that comes with Visual Web Developer by default.

Trial and Error

If there’s still no joy, go back, delete all the files, and try it again. If you are getting a particular error consistently, look up that error on http://support.microsoft.com and see if that has any solutions. If not, try posting on one of the online forums recommended later in this chapter.

614

Deployment, Builds, and Finishing Up

Testing and Maintenance

Once you’ve successfully negotiated deployment, you might be excused for doing a quick double take. Testing, haven’t you already done that? Given this is the 21st century you would have perhaps expected attitudes toward testing to have improved considerably; however, if anything, trends have reversed. I can name-check several very popular games that arrived on the market in a practically unusable state because they hadn’t been tested correctly. Hastily compiled patches of 20–50MB were required to rectify the situation. However, as a developer you will probably not have this luxury. You will probably see your client week in and week out, and if the application doesn’t work they will tell you about it and maybe withhold payment until the problem is rectified. They might still not grant you any extra time to test, but that is the name of the game.

Testing Before and After

Of course while you’re building an application you should test every component, but once the build is deployed and completed you should also make time to test the application as a whole. In particular, you should sit alongside your prospective users and watch them test it. Some clients believe that testing is the whole responsibility of the developer, but the relationship the developer shares with his code is similar to that between the author and his text. You wouldn’t expect an author to be able to adequately edit his own text, and if an author uses incorrect grammar, then it’s quite likely that he won’t be able to spot their own incorrect grammar usage. If a developer creates a piece of logically unsound code, there’s a fair chance he might not be able to spot it either. Only in hard testing, when a user who puts

in often totally unpredictable values, are some errors revealed. Some textbooks will tell you to put aside as much time as you took to develop the application for testing it. This isn’t over-cautious; the bigger the application, the greater the likelihood of bugs creeping in, and the longer it can take to find them.

If possible with a web site for a client, get them to test it in-house, on a test server before they put it on a live server. And don’t be worried to admit to bugs. Finding bugs isn’t the sign of a bad developer; a bad developer is one who refuses to admit to the possibility of any bugs in the first place. The best advice

I can give is get your clients to test the application thoroughly and make sure they have time to do it. A couple of testing methods are worth mentioning here.

Unit Tests

Unit tests are a particular form of testing where you write a test for every non-trivial function or method in the code. You can separate out the different sections of the program and demonstrate which parts are working in this way. Unit tests make it easier for programmers to change individual pieces of code because they can go back to the code and test the unit independently. So if you suddenly think of a new feature, you can add it without worrying about having to break the entire application.

Writing a Test Plan

Because unit tests, or indeed the whole practice of testing, can be time consuming, it’s best to have a test plan up front to aid the organization of testing. A test plan is simply a systematic written approach to testing, detailing the experiments and tests you want to perform on the code. Test plans don’t just apply to computer programs; they can apply to any kind of engineering. A single test case in a test plan for a dishwasher might be, “Test what happens when you open the dishwasher door halfway through a working cycle.” Some dishwashers would shower you with scalding water, some would refuse to open, and some would stop mid-cycle and let you retrieve the last cup in the house. There isn’t necessarily a right answer to what should happen, but you should write a list of scenarios that you would like to test,

615

Chapter 16

and record the outcomes and check that the scenarios and outcomes are what you both want, and what your end-user thinks is satisfactory.

Maintenance

Maintenance is the practice of keeping your site up and running once it has been successfully deployed. In some ways it’s like a glorified debugging process — some bugs might not show up until long after the site’s deployment, but you’ll still be expected to fix them. In other ways maintenance will be about performance monitoring: how fast is your site running? How many users is it handling? Can it cope with that? This is a science in itself. This is one area where ASP.NET 2.0 has come on in leaps and bounds, with the addition of instrumentation, and the capability to instrument your application.

Instrumentation and Health Monitoring

Instrumentation or instrumenting is a term you will come across if you have to do any monitoring or maintenance of your system. It doesn’t refer to anything musical, though. Rather, the instrumenting of your application is the monitoring of your system or your application’s function, checking to see that all is working the way it should be.

ASP.NET 2.0 has a lot of instrumentation features for the developer. You’ve already looked at the ability to run traces and logging and learned that there are performance counters that you can use, but are beyond the scope of this book. However, there is another new feature that is of great interest and of particular use after your application has been deployed, and that is the introduction of the

<healthMonitoring> element.

The <healthMonitoring> element can be used at system or application level and allows you to monitor when specific events have occurred and write notifications of these events to either an event log, a SQL Server database, or even to e-mail the administrator. Events that might be of interest could be a failed login, or an error occurring in the application. Besides logging events the <healthMonitoring> element allows you to test the “health” of the system via a heartbeat attribute, which sets up an event that is generated at a predefined interval — if you can “hear” the heartbeat, you know your application is working fine. If you don’t receive this heartbeat, you know there might well be problems.

To enable health monitoring, all you need to do is place the <healthMonitoring> element in your Web.config file and set the enabled attribute to true. Health monitoring is handled by three elements within <healthMonitoring>, which have a close relationship with each other:

The <providers> element specifies where you want to send the information you have collected; this can be an event log or a database.

The <rules> element specifies the name of the provider you want to write your information to and the event name you want to instrument.

The <eventMappings> element specifies a name of event you want to monitor, and maps it to an actual event or set of events. The settings of this element must correspond to a valid event type. A list of valid types is contained within the <eventMappings> element in the

Web.config.comments file.

It just takes a couple of attribute changes to alter an application that writes to the event log for failed logins, to one that e-mails the administrator with details.

616

Deployment, Builds, and Finishing Up

Monitoring for Events

You can test for a range of events using the <healthMonitoring> element. These are as follows:

617

Chapter 16

There is also a broad range of providers (sources) to which you can write your event information. These can all be found in the System.Web.Management namespace, and are detailed in the following table:

Which Events Are You Interested In?

So you have a list of events, and a list of possible places where you can write the events about how they were monitored. However, at the moment this is information overkill; you need to get back to basics and answer a simple question: Which events are you interested in monitoring?

Unfortunately, the answer is open-ended. This depends on what you want to monitor your application for. A lot of the events in your list generate huge numbers of events, both when working correctly, or when the application isn’t.

A good place to start would be security. If you aren’t regularly changing code in your application, then most likely the greatest threat to your application’s longevity and well-being is someone trying to hack. A key to finding good security events to instrument for is to locate which events under normal circumstances shouldn’t be generating a large number, but in the event of an attack or suspicious data being provided, will generate a lot of events. When your system is being attacked, you are likely to see a number of such events, which in turn can help act as an early warning system.

The key events that monitor the security-related aspects of the application might be as follows:

WebErrorEvent

WebAuthenticationFailureAuditEvent

WebRequestErrorEvent

WebViewStateFailureAuditEvent

The WebError event should be monitored because any code failure is suspicious; the WebAuthenticationFailureAuditEvent should be monitored because any suspicious login activity should be carefully monitored. The last two might have failures if a hacker is trying to intercept responses from the server and forwarding his or her own fraudulent page in response. By default, the

WebErrorEvent and WebAuthenticationFailureAuditEvent are turned on. This means that in the case of any failure they are automatically logged to the Event Log. So if such an error (for example, a division by zero error) occurs in your application you would see what’s shown in Figure 16-12 in your Event Log under Application, under the source ASP.NET version.

618