* Add ARM64 entries where ARM entries are
This change adds ARM64 entries where ARM(32) entries already exist.
In the case of certain test configurations, ARM is set to use the x86
configuration so ARM64 imitates this.
Since winrt.test.managed.uap.csproj is not compatible with .NET Native
and the ARM64 UWP does not support .NET other than Native, it is
omitted.
* Upgrade DirectXTK_UWP dep to 2019.4.26.1
This takes care of unresolved externals in the Direct3DInterop library
by updating to a version of directxtk_uwp that has ARM64 support.
* Bump UniversalWindowsPlatform to 6.2.8
This change fixes the Nuget Restore error
The local source 'C:\Users\jkunkee\source\repos\Win2D\bin' doesn't exist.
Incidentally, it also pulls in a version with official ARM64 support:
https://github.com/Microsoft/dotnet/blob/master/releases/UWP/net-native2.2/README.md#uwp-627-march-12th-2019
* Set TargetPlatformMinVersion to 10.0.16299.0 for ARM64
This change fixes errors about ARM64 not being supported before 16299.
* Work around NuGet TargetPlatformMinVersion limits
This change accomodates Visual Studio's lack of support for multiple
TargetPlatformMinVersion values in one project by separating the NuGet
restore and the build operations that depend on it.
UWAs that intend to support ARM64 must have a TargetPlatformMinVersion
of at least 10.0.16299.0, while UWAs that intend to support all past
versions of Windows 10 must set it to 10.0.10240.0. The Win2D sample
and test UWAs need to do both, but NuGet restore only takes one. This
this change copies the restore and build operations into two such that
the 16299 restore runs, the 16299 (ARM64) builds run, then the 10240
restore runs, and finally the 10240 builds run. This builds
everything, including tests, for all architectures. One side effect is
that the NuGet package state is left in a state that supports building
the most common Platforms from Visual Studio.
A corrolary to this is that exported sample projects will require
similar arrangements to build for both full Windows 10 backwards
compatibility and for ARM64.
Since BuildDocs.proj also uses NuGet Restore, it specifically uses the
more general 10240 restore target.
* Drop WorkAroundNuGetRestoreBug
As of Visual Studio 2017 and this point in the commit history, this
workaround is no longer necessary.
Details:
- Adds the supporting types ColorManagementProfile and EffectTransferTable3D
- Adds effect codegen support for adding manually authored static methods (used to implement ColorManagementEffectFactory::IsBestQualitySupported)
- Copies latest API description XML from the Windows tree - lots of churn here but it's all just reformatting and adding comment strings
- Extends ComArray to handle arrays of non-POD types ComPtr and WinString (nice side effect is this fixes a preexisting leak in the CanvasTextFormatFactory::GetSystemFontFamiliesFromLocaleList error path)
- CanvasEffect supports interface effect property types
- Moved Color -> BGRA conversion from CanvasBitmap -> DxgiUtilities
- Moved GetRefCount helper from RefCountTests to Helpers.h
The way the DirectXTK NuGet packages are built depends on a custom MSBuild extension
task. This DLL gets copied to a temporary location at the start of the build, then
loaded into the MSBuild process. Two problems result:
- The DLL copy fails if multiple processes attempt to build different flavors of the
same project using the package in parallel. (poor) solution is to disable parallel
build only for the project that uses DirectXTK.
- As long as MSBuild remains alive, the DLL is locked, so subsequent operations such
as git clean will fail. Solution is to specify the MSBuild switch (/nr) telling it not to
keep around process instances for later reuse.
- Renamed CONTRIBUTING to CONTRIBUTING.md
- Moved directory structure info from README.md to CONTRIBUTING.md
- Updated contribution process
- CLA submission process now automated via the Azure pull request bot
- Detailed the contribution process including How-To for verifying changes