Enable app to call the boostrap based on a "local" installation

[WindowsNT]

I have two versions of my app. One, the "Self-Contained" which has a bunch of redistributables in it's directory and can use WinUI directly. This app will only load in Windows 10+ even if it doesn't use WinUI (else I get a "this app must be run within a container" error in Windows 7).

The other "desktop" version can run in Windows 7 and can also use the bootstrap to load WinUI if there 's a redistributable installed.

Would it be possible for the desktop app to call the bootstrap since the "local" files are already there? This will enable me a) to use only one executable and b) to avoid a redisitributable installation.

No matter what I 've tried, calls to Bootstrap API fail from the "desktop" app unless the redist is installed.

[DarranRowe]

This isn't the way that self contained works. However, depending on how you handle things, it should be possible to do what you want.

First of all, the app container thing comes as a side effect of using the Windows 10 application project type that the WinUI projects use. If you use dumpbin to check the executable headers:

C:\Users\Darran\source\repos\Meh\x64\Debug\Meh>dumpbin /headers Meh.exe
Microsoft (R) COFF/PE Dumper Version 14.37.32822.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file Meh.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
...

OPTIONAL HEADER VALUES
             20B magic # (PE32+)
           14.38 linker version
           C3200 size of code
           6E200 size of initialized data
               0 size of uninitialized data
           5AC9D entry point (000000014005AC9D) @ILT+7320(wWinMainCRTStartup)
            1000 base of code
       140000000 image base (0000000140000000 to 000000014018FFFF)
            1000 section alignment
             200 file alignment
            6.02 operating system version
            0.00 image version
            6.02 subsystem version
               0 Win32 version
          190000 size of image
             400 size of headers
               0 checksum
               2 subsystem (Windows GUI)
            9160 DLL characteristics
                   High Entropy Virtual Addresses
                   Dynamic base
                   NX compatible
                   App Container
                   Terminal Server Aware
          100000 size of stack reserve
            1000 size of stack commit
          100000 size of heap reserve
            1000 size of heap commit
               0 loader flags
              10 number of directories
  ...

You can see that the dll characteristics contains App Container. This may be called dll characteristics, but it also affects executables too. Anyway, this is something that is set by the linker. You can force this off if you add /APPCONTAINER:NO to the command line, as documented.

Secondly, contrary to what you may think, the Windows App SDK does not use the Bootstrapper API to load when it is self contained. As documented, the Bootstrapper API is only needed when the Windows App SDK is being used as a framework package. This is because Windows 10 does not have a Dynamic Dependencies API, the Windows App SDK provides one, but you need to use a Dynamic Dependencies API to reference the Windows App SDK.
If you pay attention to what it compiles and links during the build process when you set self contained to true, there will be an extra file compiled named UndockedRegFreeWinRT-AutoInitializer.cpp (or .cs). What this file does is either makes a compile time link with a function in Microsoft.WindowsAppRuntime.dll, or uses LoadLibrary to load Microsoft.WindowsAppRuntime.dll. However, if you are making the application work like it is self contained then there is one more step that you must do. This is set the Registration Free WinRT entries in the application manifest file. You can find information on what you need to the application manifest if you look for a file named WindowsAppSDK.manifest in the build's intermediate directory. Once you know what you need to add, it is also easy to generate this information, since you can find it in a file named LiftedWinRTClassRegistrations.xml in the Windows App SDK nuget package.
The only thing I am unsure about in this case is how Windows 7 will deal with the registration free WinRT entries. If Windows 7 silently ignores them, then everything is fine. If Windows 7 doesn't then you would need separate application manifests. In this case, you should be able to use the Activation Context API to use the Registration Free WinRT manifest when you detect that the Windows App SDK is usable. You can use the presence of GetPackageInfo2 to detect this without running the risk of messing up version checks.

[WindowsNT]

I had realized that the bootstrap is not called and I had also tried to load the runtime.dll myself (without success). But now you have mentioned the manifest I will take a look at it and see what I can achieve.

Best regards & thanks.

[DrusTheAxe]

how Windows 7 will deal with the registration free WinRT entries

WinRT was invented in Win8 and reg-free WinRT even later so it should be ignored by Win7.

Should, but I can't find any docs explicitly stating that. @brialmsft @jonwis can you confirm? Or even better, know the docs/link I missed about it?

[brialmsft]

Unrecognized SxS manifest elements will be ignored, but no I'm not aware of any docs saying that explicitly.

[DarranRowe]

@DrusTheAxe @brialmsft
Thank you for the clarification. I was erring on the side of caution, but it is nice to know that they will be ignored.