Manifest requirements for TaskDialog

[miloush]

There have been some requests to have the TaskDialog available in WPF (#2902, #5967, #6775, #6810). While the basic functionality is relatively straightforward to implement, the issue is that in order for the TaskDialog API to become available to an application, version 6 of comctl32.dll needs to be loaded.

The version of comctl32.dll loaded is controlled by a manifest file. The manifest can be either embedded in the application, or, with the help of CreateActCtx loaded at runtime either from a different binary, or from an external file.

Unless developer specifies a specific manifest file, the SDK embeds a default one during compilation. Unfortunately, the default one does not allow the required version of comctl32.dll to be loaded.

Winforms solves this by embedding a manifest in the System.Windows.Forms.dll both as a native resource and as a managed resource. It uses CreateActCtx to activate the native manifest and if that fails (for example in a single-file scenario), it extracts the managed resource as a temporary file onto disk and activates that one, this happens in EnableVisualStyles.

If WPF applications wanted to use TaskDialog, the options we have are as follows:

1. Declare the API, but do not deal with manifests. It would be developer's responsibility to ensure correct manifest is embedded. The API will throw an exception if that is not the case.

2. Convince the WindowsDesktop SDK team to update the default manifest for everyone. This could be gated behind minimum target version (such as net9.0-windows) so that existing applications are not affected.

3. Patch the manifest to be embedded (either default or custom one) so that it includes the correct comctl32 declaration during build. There is already a precedence doing this in the UpdateManifestForBrowserApplication build task. (This could be conditioned either behind a build property or application property, which technically makes it again the developer's responsibility, or, detecting the API usage using an analyzer, however, that would fail reflection and similar scenarios.)

4. We do what Winforms does, i.e. embed manifest somewhere in the framework that we can reference (for example wpfgfx, PresentationNative etc.), having to ensure this works in the single-file scenario, and duplicating ThemingScope from Winforms to use it.

5. WPF will not have its own TaskDialog implementation. People can just use the Winforms one, it is technically the whole purpose of Winforms to wrap Windows controls.

Other not really good options:

6. We introduce dependency on Winforms, at least for the comctl32 activation.

7. We introduce dependency on some unsuspecting Windows binary, internet seems to like using manifest from shell32.dll.

If we do want to have at least some TaskDialog functionality, I would be personallly leaning towards develepers' responsibility to embed correct manifest (1.) while pursuing SDK putting it by default (2.). If there was an overwhelming interest in unconditionally patching the manifest during bulid (3.), I wouldn't object. However, I am not that thrilled about going the Winforms route of hiding and temporarily activating manifests.

Anyone else has thoughts on this?

[rampaa]

I would be personallly leaning towards develepers' responsibility to embed correct manifest (1.) while persuing SDK putting it by default (2.)

This sounds quite reasonable. As long as the API documentation explicitly spells it out that the developer should create a manifest file with the correct comctl32.dll version, I see no problem in making it the developer's responsibility to provide the correct manifest file.