Beginning ASP.NET 2.0 With CSharp (2006) [eng]

Chapter 16

This chapter discusses the following topics:

Deploying your site

Testing and maintaining your site

Where to now?

Site Deployment

Site deployment is the process of installing your site on the customer’s machine and making your site available and accessible to the outside world — in other words, broadcasting it to the masses. In the first versions of ASP, and indeed with any pure HTML site, the idea of deployment went little beyond “parcel up all your files in a zip file, and unzip them to the correct folder on the site.” For simple sites, this approach still works, but for more complex ones, you’re asking for trouble if you follow this method and expect no problems.

One of the weaknesses of Visual Web Developer is that, unlike Visual Studio.NET, there isn’t a special deployment wizard that can wrap all the different bits and pieces into a single installation file. However, there is an option in VWD that allows you to take your existing web site and publish the web site on a remote machine. There is also a second method that can be used if you prefer, which you learn about later in the chapter.

Before you do that, you should make sure you have everything necessary to ensure your site will work on another machine by compiling a checklist.

Checklist

Here’s a simple checklist of common things you would normally expect to feature in a typical deployment:

HTML and CSS files: Your design and structure.

ASPX files: Your main pages.

ASPX.VB or ASPX.CS files: The code-behind files.

ASCX and ASCX.VB/.CS files: The user controls.

Database files (.MDB or .MDF): The back end of the site.

Image files (.JPG, .GIF, .PNG): Easily forgotten but vital to the sites working.

Multimedia files: Includes both video and audio files.

XML files: .XML and .XSD files.

Third-party components or controls: ActiveX controls, Java applets, or such like.

License files: Required to make your components work.

598

Deployment, Builds, and Finishing Up

Quite often you will find that despite your best intentions, files can become spread out across folders all over your machine. It’s a great idea to centralize them first and even try to deploy them on another local machine of your own if you have one.

Compiling and Running Your Application

The next step is to make sure that your site actually compiles and runs. In Chapter 15, you looked at simple reasons why a site might not compile, and there is no point in deploying a site that doesn’t compile. Also be aware that even if your site happily compiles on your machine, it might not compile or run on your host’s or client’s machine. You must make sure that things like local references are changed so that file references are specific to the new machine and that the requisite components are installed. This is the most likely reason for your code failing on your host’s machine. The best way to do this is to place any machine-specific information within the Web.config file and then reference it from inside the appSettings, as discussed in Chapter 2. Then you can change any information in the Web.config file without affecting your application.

Say, for example, you put a reference to a folder in the <appSettings> section of Web.config and add a key and a value attribute as follows:

<appSettings>

...

<add key=”WroxUnited” value=”C:\Program Files\Wrox United” />

...

</appSettings>

You can then access these values from your code as follows:

string WroxULocation =

System.ConfigurationManager.Configuration.AppSettings[“WroxUnited”];

Of course, you will probably be faced with a scenario where you want to have a reference to a local file and also a reference to that same file in a location on your remote server. In this case, you can place a reference to both locations in Web.config. Here LOCALHOST is the active file location:

<appSettings>

<!-- LOCALHOST -->

<add key=”WroxUnited” value=”C:\Program Files\Wrox United” />

...

<!-- REMOTE

<add key=”WroxUnited” value=”D:\Websites\Wrox United” /> -->

</appSettings>

All you need to do then is uncomment the REMOTE settings and comment out the LOCALHOST settings instead. In this way, no code needs to change. Make sure you comment which of the locations is local and which is remote, because it might not be entirely obvious to anyone else who uses the code. If you have reason to change the location of the file, you only have to change it once in Web.config and not every time it is mentioned within your code.

599

Chapter 16

This doesn’t just stop with remote file locations, but also with connection strings. If you are using a local database to test your code, you will have to change the connection settings as well. Your local database might use SQL Express, but your main server might be SQL Server 2005 — once again, no extra code is needed, it can just be worked by commenting the line out:

<ConnectionStrings> <!-- LOCALHOST -->

<add key=”WroxUnitedConnectionString” value=”Data Source=.\SQLEXPRESS;AttachDbFileName=|Data Directory|\WroxUnited.mdf;Integrated Security=True;User Instance=True;” providername=”System.Data.SqlDataClient”/>

...

<!-- REMOTE

<add key=”WroxUnitedConnectionString” value=” Data Source=MainSQLServer;AttachDbFileName=|Data Directory|\WroxUnited.mdf;Integrated Security=True;User Instance=True;User ID=auser;Password=56gTR4£s “ providername=”System.Data.SqlDataClient” />

-->

</ConnectionStrings >

LOCALHOST in this example is the active string. If you changed the provider name, you could pass connection strings to other databases such as Access or MySQL or even Oracle.

Publishing the Site

After you’re sure that everything is ready and everything compiles, you can use Visual Web Developer to publish your web site for you. There isn’t much more to say on the subject — it’s literally easier to go ahead and do it.

1.Open the chapter copy of WroxUnited (C:\BegASPNET2\Begin\Chapter16\WroxUnited) and select the Web Site Copy Web Site option (see Figure 16-1).

Figure 16-1

600

Deployment, Builds, and Finishing Up

2.Click the Connections: Connect To box and enter WroxUnited2 into the text box, as shown in Figure 16-2.

Figure 16-2

Notice that to actually deploy to a remote site, you need to select the Remote Site icon on the left-hand menu and then supply the URL or IP address of the location of the site, possibly entering relevant user ID and password details in along the way. It is unfortunately not possible to supply test web space for readers to deploy their sites to.

3.Click Open and click Yes when asked whether you would like to create a new folder.

4.Select all the files, as shown in Figure 16-3.

Figure 16-3

601

Chapter 16

5.Click the blue single right-arrow button to copy the files across (see Figure 16-4).

Figure 16-4

6.Close the web site down, by selecting Close Project from the File menu.

7.Select Open Web Site and select WroxUnited2.

8.Run the new web site. It should look like the old one (see Figure 16-5).

Figure 16-5

602

Deployment, Builds, and Finishing Up

How It Works

In this Try It Out, you used the Copy Web Site option of Visual Web Developer to produce a complete, identical copy of the Wrox United site on your local machine. This mirrors the way in which you would go about deploying a web site to a remote location. In fact, if you have a remote machine that is also running ASP.NET 2.0, try deploying the Wrox United site on it yourself.

There really is very little to the physical act of deployment. The problems you may encounter are either caused by elements in your application that are locked in to your current setup (such as referencing files on a C:\ drive, when the host uses E:\ instead) or if you attempt to copy files into a folder or location where some files already exist. In this case, a blue question mark will appear next to the offending file in the left-hand dialog box, and you will get a dialog box (see Figure 16-6) that asks you whether you want to copy over the existing file.

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 had to do was 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. If you use third-party components (that is, separate executables), these should be installed separately.

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 here:

/ 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.

603

Chapter 16

/ 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:\BegASPNET2\Begin\Chapter16\WroxUnited

C:\BegASPNET2\Begin\Chapter16\WroxUnited3 /E

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

XCOPY C:\BegASPNET2\Begin\Chapter16\WroxUnited

C:\BegASPNET2\Begin\Chapter16\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).

604

Deployment, Builds, and Finishing Up

Figure 16-8

How It Works

The XCOPY option works in the same way as the Copy Web Site option in Visual Web Developer. It copies all of the files from one location to another. There are two main differences, however. The first difference is that you don’t need Visual Web Developer installed, 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, 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

You shouldn’t have any problems with the physical act of deployment itself. However, what happens if you correctly copy all of the files over, install all of the relevant components, and install the third-party ones, 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 were 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, which are worth talking about now.

605

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, in the same way as outlined next for the NETWORK SERVICE account. You can find more details about this in Appendix B.

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, select the Properties, and click the Security tab, which is shown in Figure 16-9.

Figure 16-9

606

Deployment, Builds, and Finishing Up

Here’s an 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 then turn off Simple File Sharing. To do this, double-click My Computer, click Tools Folder Options, click the View tab, and then select the Use Simple File Sharing (Recommended) check box. Then you can locate the folder whose permissions you want to change, right-click that folder, select Properties, and change the permissions.

Click the Add button to bring up the Select Users or Groups dialog box (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 box (refer to Figure 16-9), make sure the Write check box 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

This method 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 (note that you will need to log in to the database as an administrator first):

sp_grantlogin ‘NT AUTHORITY\Network Service’

USE aspnetdb GO

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

607