Update Win2D to WinAppSDK 1.0.3
Update Win2D to use HybridCRT
Remove BuildDocs from build process, which isn't intended to be used with WinAppSDK
Disable building of winrt.test.external.uap.vcxproj, which did not run previously because of UAP restrictions in WinAppSDK, but now also does not build because of the move to HybridCRT
Add WinAppSDK as a nuget package dependency, enforcing a minimum version
Previously the projection project was converted over to not use AnyCPU anymore. This was because there's a bug where the WindowsAppSdk bootstrap dll tries to deploy an AnyCPU version (which doesn't exist) and fails.
Not using AnyCPU causes issues down the line with adding more tests, so this change restores back to using AnyCPU. But it also addresses the bootstrap dll bug more directly, and works around it to deploy x86.
Updates all the package references to upgrade Reunion -> WindowsAppSdk 1.0 experimental.
Some of the tests needed fixes because WindowsAppSdk added a namespace called Microsoft.Windows. Because of the way the tests are using namespaces, all their references to Windows.UI.Foo auto-resolved to Microsoft.Windows.UI.Foo which breaks.
Updates Win2D to depend on Reunion 0.8.0
Includes some breaking changes:
- Microsoft.System.DispatcherQueue -> Microsoft.UI.Dispatching.DispatcherQueue
- Microsoft.Graphics.IGeometrySource2D -> Windows.Graphcis.IGeometrySource2D
- .Net5 projections added
- Updated to reflect WinUI3 changes
- Samples will now live in the Win2D-samples repo
- CanvasAnimatedControl and CanvasBitmap not yet supported
* 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.
* Use latest installed Windows SDK version
* Use VS2019 (v142) C++ toolchain
* Use UniversalApiContract version in 18362 SDK
* Fix build with VS2019 compiler
* Fix Win2DValidatePlatformVersion when the version is 10.0
In later versions of Visual Studio, this means "the highest
version out of whatever platform SDKs are installed".
* Add VS2019 support to Win2D.proj
* Use explicit SDK version
* Use PlatformToolset from Win2D.Cpp.props
* Update version in solution file header
* Port ShaderCompiler fixes from xaml_islands branch
* Re-add explicit PlatformToolset
* Update code generator to match manual changes
* Update README
* Update build.cmd
* Update TargetPlatformVersion in sample projects
* Silence deprecation warning/error
* Fix double-definition build error
* Fix ambiguous-definition errors
* Tests running on VS 2019.
Turns out this is required when consuming new style .csproj NuGet references. The NuGet
restore operation generates temp files into the obj folder, which is unique per config,
so restoring just one config doesn't enable building others.
This change also switches from restoring individual projects to restoring the top level
.sln. We previously avoided that to work around a NuGet bug that is no longer relevant.
Restoring the .sln is simpler and MUCH faster.
The UWP C# project system has migrated from project.json to a newer .csproj mechanism for referencing NuGet packages, and newer versions of the commandline nuget.exe no longer support restoring packages from project.json. This change updates Win2D to match.
This reverts the two commits:
"Still build Intellisense even though main doc build is disabled" (66adb0f22e)
"Temporarily disable building docs, until github #390 is fixed" (13f20335b8)
This was previously using the non-universal version of the test framework, which somehow
managed to work ok with VS 2015 Update 1, but is not the right thing and broke with
Update 2.
Also reorganized the directory structure to keep things clear as this test project now
includes some UAP-only app files. test.external is split into Shared, UAP, Windows, and
WindowsPhone sub folders, just like we already did for the samples and test.managed.
Currently implemented checks:
- Tabs should be spaces
- Missing space after keyword
- Lambda with no parameters should not include ()
- Lambda indentation
If an app does not directly reference any numerics types, the current compiler incorrectly drops
its reference to System.Numerics.Vectors.dll, which breaks the build. Workaround is to always
include a stub assembly that explicitly uses one of the numeric types.
This example shows how a background task can use Win2D to draw images that are saved to disk. These images are then used on the app's live tile.
Currently only for UAP projects since a bug in VS2013 Update 4 does not allow WinRT components to consume Win2D.
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.
This uses Win2D to draw scrolling text into a rendertarget, maps that
rendertarget onto a 3D teapot model (which is drawn via DirectXTK),
then uses Win2D image effects to apply a bloom postprocess filter.
Currently only for 8.1 (not UAP) due to lack of UAP NuGet package for DirectXTK.
Geoffrey Trousdale
Ian Blaauw
Shawn Hargreaves
Alexandre Zollinger Chohfi
Damyan Pepper
Claire Andrews