Support embedded resource manifests on Windows

[SteveL-MSFT]

Summary of the new feature / enhancement

Windows exe's can have resources embedded in them so they can ship/sign just one file. dsc would need to check every exe to see if it has an embedded resource manifest, but with caching, this should only be an expensive operation the first time for resource discovery and we can invalidate specific portions of the cache if a directory's modified date changes. The embedded resource manifest would take precedence over any external file equivalent.

Proposed technical implementation details (optional)

No response

[anmenaga]

Need an example of an embedded resource manifest please.

[SteveL-MSFT]

Need an example of an embedded resource manifest please.

The file format is exactly the same, but we need to use a win32 api to retrieve it. Looks like there is at least one crate that also does this https://docs.rs/native-windows-gui/latest/native_windows_gui/struct.EmbedResource.html

Embedded resource MIGHT solve the AppStore problem

[JohnMcPMS]

I'm not sure how this helps with the problem; the executables in MSIX packages aren't on %PATH%. It also makes first run much more expensive.

Would a Windows specific behavior of "all MSIX package roots are searched for resources" using the existing .dsc.resource.json convention work?

[SteveL-MSFT]

@JohnMcPMS caching will alleviate the warm startup problem, but any cold start will be slow as part of resource discovery anyways. As MSIX packages get all their files installed into a folder that doesn't have enumeration permission, we can't do the current discovery using that process. Embedded resources still has the problem, currently, that we can't follow the reparse point as the appx reparse point isn't documented.

[JohnMcPMS]

I suspect that probing every .exe on %PATH% for embedded resources is going to be far more expensive than probing the filesystem for files.

Everyone has permission to enumerate within package install roots. Enumerating the set of packages that a user has installed is the correct way to find those roots, not using the filesystem.

Using the alias reparse point introduces an additional complication of the location of the resource manifest w/r/t the location of the actual command to run. Assuming that I can only run commands that are collocated with resource manifests (for security reasons), a packaged alias that is on %PATH% is also collocated with all other aliases. So, a resource in package A could target a command in package B. That could be solved by explicitly setting the command location to the package specific alias path, disallowing cross package alias invocations. It could also be solved by simply stating that any embedded resource is only allowed to reference itself as the command to run, although that places limits on implementations.

One option, although it complicates my own interactions, would be to create an adapter that encapsulates all of this knowledge.