When to Use the Activation Context API
|how-to | home|
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.
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.
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.
This option allows for the most power and flexibility while at the same is the most difficult and demanding.
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.