Migrate runtime bootstrap and initialization support from Foundation to Base#6293
Draft
Migrate runtime bootstrap and initialization support from Foundation to Base#6293
Conversation
- Remove WindowsAppSDKAggregator repo resource and PayloadTrackingTool stage - Fix CommonVariables path: ../../build/WindowsAppSDK-CommonVariables.yml - Fix Stages template ref: AzurePipelinesTemplates/...@self - Fix SetupBuildEnvironment path: ../../../build/AzurePipelinesTemplates/... Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- name: use from CommonVariables (not ) - DetermineNugetPackageVersion: use instead of Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…kage - Add new BuildBaseFoundation step to BuildAll.ps1 that builds only WindowsAppRuntime_DLL and WindowsAppRuntime_BootstrapDLL from the solution (plus Bootstrap.Net for AnyCPU) - Update StageBaseFiles to copy auto-initializer source files directly from their source locations instead of build output - Add BuildBaseFoundation task to Base PR pipeline before StageBaseFiles Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The NugetRestore function sets NUGET_RESTORE_MSBUILD_ARGS with the multi-platform Platform variable which causes MSBuild to fail when invoked on a .csproj. SDK-style projects use /restore inline instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Build WindowsAppRuntime_DLL.vcxproj and BootstrapDLL.vcxproj directly instead of using /t:ProjectName on the solution (MSB4057 error) - Clear NUGET_RESTORE_MSBUILD_ARGS before solution restore to avoid multi-platform argument issues (MSB1006 error) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Switch all 4 Foundation DLL imports (MddTryCreatePackageDependency, MddAddPackageDependency, MddRemovePackageDependency, WindowsAppRuntime_VersionInfo_TestInitialize) and MsixInstallLicenses to explicit dynamic linkage via GetProcAddress with runtime error reporting. Remove from BootstrapDLL vcxproj: - Microsoft.WindowsAppRuntime.lib from AdditionalDependencies - WindowsAppRuntime_DLL from AdditionalLibraryDirectories - Microsoft.WindowsAppRuntime.dll from DelayLoadDLLs Add source include paths for headers previously found via DLL output: - dev\WindowsAppRuntime_Insights (WindowsAppRuntimeInsights.h) - dev\DynamicDependency\API (MsixDynamicDependency.h, MddWin11.h) - dev\Licensing (MsixLicensing.h) Remove WindowsAppRuntime_DLL build from BuildBaseFoundation step since Bootstrap no longer needs the import library. All 18 local tests pass. dumpbin confirms zero import dependency on Microsoft.WindowsAppRuntime.dll across all 3 platforms. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Now that Bootstrap DLL uses dynamic linkage, the Base pipeline build step no longer builds any Foundation projects. Rename to reflect this. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Move WindowsAppRuntime_BootstrapDLL, Bootstrap.Net, and all auto-initializer source files under base\dev\ so that pipeline folder triggers (base\**) cleanly separate Base from Foundation. - base\dev\WindowsAppRuntime_BootstrapDLL\ (from dev\) - base\dev\Bootstrap\CS\ (from dev\Bootstrap\CS\) - base\dev\include\ (auto-initializers from dev\Common, Deployment, UndockedRegFreeWinRT) Updated 84 files: solution, vcxproj, csproj, vcxitems, BuildAll.ps1, pipeline templates, test targets, test projects. All 18 local tests pass. All 3 platform builds verified. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Config 8 (RS5_FD_Pkg): set WindowsAppSdkDeploymentManagerInitialize=true and expect MSBuild error when Foundation is not referenced. Added WindowsAppSDKDeploymentManagerRequiresFoundation validation target in BaseCommon.targets, matching the existing URF pattern. Fixed RunBasePackageTests.ps1 to auto-detect repo root and MSBuild so it works from any directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Update template references to use correct relative paths and @self suffix when running from base/build/ in the GitHub repo: - ../../build/WindowsAppSDK-CommonVariables.yml (relative to file) - @self suffix for stages templates inside extends block - Forward slashes for consistency Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The targets files moved from build\NuSpecs\ to base\build\NuSpecs\. Update test project imports to the new paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When referenced via @WindowsAppSDKAggregator from an external repo, the path must be relative to the aggregator repo root (build/...). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
In OneBranch extends block, @self templates resolve relative to the YAML file's directory, not the repo root. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…lines PayloadTracking references a script from the aggregator repo that doesn't exist in WindowsAppSDK. Its failure blocked the main build stage via succeeded() condition. Base builds don't need payload tracking. Also removed unused WindowsAppSDKAggregator and WindowsAppSDKSamples repository resources. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tics The original Bootstrap DLL used delay-loading for Microsoft.WindowsAppRuntime.dll. When the helper app freed Bootstrap.dll, the runtime DLL stayed loaded because the delay-load helper's LoadLibrary ref persists independently. Our GetProcAddress approach stored the handle in a wil::unique_hmodule global, whose destructor freed the runtime DLL when Bootstrap.dll was unloaded. This destroyed the in-process package graph state on Win10 (managed by the runtime DLL, not the OS), causing WinRT activation failures and test timeouts. Fix: Use a raw HMODULE with no destructor, matching the original delay-load behavior. Only MddBootstrapShutdown explicitly frees the handle. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace \ (undefined) with \ from CommonVariables.yml, matching all Foundation pipeline conventions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The old code called MddRemovePackageDependency via delay-load from the runtime DLL, which worked for both Win11 and DDLM paths. Our GetProcAddress approach only resolved g_pfnMddRemovePackageDependency in the DDLM path, so the Win11 path skipped the call entirely, leaving the package dependency in the OS graph. This caused cascading failures: StoragePickers ClassSetup couldn't re-register the framework package (0x80073D02 'package in use'), and DynamicDependency GetCurrentPackageInfo returned wrong results after shutdown. Fix: Check g_usingWin11Support and call MddCore::Win11::RemovePackageDependency directly on the Win11 path, matching the old delay-load behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
|
This is a huge change that intersects with the bootstrap/etc SemVer/2.0 change Completing this PR should await #6277 completion |
DrusTheAxe
requested changes
Mar 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This work enables other component packages to streamline their dependencies, omitting building and packaging of any WinAppSDK APIs unless explicitly referenced. For example the WinML package can change its transitive reference on Foundation (and indirectly, IXP) to just Base to pick up auto-init support and avoid binplacing DLLs it doesn't require at runtime, in self-contained mode.