DEPLOYING, CONFIGURING, AND

CACHING APPLICATIONS

Deploying Web applications

After you’ve developed and tested your application, it’s time to deploy it to a production environment.

The deployment process can be automated with tools and scripts, managed and governed by IT departments, or deployed directly by developers through Microsoft Visual Studio.

Additionally, many Web developers must release their applications commercially; this means other people need to be able to deploy them in environments that the developer knows nothing about.

Configuring

There are times, when you might need more control over how your application gets deployed.

Check dependencies (such as particular operating system versions or service packs),

add registry entries for your application, download and install prerequisites, set security, add dependent dynamic-link libraries (DLLs), and so on.

Configuring

For all these purposes you will find a number of setup Editors of following types in the View menu of Visual Studio :

Launch Conditions Registry User Interface Custom Actions File System File Types

Launch Conditions

A launch condition is used to check the requirements for your application installation.

For example, you can check for specific versions of Windows or verify that specific service packs are present before you allow an install.

Launch conditions can provide a useful message to the user if a requirement is missing.

Launch Conditions

Following are the common launch conditions : File Launch Condition : if you want to verify

that a specific DLL is present Registry Launch Condition : search a target

computer for a specific registry key or value Windows Installer Launch Condition : to

determine if a specific package is installed .NET Framework Launch Condition : checks

the runtime version of the .NET Framework on the target computer

Internet Information Services Launch Condition : This searches for the presence of the right version of Microsoft Internet Information Services (IIS

Creating Launch Conditions To create and manage new launch conditions, you

use the Launch Conditions editor in the View menu.

There are two main branches of the Launch Conditions editor:• Search Target Machine• Launch Conditions

Typically, you must add an item to each of these two nodes.

For example, if you want to verify that a specific DLL is present, you must Add File Search under Search Target Machine and store the result of the search in a property. You then Add Launch Condition under Launch Conditions that uses the search condition’s property.

Adding a Simple Search Condition

To add a basic search condition, start by right-clicking the Search Target Machine node in the Launch Conditions editor. You will have three search condition types to choose from:

File Search This search type allows you to define a search for a file. You set the FileName to the name of the file you are searching for, the Folder to search, and the Property to a variable name you use for tracking the results of the search.

Registry Search This search type allows you to specify a registry search. You set the Root property to a place to start looking in the registry, the RegKey to a registry key to search for, and the Value property to a value you hope to be set for the given key. You store the results of your search in the Property property as a variable name that can be used in a related launch condition.

Windows Installer Search This search type allows you to search for a registered component. You set the ComponentId to a GUID of the component for which you are searching. You set the Property property to a variable that indicates the results of your search.

Adding a Simple Launch Condition

Right-click the Launch Conditions folder, and then select Add Launch Condition.

With the new launch condition selected, view the Properties window to configure your launch condition.

You can set the Condition property to match the Property value of a search condition or specify a different condition.

To download software to resolve the missing launch condition, provide a URL in the InstallUrl property.

In the Message property, type a message to be displayed to the person installing your Web application if a condition is not met.

Creating Pregrouped Launch Conditions

To create a grouped launch condition, you right-click the root node, Requirements On Target Machine.

Doing so simply creates both a search and a launch condition. However, these items are preconfigured to work together. You simply need to tweak their properties according to your needs.

Writing to the Registry as Part of Deployment

Although rare, there might still be times when you need to add registry entries during setup.

From the View menu, select Registry Editor.

To add a registry setting in a nested key, you need to add each nested key to the editor. For example, to add a setting to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\, you need to add the SOFTWARE, Microsoft, and ASP.NET keys to the HKEY_LOCAL_MACHINE hive in the Registry Settings editor.

Right-click the key to which you want to add a setting, select New, and then select String Value, Environment String Value, Binary Value, or DWORD Value. Type the name of the value, and then press Enter.

Adding a Custom Setup Page Administrators responsible for deploying and

managing your Web applications can also add custom setup wizard pages.

These pages enable you to perform the following types of tasks:

Display a license agreement A Web Setup Project provides a dialog box template for requiring the user to accept a license agreement.

Modify settings in the Web.config file You can use user input to modify configuration settings without requiring administrators to know how to configure an Extensible Markup Language (XML) file.

Adding a Custom Setup Page Perform custom configuration You can

use a custom configuration to prompt the user for information that might be stored in the registry or in another unusual location.

Activate or register your application You can prompt the user for a product key or registration information. Prompts can be either required or optional.

To add a custom setup wizard page to your Web deployment project, you use the View | User Interface Editor

Adding Custom Actions to Your Deployment

You add a custom action to your setup project through the View | Custom Actions Editor

The Custom Actions editor displays the four setup phases. You can right-click the phase to which you want to add a custom action.

You then select Add Custom Action. Doing so launches the Select Item In Project dialog box.

From here you can select to add a custom .exe or script file from current project or elsewhere to execute at the appropriate phase of deployment.

Custom Actions Phases Custom actions can run in any of the four phases

of setup:

Install This phase performs the bulk of the work done during setup

Commit This phase finalizes these changes. After the Commit phase, setup cannot be rolled back and the application should be uninstalled with Add or Remove Programs.

RollBack The Rollback phase runs only if setup fails or is cancelled. It occurs instead of the Commit phase and removes any new files or settings.

Uninstall This phase removes files and settings from the computer when the application is removed with Add or Remove Programs.

Deploying Web Applications Using a Web Setup Project

There are typically two generated to the target build directory for Web Setup Projects:

Setup.exe <Websetupprojectname>.msi

Although users are more familiar with using Setup.exe to install an application, the .msi file is smaller, far more versatile, and familiar to most systems administrators.

The only disadvantage to deploying the application with the .msi file is that the target Web server must have Windows Installer. Most Web servers already have this component, however.

Deploying Web Applications Using the Copy Web Tool

There are many scenarios in which you simply need to copy changes between two servers.

There might be some changes from your development environment up to staging or even from staging to production in some limited scenarios.

In these cases, you can use the Copy Web tool to publish changes between source and remote sites.

You can also use the tool to synchronize files. This involves copying only changed files and

detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited.

Deploying Web Applications Using the Copy Web Tool

To launch the Copy Web tool you typically open the Web site you intend as the source. Then right-click the site in Solution Explorer and choose Copy Web Site.

The Copy Web tool displays two panes: Source Web Site and Remote Web Site.

To set up a remote Web site, you must create a connection by clicking Connect at the top of the tool.

This launches the Open Web Site dialog box, which allows you to find a Web site.

Deploying Web Applications Using the Copy Web Tool

You can copy or synchronize files between the source and the remote Web site in several different ways:

Copy individual files in either direction Copy the entire site Right-click the Source Web

Site pane, and then select Copy Site To Remote. To copy the Remote Web Site to the source Web site, right-click the Remote Web Site pane, and then select Copy Site To Source.

Synchronize individual files Select files in either the source or remote Web site, and then click Synchronize Selected Files.

Synchronize the entire site Right-click the Source Web Site pane, and then select Synchronize Site.

Precompiling Web Applications To precompile and publish a Web application,

follow these steps:

1. Open the Web site you wish to precompile and publish.

2. Next, you can right-click your Web application in Solution Explorer and select Publish Web Site. Alternatively, you can select the Build menu and then choose Publish Web Site.

3. In the Publish Web Site dialog box, specify a location to which to publish.

Using caching to improve performance

ASP.NET caching stores frequently accessed data or whole Web pages in memory where they can be retrieved faster than they could be from a file or database.

Data that changes infrequently and is accessed by a lot of users is a good candidate for caching.

The first access of this data would load it into the cache; subsequent requests would be served from the cache until the cache expires.

Types of Caching There are two different types of caching in

ASP. NET:

Application caching : This represents a collection that can store any object in memory and automatically remove the object based on memory limitations, time limits, or other dependencies.

Page output caching : This is ASP.NET’s ability to store a rendered page, portion of a page, or version of a page in memory to reduce the time required to render the page in future requests.

Application Caching Application caching (also called application data

caching) is the process of storing data (and not pages) in a cache object. The cache object is available as a property of the Page object.

It represents a collection class of type System.Web.Caching.Cache.

The Page.Cache property actually uses an application-wide cache (and not just a page-specific cache).

This means that a single Cache object exists for your entire application; items in the Cache can be shared between user sessions and requests

Using the Cache Object

You work with the Cache object like you would Session or similar objects. You can assign items directly to the cache by giving them a name (key) and assigning them an object (value).

Cache["Greeting"] = "Hello, world!";if (Cache["Greeting"] != null)value = (string)Cache["Greeting"];elsevalue = "Hello, world!";

You wouldn’t normally cache a static string in your application; you’d more likely cache a file, a database query result, or other data that is shared and expensive to obtain.

Inserting Items into the Cache

The Cache object has both the Add and Insert methods.

Both define the same set of parameters and do the same thing behind the scenes.

The Add method returns the item added to the cache. The Add method is meant to comply with the collection interface.

The Insert method, however, has been the preferred method for adding items to the cache. It has a number of overloads based on the many parameters you can set when adding an item to the cache.

Cache Dependency

A cache dependency links a cached item to something else such as a file or another item in the cache.

ASP.NET monitors the dependency and invalidates the cache if the dependent item changes.

Cache.Insert("FileCache", "CacheContents", new System.Web.Caching.CacheDependency( Server.MapPath("SourceFile.xml")));

Setting an Absolute Cache Expiration

Many times you want to cache data for a specific amount of time.

This allows you to limit the amount of time between cache refresh.

To do so, you pass the absoluteExpiration parameter to the Cache.Insert method.

Cache.Insert("FileCache", "CacheContents", null, DateTime.Now.AddMinutes(10), Cache.NoSlidingExpiration);

Setting a Sliding Cache Expiration

Sliding expiration indicates the amount of time that must elapse between subsequent requests before an item is removed from the cache.

This allows most frequently used cached objects to stay in your cache longer

You set a sliding expiration by passing a TimeSpan to the slidingExpiration parameter of the Insert method.

Page output Caching

After a Web browser retrieves a page, the browser often keeps a copy of the page on the local computer.

The next time the user requests the page, the browser simply verifies that the cached version is still valid, and then displays the cached page to the user.

This improves the responsiveness of the site by decreasing the time required to load the page. It also reduces the load on the server because the server is not required to render a page.