[1.8 servicing] Delay load RoMetadata, XmlLite, userenv dlls in WindowsAppRuntime

[Hemantxk]

Cherry-picked from #6398

In a WinUI3 packaged app created from the Visual Studio template, during the auto-initializer phase of WindowsAppRuntime, statically imported DLLs are loaded into memory by default. It is observed that WindowsAppRuntime doesn't call into rometadata.dll, xmllite.dll, and userenv.dll in this phase, but statically imports them. This change delay-loads these three DLLs so they are only loaded when actually needed.

Details

Below is what WindowsAppRuntime uses each of these DLLs for:

• RoMetadata - WindowsAppRuntime calls into MetaDataGetDispenser in WinRTGetMetadataFile, but it is not called for a WinUI3 packaged app.
• XmlLite - Used in WinAppSDK to read a package's AppxManifest, but this was not observed being called in a sample launch path. XmlLite can also get loaded by the MUX DLL if someone passes XAML in a string in code-behind (e.g., XamlReader), but this is not a common way to write XAML.
• userenv - WinAppSDK calls into this DLL for DeriveAppContainerSidFromAppContainerName. This was also not called in the launch path of an app. Browsing through the WinAppSDK code, it is called in GetSecurityDescriptorForAppContainerNames, and not all apps may need it.

Changes

dev/WindowsAppRuntime_DLL/WindowsAppRuntime_DLL.vcxproj: Added rometadata.dll, xmllite.dll, and userenv.dll to the linker setting across all build configurations.

[Hemantxk]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[DrusTheAxe]

but this was not observed being called in a sample launch path

*What platforms did you observe this? WinAppSDK runs down to RS5 desktop (and server 2019) and the behavior and implementation varies.

xmllite.dll is required by UndockedRegFreeWinRT (parses Fusion manifests) and WinAppSDK Dynamic Dependencies (parses AppxManifest.xml)

On Windows >=Ge (10.0.26100.0) the DynDep APIs are passthrough to the OS DynDep and don't Detour OS APIs, and URFW is ignored entirely Detour'ing nothing (OS RegFreeWinRT handles RegFree WinRT demands).

Thus thus there's no value (negative value?) marking xmllite.dll as delay-load on <Ge, and VS doesn't support OS-version-dependent options for <DelayLoadDLLs>.

Does <DelayLoadDLLs> interfere with Detours? If so then deferring rometadata.dll would be bad - app may load but calls to e.g. ApiInformation will be problematic at runtime.

userenv.dll may be worthy of DelayLoad. Of course this assumes the app's code (and non-WinAppSDK libraries used by the app) have no need for userenv exports, especially if said exports were added after RS5. Failure to find a delay-load'd import at runtime would crash the app.

This concern is why we haven't routinely added <DelayLoadDLLs> to WinAppSDK's templates (it was suggested in a previous Issue or PR) -- we don't know all the ways apps are written, and delay-loading Windows DLLs isn't a routine thing developers expect by default (the Platform SDK and Visual Studio templates never defaulted to this behavior). If this goes wrong it likely will give developers a painful surprise. Is this worthy to set by default?

[Scottj1s]

Agree that the userenv.dll delay-load makes sense, as this is API-specific (conditional on client code).

I have no problem with xmllite.dll, since this scenario is bound to diminish with time, as more devices move up to Ge+.

The Detours concern is valid - have we tested to ensure that rometadata.dll is handled correctly if loaded after Detours is initialized?

[DrusTheAxe]

FYI xmllite.dll's used by various parts of Windows e.g. the Fusion manifest parser. If the exe has a Fusion manifest xmllite.dll was loaded as part of process creation so this is probably a warm load - already in disk cache so just need initialization for current process. That should be inexpensive, all things considered.