When to Use the Activation Context API

Help Home How-To

Quick start guide How to guides Advanced topics User interface Side-by-Side License information
Web Home Free evaluation Download the latest version

Activation Context API

Should you or should you not call the activation context (win32 side-by-side) API in your program? There is no simple and straightforward answer. There are at least two, seemingly conflicting, points of view.

Corporate administrators are in charge of configuring the entire Windows environment for tens of thousands of machines. They need as much flexibility as possible to be able to make everything work and to apply corporate standards.

Developers and third-party vendors need to ensure the stability of their applications. This includes making sure that the right components are used by their code.

What are the available options?

Use default Windows processing.

Windows has an elaborate mechanism for providing side-by-side support with no action on the part of the application. All that is needed is one or more manifests. These can be either external (*.manifest files) or embedded as RT_MANIFEST resources. In both cases corporate administrators can add external manifests to override the pre-configured processing.

Pros:

Cons:

Use ISOLATION_AWARE_ENABLED.

Create all the necessary manifests and embed them as RT_MANIFEST resources in applicable modules. Define this symbol for the compilation of all C/C++ modules. The code generated will automatically use your manifest for all side-by-side enabled Windows API calls.

Pros:

Cons:

Call the activation context API directly from code.

This option allows for the most power and flexibility while at the same is the most difficult and demanding.

Pros:

Cons:

Recommendations

The approach depends on the target environment, the complexity of the program’s requirements and the programmer’s commitment to the application (or component) servicing.

Home users and small businesses have no administrative expertise but are more prone to accidental configuration damage (for example by editing manifest files). The selected approach must be more resilient and there is no need for the client to change the configuration. Corporate environments have highly skilled, dedicated staff and may require the ability to configure the Windows desktop according to corporate standards. At the same time they have very elaborate automatic installation and healing processes in place and can ensure a correct configuration at any time.

Finally, the developer must understand that the moment they decide to use anything other then standard Windows processing, they must take the responsibility for configuring and servicing the application, or the component, through the product’s lifetime.

Environment: Corporate development for internal use.

If corporate administrators manage side-by-side
Use default processing with external manifests.
If the application requirements are simple or the programmers do not have sufficient side-by-side skills or languages in use are other then C/C++
Use default processing with embedded manifests.
If the default Windows processing is not flexible enough and the language in use is C/C++
Use ISOLATION_AWARE_ENABLED.
If requirements are complex and languages in use are other then C/C++
Use the activation context APIs.

Environment: Vendor development for outside clients or home / small business users.

If possible
Use ISOLATION_AWARE_ENABLED.
If requirements are simple enough
Use Windows default side-by-side processing with embedded manifests.
If the above is not sufficient
Use side-by-side API calls.


Read more...