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:
- Simple to use, easy to configure.
- Gives corporate administrators full control over the configuration.
- No code changes are needed.
- Can be applied to third part applications and components.
Cons:
- The configuration is easier to damage (manifests are plain text files).
- Does not allow for complex, and possibly conflicting, dependencies among components.
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:
- Relatively simple to use, no extra code is required.
- Allows each module (EXE, DLL) to define own, possibly conflicting with others, isolation requirements.
- Performs strict activation context management ensuring no activation context leaks or pollution.
Cons:
- Can only be used in C/C++ code.
- Requires recompilation of the code.
- Does not handle call-backs.
- Prevents corporate administrators from changing the configuration.
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:
- Full control over the activation context.
- Can be used in any language capable of calling Windows API (C#, VB6 etc).
Cons:
- Requires thorough understanding of side-by-side, COM and Windows.
- Can cause hard to track down problems, activation context leaks, activation context pollution and resulting spurious program failures.
- Prevents any management by corporate administrators.
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.