This repository is mirrored onto an internal Azure DevOps repository that is used for building Windows App SDK releases. This has the unfortunate side effect of embedding into the PDB symbols Source Link information that points at the internal AzDO repo rather than this public Github repo. This change addresses that by adding a custom target that corrects the repo URL that Source Link uses.
Fixes#4633.
Teach DevCheck to verify dependencies
To use:
* DevCheck -CheckDependencies (or -All or no parameters) to verify dependencies
* DevCheck -SyncDependencies to verify and potentially update dependencies (if necessary)
* DevCheck -CheckVisualStudio now also verifies all required components are installed per docs\Coding-Guidelines\VisualStudio2022.vsconfig
Also enabled StrictMode 3.0 for better error detection.
Sample runs:
[C:\source\repos\windowsappsdk]DevCheck.cmd -CheckVisualStudio
Checking developer environment...
Windows App SDK location...C:\source\repos\windowsappsdk
VisualStudio 2022...C:\Program Files\Microsoft Visual Studio\2022\Enterprise
...Scanning 69 components in C:\source\repos\windowsappsdk\docs\Coding-Guidelines\VisualStudio2022.vsconfig.....................................................................OK
Coding time!
and
[C:\source\repos\windowsappsdk]DevCheck.cmd
Checking developer environment...
Windows App SDK location...C:\source\repos\windowsappsdk
VisualStudio 2022...C:\Program Files\Microsoft Visual Studio\2022\Enterprise
...Scanning 69 components in C:\source\repos\windowsappsdk\docs\Coding-Guidelines\VisualStudio2022.vsconfig.....................................................................OK
Test certificate for C:\source\repos\windowsappsdk\.user\winappsdk.certificate.test.thumbprint...OK
Test certificate AF8A2139E3942FE1D3DA65009D68C2A97EB41739...OK
TAEF service...Running
Reading C:\source\repos\windowsappsdk\eng\Version.Details.xml...
14 dependencies detected
Reading C:\source\repos\windowsappsdk\eng\Version.Dependencies.props...
Verify C:\source\repos\windowsappsdk\eng\Version.Dependencies.props...OK
Scanning packages.config...
Scanned 23 packages.config
Scanned 40 *.vcxproj
Coding time!
TODO (in a future PR)
* Verify references in *proj use only packages in Version.*.xml
* Verify references in *proj use only package versions matching Version.*.xml
* Move csproj to CentralPackageVersions
* Move more csproj to CentralPackageVersions
* Replace version 1.1.1 of SourceLink.Common, SourceLink.GitHub, Build.Tasks.GitHub with variable in Versions.props
* Add vars to Versions.props
* Replace CppWinRT version 2.0.220929.3 with $(CppWinRTVersion) from Versions.props
* Replace CppWinRT version 2.0.220531.1 with $(CppWinRTVersion) from Versions.props
* Replace Taef version 10.58.210222006-develop with variable from Versions.props
* Replace Wil version 1.0.220914.1 with variable from Versions.props
* remove xml line, use variables from versions.props
* Move Cpp.Default.props to top so that version.props is brought in before import statements
* Use nuget Central Package Management
* add one that I missed - moving cpp.default to the top to populate variables before imports
* Disable problem csproj files (time boxing effect)
Tweak various compiler options for optimization (e.g. /GR-) and correctness/productivity (e.g. /W4).
Project-wide standardization via new \WindowsAppSDK.Build.Cpp.props. See for more details.
Corrected several inconsistencies across projects e.g. given Debug|Release + x86+x64+arm64 = 6 permutations, but some projects had an option set for only 5, or only 1. Most projects were mostly already setting most of these options so their changes were mostly removing the now-redundant project-specific setting and let the top-level project-wide standards handle it.
This now standardizes all C++ projects to...
* Compile (all): `/W4 /sdl /permissive- /std:c++17 /GR-` (except 2 projects that explicitly set `/std:c++20`)
* Compile (debug): `/Od`
* Compile (release): `/GS /GF /GL /Gy /Gw /Ob2 /Oi /Os /Oy`
* Link (debug) `/DEBUG:FULL /INCREMENTAL`
* Link (release): `/INCREMENTAL:NO /LTCG /OPT:ICF /OPT:REF`
https://task.ms/39994837 Foundation
https://task.ms/39994852 MRTCore
* Add standardized (project-wide) C++ compile and link options
* Remove ARM support (not supported, but some ARM-conditional fragments weren't removed)
* Removed <WarningLevel> from all projects. Fixed up warnings masked by projects who'd set Level3
* Added SDLCheck for all builds. Added Disable-Optimization for Debug builds. Remove properties in *vcxproj redundnat with standardized options
* Removed redundant <Optimization> from *vcxproj
* Fixed warnings. Removed unnecessary delayload
* Fixed some inconsistencies in project settings
* Fixed AccessControlTests weren't copying the Bootstrap dll to the test's OutDir and thus the test dll wouldn't load
* Fix some warnings in MRT. Had to disable read-only string pooling and strictstrings as workaround for some funky issues in MrtBaseUnitTests for now; filed bug for follow up to fix the errors
* Corrected some comments. Added the missing LTCG option
* Changed LTCG from fast to normal
* Updated FavorSizeOrSpeed to Size instead of Speed
* Move LinkIncremental=false for Release builds to the top-level project-wide standard
* Host LinkIncremental=true if Configuration=Debug to be project wide setting (projects were routinely doing this locally, but inconsistently)
* Fixed a comment
* Added a cautionary note about why Detours.vcxproj has seemingly redundant or contradictory options and to be wary of making any changes
* Removed options redundant with WindowsAppSDK.Build.Cpp.props
* Elevate GenerateDebugInformation=Full to project-wide and remove redundancies. Move dev\WindowsAppSDK.Build.Cpp.props content to project wide (not just \dev) and delete the now obsolete dev\WindowsAppSDK.Build.Cpp.props (really only amounted to /ZH:SHA_256).
* Incorporated feedback
* Remove dead code
* Add URWF auto-initializer
* New URFW files
* Connect the dots for URFW auto-initialization support
* Added missing file. Fixed compiler warnings
* Simplified the C# auto-initializer. Added a comment explaining why it works the way it does
* Updated C# auto-initializers to shortcircuit any work if loaded for reflecction (vs execution)
* Added missing using
* Fix returning a reference to a local variable in GetActivityFlags(); returns a const enum so no reason it can't be by-value and the obvious correctness reason it can't be by-ref
* Added build macro WindowsAppSDKCleanIntermediateFiles=<boolean> to scrub intermediate outputs as we build. Defaults to 'true' for build pipeline else undefined and thus not acted on (e.g. dev inner-loop)
* Fix prototype for GetIntegrityFlags
* Move WindowsAppSDKCleanIntermediateFiles to be a parameter defined by the pipeline, for better inner-loop (for those who want to use the option)
* Update DevCheck to generate MSTest.pfx/.cer
* Refactor temp handling. Add .user dir
* Change cert handling to use .user\* and direct certificate handler via Powershell's PKI module. Buh-bye all references to MSTest.* and certutil
* Add -Remove-DevTestCert and -Remove-DevTestPfx
* Change all temp\MSTest.pfx to .user\winappsdk.certificate.test.pfx
* Added -CertPasswordFile, -CertPasswordUser, -RemoveAll. Save password as plaintext to .pwd file for later use
* Update makemsix.cmd to pass along the .pwd content needed to use the (now password protected) .pfx
* Update MSTest references
* Start of changing NMAKEfiles to MSBuild
* Add new file
* MakeMsix.targets works! Rewrote DDLM.msix to work it out, when running a specific project (e.g. 'msbuild /bl /p:Configuration=Debug,Platform=x64 /t:Build test\DynamicDependency\data\DynamicDependencyLifetimeManager.Msix\DynamicDependencyLifetimeManager.Msix.vcxproj'). Now to verify it works when building the solution, moving MakeMsix.targets out to root\build and propogating this to the other makemsix projects
* 'msbuild foo.vcxproj' works but 'msbuild bar.sln' fails due to 'C:\source\repos\windowsappsdk\test\DynamicDependency\data\DynamicDependencyLifetimeManager.Msix\DynamicDependencyLifetimeManager.Msix.vcxproj error MSB4057: The target GetProjectInfoForReference does not exist in the project. [C:\source\repos\windowsappsdk\' Seems GetPRojectInfoForReference is referenced by 'C:\ProgramFiles (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets' and Microsoft.Makefile.targets, we don't fit either but they're required to resolve '<ProjectReference...'? Is it possible to move the ProjectReference dependency to the .sln? Or make this work without trying to make a full blown C++ or NMake project? Time to ping some VS/MSBuild experts...
* Tweaked the vcxproj to successfully create .msix via MakeMSIX!
* Moved MakeMSIX.targets to the root (with other build files)
* It works! Got the test projects building with the .pfx and .pwd
* Rewiring test projects to use MakeMsix.targets instead of NMake
* Yet more MakeMsix fixup
* Fixed the package name
* Added dummy Clean command (for now)
* Fixed Deployment's test package where source files get put to different subdir+filename inside the msix
* Fix DevCheck Start-Service to gracefully degrade if not running as admin
* DeploymentTests were missing a build order dependency on BootstrapDLL project
* Updated DevCheck generated cert to have 12-month lifespan (like current one)
* Move Framework.* projects from makemsix.cmd to MakeMSIX.targets
* Delete makemsix.cmd (obsolete)
* Updated test projects to use static manifests instead of generated from a template (unnecessary complexity)
* Deleted obsolete MakeAppxManifestFromTemplate.*
* Removed obsolete manifest/template handling. Removed printfery debugging
* Minor syntax cleanup. Fixed appxmanifest overly aggressive copy/paste human error <sheepish grin>. Fixed publish-header delete-custom-build-step human error
* Fixup Math framework header publishing (due to bad merge due to the age of this change and other work in other branches that hit main. Grrr)
* Deleted obsolete files
* Replaced SolutionDir with RepoRoot
* Rewrote installer's testpackage creation project to use MakeMSIX
* Fixed naming inconsistencies
* Addressed some issues. More to come
* Fixed Get-UserPath emitting New-Item result to the output stream thus when creating the .user directory return $user returned System.Object[] with 2 objects in the stream (filename twice). Well, that was fun
* Fix bad merge
* Added Clean support to MakeMSIX. Cleanup up some internals including dependencies. MakeMsixOutputFilename is no longer optional and inferred; it must be defined by a project before import'ing makemsix.targets
* Optimized load-test-cert-password to a global done once instead of per import rof makemsix.targets
* Updated projects to use the common RepoTestCertificate*
* Removed obsolete and redundant <Error> check
* Added file-existence check before readng file. Added error check at start of project to flag missing-devcheck-artifacts early rather than late
* Test WTH is going on
* Remove debugging printfery. NOTE: Separate Jobs in a pipeline (will? may?) run in parallel on different machines. Until build-mrt.yml is merged into WindowsAppSDK-BuildProject-Steps.yml any common setup (or cleanup) needs to be done in both. Also, it means MRTCore *cannot* use any APIs in WindowsAppRuntime.sln because they're technically peers
* Add DevCheck support to RunTestsInHelix job
* Move Hybrid CRT support out of individual project files up to the project level as a whole
* Remove unnecesasry Store-app-ness that fails the Hybrid CRT support
* Stop enabling DebugLibraries to avoid bringing in debug VC CRT DLL dependencies (violating the Hybrid CRT rules)
* Add DesktopCompatible to MrtCoreManagedTest for future reference - it doesn't hurt, but it doesn't help (at least, not this issue). Also added Win32Proj keyword to M.AM.Resources project. We now have 1 root issue
* Removed MrtCoreManagedTest from the build due to a fundamental incompatibility (ut's a Universal Windows project referencing Microsoft.ApplicationModel.Resources (the WinRT dll) which isn't, and VS doesn't like crossing streams. Even worse, VS and msbuild produce different results!).
* Revert "Removed MrtCoreManagedTest from the build due to a fundamental incompatibility (ut's a Universal Windows project referencing Microsoft.ApplicationModel.Resources (the WinRT dll) which isn't, and VS doesn't like crossing streams. Even worse, VS and msbuild produce different results!)."
This reverts commit 6f4b23dd10.
* Doing things to workaround MrtCoreManagedTest is a Univesal Windows project. Epic Failure. Because it's a Universal Windows project MSTest is creating $(OutDir)AppX subdir and copying files ***it knows about*** to the subdir. This brutal hack fails because File.Exists() for files in the parent directory fails, and that's because the last var pc = ... tries to access the AppX directory's parent ***and fails because Access Denied***. Previously doing the copy in the .csproj fails because the AppX directory doesn't necesarily exist before the test runs, and MD $(OutDir)AppX before copying files is pointless because MSTest is deleting all the files (if any) in the AppX directory when the test starts. So dead end upon dead end. Only way is to find a way to bench the Universal Windows .props logic to understand the files it doesn't want to allow through the ...Transitive... copy rules. Or just rewrite the project as a non-Universal Windows project. Or rewrite the test using TAEF instead of MSTest. Or... drink heavily. Hunting up Scott tomorrow hoping he has an idea
* Hah! Thank you ScottJ! ReferenceCopyLocalPaths does the right thing, copying the needed DLLs into $(OutDir) *and* $(OutDir)AppX and the tests now find the dll and pass
* Remove debugging hackery
* ProjectReunion -> WindowsAppSDK rename (first pass. Of many...)
* /build/** renamed
* assets/**
* /docs
* dev\WindowsAppSDK_DLL\
* installer/
* specs/**
* Last pass! Time to test...
* Remove en-us from microsoft URLs e.g. BAD=https://docs.microsoft.com/en-us/blah GOOD=https://docs.microsoft.com/blah. The client+server figure out the appropriate language and update the URL (at least, Microsoft.com does it) so always encode the more generic syntax
* Incorporated feedback
* Merged latest from main and fixed up reunion references brought in
* Incorporated feedback
* Maybe this is it
* This too?
* Fixing another reunion reference that snaked in from recent main...
* Enable running MRT Core tests in Helix in the PR Feeder repo using Microsoft.Internal.WinUI.Helix package.
* Code review changes.
* Remove HelixIsExternal from the pipeline yml
* Add comments. Remove unneeded scripts. Enable dumps for TAEF.
* Make the token optional for Append-HelixAccessTokenToUrl
* Remove conditionFor* for arm64
* Use Microsoft.Internal.WinUI.Helix version 0.5.1
* Push Microsoft.DotNet.Helix.Sdk to ProjectReunion-Dependencies
* Code review and clean-up.
* Bump Microsoft.Internal.WinUI.Helix to version 0.5.2
* Support both open and closed Helix queues.
* Remove platform from Helix csproj files, as it is now set by BaseOutputPath.
Remove property overrides for build output directory structure behavior. The only always guaranteed safe properties available to override on the command-line are Configuration and Platform. This is due to the fact that there is no way to set other properties in the VS IDE solution (at least to the best of my knowledge).
* Tweak logging in Directory.Build.props to remove noise during inner-loop
* PRfwk's package name is Microsoft.ProjectReunion, not Microsoft.ProjectReunion.Framework. Fix GetFrameworkPackageInfoForPackage() to find the right package, now and into the future (different Major.Minor[-tag]). And as a happy perk don't break tests
* Fix typo
* Added define+include override support to Directory.Build.props (as ProjectReunion.props doesn't seem to be used).
* DynamicDependencyLifetimeManager.ProxyStub project's MIDL task's AdditionalIncludeDirectories was a hardcoded path lacking 2 thus omitting the override location (needed to compile in pipeline builds). I verified this was the only such instance except some MRT projects, but they're different enough and working so letting sleeping dragons lie
* GenerateDynamicDependencyOverrides.ps1 was told to write to the wrong directory
* Huh. Maybe ProjectReunion.props is used after all - by the CI pipeline?
* Fixed a typo
* Added more debugging aid
* Fixed overridedir location
* Righter path (I hope
* Removed debugging codfe
* Removed dead code
Stop building AppLifecycleTestApp and TestPackage so we can continue to build on our pipeline.
I've attempted to make these two build on the pipeline but there are a couple of issues:
this appx package is being signed with a pfx that doesn't exist on the repo (it shouldn't be on there anyway)
the reference to project reunion lib on AppLifecycleTestApp is failing with LNK1181 on Arm and Arm64
the appxbundle from the testpackage is only configured to build x64 and if I enable the other platforms to build, the pipeline freaks out and x64 starts building x86 and so on.
Fix Nuget Restore failing on Taef.TestAdapter in the ms ProjectReunion pipeline by setting up a nuget service connection to the WindowsES-External feed.
* Initial commit of Reunion Common Entrypoint
* Rename Common to SampleWinRT
* Care and Feeding of WinRT code
* Add ARM64 target
* Flat C API sample
* Extend sample slightly, fix publishing files
* Update References
* Add a simple test (that doesn't work yet)
* Move to a shared project
* Replace "Universal" DLL with a regular C++/WinRT DLL
Publish "flat C" headers to common output directory
Ensure test execution can find the implementation binary
* Change namespaces, fix up solutions, make test work
* Get a UWP unit test building
* Update to new cppwinrt package
* Include ARM64 in builds, add 'build everything' script
* Add means to test UWP, identity, etc in one shared file
* Rename test projects
* PR feedback
* PR feedback
* PR feedback
Evelyn Wu
Manodasan Wignarajah
alexlamtest
Bob Pulliam
Howard Kapustein
JJ Brychell
Kyaw Thant
Hui Chen
Jeff Genovy
Scott Darnell
Jon Wiswall