Universal Windows Platform Support (Beta)
We are proud to announce that we are launching beta support for building and signing Universal Windows Platforms applications in Unity Build Automation on Tuesday April 25th. This includes support for all platforms supported by UWP; including Xbox.
All Unity DevOps and UCB 2.0 customers will not be billed during the initial beta period. The beta period starts on Tuesday April 25th and will last until Tuesday May 23rd.
During this initial beta period please reply to this post with any issues you encounter or features we are missing. To quickly help us diagnose the issues please provide your ORG ID, Project ID and target name (or just paste a link to the build history for the target). This will help us find your project quickly and dig into the logs. We will update this post with identified issues and attempt to provide target resolution dates.
UWP applications have a wide range of configuration options. There are two core options that drive building UWP applications: Visual Studio and Windows SDK.
Visual Studio Version - This defines the version of Visual Studio that will be used to build the UWP application once Unity has completed compiling the code and creating a Visual Studio Project.
Windows SDK Version - This value depends on the visual studio version selected. This will set the Windows SDK version that the application will target when building with Visual Studio.
Credentials
Initially, we will only support automatic signing of all builds (including debug/development builds). We are working on generating test certificates and bundling those into debug/development builds. We are also requiring certificates for ExecutableOnly builds of UWP applications, although the certificate will not be used for signing the built executable.
A credential file in the form of .pfx is required. The pfx must be password protected.
Build Configuration
The following build configuration options are available.
Build Type - This is the output of the Unity portion of the build. The supported types are Executable Only, D3D, and XAML. Additional details on this are found in the Build Type property in the UWP Build Settings
Build Configuration - This setting determines the optimization level of the code along with the profiler settings for the build output from Visual Studio. We default this to “Release” if no value is set during target configuration. Additional details on this are found in the Build Configuration property in the UWP Build Settings
Target Device Family - This setting determines which devices the output is optimized for. We default this to Universal. Multiple device families can be targeted during a build. Unity - Scripting API: WSATargetFamily
Capabilities - This is a list of capabilities that the application requires in order to run after being built. More information on the available values are in the Unity Manual: Unity - Scripting API: WSACapability
Executable Only CPU Architecture - This value is only available when the build type is set to Executable Only. This will determine the CPU architecture that the output executable will be able to run on. If no value is provided, we default to x64
Targeted CPU Platforms - This value is available when the build type is either D3D or XAML. This will set the AppxBundlePlatforms property. Example values are x64, x86, ARM, ARM64. This defaults to x64.
Build Output
When the build type is defined as ExectuableOnly, the primary artifact output will be the folder containing the built executable.
When the build type is defined as D3D and XAML, the primary artifact output will be a .appxupload file that is signed and ready to be uploaded to the Windows Store. The secondary artifact will be the AppPackages containing the signed .appxbundle file. This can be used to sideload the application for testing.
FAQ
Can I really build for Xbox?
Yes. You can leave the target family as Universal or optimize the build by setting the target family to Xbox. UWP does not provide native support for Xbox using the GDK. Native support for Xbox through the GDK is in active development with the goal of launching this year. We understand that building consoles and desktop games requires more powerful build machines than we currently offer. Support for more premium machines is also in active development with the goal of launching before the end of Q3 this year.
How do I generate a cert?
You can use Visual Studio to generate a certificate by following Microsoft’s instructions here:Get a developer license - Windows app development | Microsoft Learn
If you are on Windows, you can also generate a certificate using Powershell by running the following commands. Grab the thumbprint from the first command and replace $thumbprint with its value in the third command:
New-SelfSignedCertificate -Type Custom -Subject "CN=Build Automation" -KeyUsage DigitalSignature -FriendlyName "Unity Build Automation" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")
$password = ConvertTo-SecureString -String SuperSecretPassw0rd -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\CurrentUser\My\$thumbprint" -FilePath C:\tmp\unity_build_automation.pfx -Password $password
What is an .appxupload?
The .appxupload is just a compressed file containing the .appxbundle, and .appxsym files for the bundled platforms.
Why does my certificate subject have to contain only a CN?
This is because the Windows Signing Tool will fail to sign the AppxBundle files when the subject of the certificate contains other values like O, OU, C, etc.
Why doesn’t Unity Version X allow me to use Visual Studio 2019?
Prior to Unity 2022.2 the IL2CPP compiler always used the latest MSVC toolchain installed. This means that the Visual C++ toolset used for compiling is always the 2022 version of the tools because the machines have both 2019 and 2022 versions of MSBuild installed.
Unity 2022.2 now respects the version of MSBuild being used which enables the flexibility of choosing the Visual Studio version for Unity 2022.2 and up.
How do I change the verbosity of MSBuild?
By default, we set the verbosity to minimal. You can control this by adding an environment variable to your target configuration called “MSBUILD_VERBOSITY”. You can set the following values: quiet, minimal, normal, detailed, and diagnostic.
How do I change the verbosity of SignTool?
By default, we use “q”. You can control this by adding an environment variable to your target configuration called “SIGNTOOL_VERBOSITY”. Valid values are: “q”, “v”, or “debug”.
Known Issues
ASSERT failures when building
Unfortunately, not all Unity Versions handle processing certificates in the same way. During our testing we noticed that some certificates would only work on certain versions of Unity.
When you see an ASSERT failure and issue related to setting the certificate this means that the version of Unity you are using doesn’t like your certificate. I would suggest trying to build on a newer version of Unity. If you are on the newest version of Unity and are still encountering this issue please open up a support ticket so that we can dig into your project and get more information about your certificate configuration.
Resolved Issues
“Zip 64 End of Central Directory Record not where indicated” in Microsoft Partner Center
We are hoping to have this resolved before the beta starts, but right now we are using “tar” to create the .appxupload file. When uploading the .appxupload file in the Microsoft Partner Center you might see the error: “Zip 64 End of Central Directory Record not where indicated”. This is easily resolved by “unzipping” the .appxupload file and re-creating it using Zip.
EDIT (4/17 @12:41pm central): Added info on setting the verbosity of MSBuild and SignTool
EDIT (4/17 @3:24pm central): Added info on the known issue for “Zip 64 End of Central Directory Record not where indicated”.
EDIT (4/18 @ 1:31pm central): Marking Zip64 error as resolved since it will launch with the beta