UWP Release Builds

The first time I tried to do a Release build of my UWP application, I thought that Visual Studio had hung in some horrible loop, pegging the CPU. After all, it takes seconds to perform a debug build, surely if the release build wasn’t done in, say, a couple of minutes, something was broken, right?

After the second, third, fourth, etc, time, I stopped killing VS and left the build running for half an hour. It finished, successfully. So, I looked to see what might be going on to cause the long long long build times.

The current wisdom is that this has to do with .NET Native where, in a nutshell, UWP applications are compiled down to native code and make use of static linking to portions of the .NET framework. The upshot is your app should be (and is, in my case), somewhat more snappy in terms of startup and usage (more details in this MSDN article).

There are a couple of downsides that I see:

  1. Running a release build inside of Visual Studio gives abysmal performance. It is not representative of what a release build behaves like running standalone.
  2. The build time is a big impediment to the build-test-fix cycle we’ve all become accustomed to in VS.

Since (according to the first post I linked), .NET Native builds are what customers are going to see when they download your app from the Store, it behooves us as developers to periodically do a test pass with a release build. Not likely as often as we might have previously, but often enough to periodically see if we’ve broken something and certainly before submitting to the store.

My current test workflow involves performing a Store build, but only checking off x86 as a target (i.e., avoiding the need to build x64 and ARM) and then deploying the package to an unadulterated test system. It’s worth noting that I haven’t yet hit any gotchas resulting from .NET Native compilation (just my own errors!) I am sure though, at some point, I am going to hit one and need to go through a build-test-fix cycle on a release build, and I’m truly not looking forward to it.

Net though: better for our customers, even though it causes us developer types some pain.

Leave a Reply

Your email address will not be published. Required fields are marked *