Determining a Servicing Strategy for Applications and Components
Once you have created an application or component you intend to run in side-by-side execution, you must decide how to update and service it. Because new versions of the runtime will be released and run in side-by-side execution, you must decide how to manage your application or component in this environment. In addition, you should plan how you intend to service your application or component with updates either by using in-place patches (thus replacing code), or by allowing multiple versions of the code.
The traditional model of servicing applications and components is to overwrite existing code with updates and fixes. This model changes with side-by-side execution. In addition to overwriting an existing file or requiring the uninstallation of an older version, side-by-side execution offers the following servicing options:
- Using an in-place patch of the application or component.
With this option, you should determine whether the in-place replacement will break the application or component. You should also realize that the user will be unable to back out any changes made by the in-place fix.
- Running the new version of the application or component side-by-side with the old version.
With this option, you can allow customers to opt out of an upgrade and simply run an application or component as they always have. You can also allow customers to return to the old configuration if an upgrade fails to perform as expected. However, using this option, customers could theoretically have multiple applications running with various levels of upgrades. If a critical fix were required, you would have to service all versions of the application or component. Because multiple versions of a particular piece of code may be installed simultaneously, it is often unacceptable to service only the latest version of a product.
It is important to balance the need for stability and the need to update and patch an existing application. It is impractical to service every version of a product. It is also impractical to expect every update to an application or component to be an in-place fix.