Games for Windows and the DirectX SDK blog

Technical tips, tricks, and news about game development for Microsoft platforms including desktop, Xbox, and UWP

Project maintained by walbourn Hosted on GitHub Pages — Theme by mattgraham
Home | Posts by Tag | Posts by Month

GitHub, NuGet, and VSTS

github

Originally posted to Chuck Walbourn's Blog on MSDN,

There are April 2018 releases on GitHub for DirectX Tool Kit (DX11 / DX12), DirectXTex, DirectXMesh, and UVAtlas. These were more minor releases focused on code quality, fixing a few bugs, and cleaning up some new /analyze issues based on the C++ Core Checker rules that will be appearing in Visual Studio 2017 (15.7 update) which is currently in preview.

I’m mentioning these because there are some changes happening with NuGet where I’ve also been publishing new releases of many of these libraries that has some important implications I wanted to announce.

The Good

NuGet packages are getting support for digital signing, which means better security when consuming signed packages in your applications. Packages published by Microsoft now also have more official organizational ownership rather than being published by individual Microsoft developers private Microsoft Accounts.

See this NuGet blog post for more details.

To support digital signing, I’m setting up Visual Studio Team Services (VSTS) build support for my libraries so they can be more officially built than just sitting on my machine. Much of Microsoft’s internal processes have migrated to using VSO for building including my group’s samples work, so this is generally all goodness and it’s been a good learning experience making use of the cloud-based build services.

The Bad

One consequence of moving to the VSO build solution, however, is that I need to drop support for Visual Studio 2013, Windows Store 8.1, and Windows Phone 8.1. The VSO hosted build services support VS 2015 and VS 2017, so I will continue to support VS 2015 Update 3 & VS 2017 for Win32 desktop applications for Windows 7 SP1 or later, Universal Windows Platform (UWP) apps, and Xbox One XDK development.

As such, the April releases above will be the last to support Visual Studio 2013, Windows Store 8.1, or Windows Phone 8.1. The existing NuGet packages for these platforms are still available (directxtk_desktop_2013, directxtk_windowsstore_8_1, directxtk_windowsphone_8_1, and fx11_desktop_2013), but will no longer receive any updates–much like I had already done for the Windows Phone 8.0 package (directxtk_windowsphone_8) when I dropped VS 2012 support some time ago.

Mine are not the only open source packages from Microsoft so affected, so expect most of them to be dropping these platforms as well.

As an aside, this change is good news for me. This greatly reduces the number of configurations I maintain and let’s me focus on the more complete C++14 language and Standard library conformance in VS 2015 or later with a lot of messy conditional compilation. I realize it’s a potential hardship on some users of these libraries, but you can continue to use the April 2018 or earlier releases.

Note that Xbox One XDK development never supported VS 2013.

The Ugly

Another consequence of the move to the VSO build solution is that I can’t make use of the legacy DirectX SDK in those solutions that are published as NuGet packages. For the most part I don’t need the legacy DirectX SDK for anything since that’s one of the main motivations for doing these libraries in the first place. There is, however, one specific scenario that still require the legacy DirectX SDK: XAudio 2.7 support for Windows 7.

None of “The Ugly” here applies anymore thanks to XAudio2Redist. The directxtk_desktop_2017 package now includes DirectX Tool Kit for Audio that supports Windows 7 SP1 or later.

Up through the April 2018 release, the NuGet directxtk_desktop_2015 package includes DirectXTKAudioDX.lib which uses XAudio 2.7 to support Windows 7, but I will now have to make it include the DirectXTKAudioWin8.lib instead for the May 2018 and later versions of the NuGet package. That means if you using a project that is set up to use DirectX Tool Kit for Audio with Windows 7 (``_WIN32_WINNT`` set to 0x0600 or 0x0601), you'll now get a build failure including "Audio.h" or trying to link. The newer Win32 desktop NuGet packages will work fine if you are building for Windows 8 or later (``_WIN32_WINNT`` set to 0x0602, 0x0603, or 0x0A00). Use of the DirectXTKAudioDX.lib already required some gymnastics with the legacy DirectX SDK and imposed specific deployment requirements using legacy DirectSetup. If you need DirectX Tool Kit for Audio support on Windows 7, I recommend you move to using project-to-project references instead of the NuGet package. The Win32 desktop NuGet package will still be built for Windows 7 SP1 support for the graphics, input, and math functionality so this only affects you if you are using DirectX Tool Kit for Audio. There are also no issues when using the UWP packages since XAudio 2.8 or later is always available on those platforms.

C++/WinRT: Note that I’m also no longer updating the cppwinrt NuGet package. As of the Windows 10 SDK (17343), the C++/WinRT headers are include in the Windows SDK per this blog post. Therefore, the 2017.10.13 NuGet package which supported the Windows 10 Fall Creators Update SDK (16299) is the last one, and the related GitHub project is now archived.

Update: See this blog post for the latest information on NuGet signing support. The following NuGet packages are now available digitally signed: DirectXMesh (directxmesh_desktop_2015, directxmesh_uwp), DirectXTex (directxtex_desktop_2015, directxtex_uwp), DirectX Tool Kit for DX 11 (directxtk_desktop_2015, directxtk_uwp), DirectX Tool Kit for DX12 (directxtk12_desktop_2015, directxtk12_uwp), DirectXMath (directxmath), and Effects for Direct3D 11 (fx11_desktop_2015).