Updating Deployed Asp.Net Applications

Among the tasks necessary to update Asp.Net applications, the three most common are:

1. Adding and Replacing Files
2. Modifying Web.config Files
3. Modifying Databases

In addition to these primary updating activities, there are many other activities that might be necessary to successfully update a server-based Asp.Net application, such as starting and stopping services, registering components, or even installing further prerequisites. In this lab, we’ll discuss how to use AppLife Update actions to accomplish these primary tasks as well as many of the update actions available to perform the ancillary tasks mentioned.

With AppLife Update, the update process that will be executed on deployed servers are defined using Update Actions. The work necessary to transform a deployed installation from one version to another is performed by a collection of update actions. These actions are easily configured, then compiled and built into an update package designated to target a specific set of previously deployed application versions. Let’s look at the actions available to accomplish the tasks necessary to update a deployed Asp.Net application.

There are many update actions available with AppLife Update to manipulate files, but the action that works particularly well for Asp.Net applications is the Add & Replace Files by Comparison action. It’s not uncommon for Asp.Net applications to have hundreds if not thousands of individual files. To update an existing application, we only need to include files that have been added or changed between the new version and the target previous version. That’s exactly what the Add & Replace Files by Comparison action does. As an update is built, the action compares two folder branches on your build system and adds to the update package any files that are new or changed. You can then target a folder on the deployed server that these files will be copied to as the update is executed on deployed servers.



In summary, when an update is built two versions of the Asp.Net directory structure are recursively compared, and any new or modified files added to the update package.

Web configuration files play a huge role in the configuration of Asp.Net applications. These files are unique to the specific server and can seldom, if ever, be replaced during an update. Instead, they must be manipulated or transformed in-place as necessary to support the new version. These files are xml based and AppLife Update comes with a collection of Update Actions designed to add and read Xml elements and attributes. These Xml actions are used during an update to manage your web.config files.

Using Shared Properties
An AppLife Update update process maintains a collection of name/value pairs called Shared Properties. Actions can create shared properties, read shared properties, and expand shared properties as a component of other properties. Shared properties can also be passed into the update process as an update is initiated.

Using shared properties, information can be shared between actions and actions can be conditionally executed based on their values. This is very useful when modifying configuration files, as it is often necessary to add elements only if they don’t already exist. Such a task can be accomplished by using a Read Xml action to determine whether the element exists, or get the existing value. This information can then be used as a conditional or input to another action.

Updating a database on a deployed system follows a pattern similar to this:

1. Gain exclusive access to the database (Single User Mode)
2. Backup the database (if practical, for insurance)
3. Run SQL commands in a transaction
4. Commit the SQL work
5. Return the database to service (Multi-User Mode)

The Deployed Database Applications solution lab discusses these steps in depth, and the information contained in that lab is relevant to an Asp.Net application that includes a database.

Updating Asp.Net applications will sometimes require starting and stopping services, registering com components, and modifying the registry. AppLife Update has built in actions to accomplish any of these actions.

IIS includes many command-line tools. To use these tools during an application update, the Run Command Line update action can be used. Other Windows based command line tools can be used as well, such as CACLS to manipulate access control lists.

When updating Asp.Net applications, you will inevitably need to perform a task for which there isn’t an update action available for. For these situations, AppLife Update provides a complete custom action infrastructure. When custom activity on the deployed system must be performed without any need to add files or information into the update package, the C#/VB.NET Code update action is the best choice. This action lets you define updating activity using c# or vb.net. The code action has access to shared properties through the update context object and can interact with other actions in the update using these shared properties.

For custom activity that must interact with the update build process, or when it’s desirable to easily add the activity to many updates, custom actions can be compiled into their own assembly and implement custom builders and editors. The solution lab on patching files provides an example of such an action.

When updating Asp.Net applications, user access to the application must be suspended as the update process is performed. There are multiple methods to accomplish this. The web site can be taken “offline” by placing an app_offline.htm file in the root of the web. With this file present IIS will serve any incoming request with that file. The web site can also be stopped, and then restarted. And perhaps most drastically, IIS can be stopped, and then restarted. To take an application offline or start/stop a web site, we have provided update actions in the Kjs.AppLife.Update.Web.Actions.dll assembly included as part of this solution lab attachment.

As an update is executed on a server hosting an Asp.Net application, each action in the update will log their configuration, and information about the work that they perform. This information can be used to verify that the update is performing as expected, and helps immensely in determining the cause of any issues with an update, both in development as well as in production. On development systems with AppLife Update installed, these logs can be viewed in the Log Viewer utility. The logs are written to the local application data folder of the user executing the update.

There are two common methods used to manage the discovery and initiation of updates on a deployed server.

• Server Utility Application
• Integrated Web Form

Using a server utility application requires a server administrator to log on and start the server utility. The utility includes the AppLife Update Controller, which checks for, downloads and initiates published updates for the currently running version. Using the utility application option, the update is executed under the security context of the logged on administrator. The benefit of this approach is a slightly simpler implementation. The disadvantage is that a server administrator is required to perform an update in an interactive server user session.

Alternatively, a browser-based updating user experience can be integrated into a web form using the Asp.Net WebUpdatePostbackDisplay control included in the solution lab download. Using this control, an application administrator, which does not have to be a server administrator, can perform and update process by browsing to an administrative web page in your application. When using this approach, the AppLife Update Elevation Windows Service must be deployed with your application to provide the update process with the permissions necessary to update your application. The advantage of this approach is that a server administrator is only required to install the application, after which an application administrator can maintain the application by applying published updates through a web browser. The disadvantage is a slightly more complicated initial install.

Both of these approaches are documented in the Asp.Net updating web help, and in the help file provided in the solution lab download.

Maintaining Asp.Net applications that are deployed to many servers provides challenges to a development team, and AppLife Update solves these issues. The long, intimidating manual updating procedures that often accompany the release of a new Asp.Net application version is time consuming to implement and provides a significant barrier to quick deployment of bug fixes and new features. AppLife Update provides the development team the right tool to mitigate these deployment issues by automating the process and providing their application users and administrators an extremely simple method to keep their applications up-to-date.

Download AppLife Update Here