Here is an attempt to explain why things work the way they are described in the last article about FileOpenDialog. There are two things we did to make this work on Vista and XP.
- We removed assembly identity elements from the embedded manfiest
- We changed the Name for Assemblyidentity to Fileopen.package from FileOpen.exe
For the first part…
Every managed assembly has a CLR identity. This identity is described in the CLR metadata. Broadly speaking when you are dealing with a file that really does not need “SXS-ness” or “component-ness” there is no reason to specify an identity. If you want to plainly describe dependencies for a binary and you are never going to install it in Win32 GAC or no other win32 file(Manifest) is going to reference it, you don’t need to make up an identity for it. A lot of monolithic win32 Apps fall into this category. But the “cut & paste the manifest” legacy is making all these manifests have an identity even if it does not serve any real purpose. The VS 2005- When generating a mixed mode exes (Managed C++ exes) does not spit out an identity for an embedded sxs manifest. In our case, we had specified another ideneity. Now ideally tools should make sure that both these idenetities are same but in our case they are not (CLR: FileOpen, Embedded:FileOpen.exe). By removing the assemblyidentity from the embedded manifest, system uses identity from the managed metadata.
For the second part…
Ideally if the tools can pull out all the dependencies (Managed and UnManaged) from a given application dependency graph and put it in side the ClickOnce manifest, that would be perfect. In that case we would have replicated the flattened dependency graph of the app before the execution itself and it matches with the actual runtime dependencies. And of course any dependency that is not local would become a prerequisite. This is a perfect experience.
- All the local dependencies and pre-requisite dependencies are known upfront. ClickOnce can do the checks accordingly.
- One manifest serves for download and Activation (On XP)
- On Vista the app works the same way – only difference being that activation originated from the embedded manifest
When you SXS manifest inside (embedded) and outside(ClickOnce application manifest) on vista it looks at inside one to setup the correct execution context but on XP it looks at the outside one. Since ClickOnce creates external SXS manifest (fileopen.exe.manifest) in this case, this is what gets used by system to setup the execution context. Since ClickOnce manifest in our case does not have prerequiste element that describes ComCtl32.dll dependency, app works on Vista but fails on XP. By naming the name of assemblyideneity element (FileOpen.package) we cause ClickOnce to create FileOpen.package.manifest to be created in the store since ClickOnce appends .manifest to assembly identity name. This means Windows SXS infrastructure does not fine FileOpen.exe.manifest next to EXE on XP, so it falls back to internal manifest which has ComCtl32.dll information and hence it works. We have to choose between one manifest vs the other. If we dont want ClickOnce manifest to serve for the activation context we can change the name