Resolving build issues for UWP packages with Unity

Published September 22, 2017 by Simon (Darkside) Jackson, posted by SimonDarksideJ
Do you see issues with this article? Let us know.
Advertisement

Image result for visual studio tools for unity

If you are building games and projects in Unity and targeting the Universal Windows Platform (UWP), you may have noticed than in the recent Unity releases this was actually broken. What you end up seeing in your build UWP project in visual studio is the following error:

The command “”C:\ <Project>\Export\UWP\Unity\Tools\SerializationWeaver\SerializationWeaver.exe” “C:\ <Project>\Export\UWP\GeneratedProjects\UWP\Assembly-CSharp-firstpass\bin\x64\Debug\Unprocessed\Assembly-CSharp-firstpass.dll” “-pdb” “-verbose” “-unity-engine=C:\ <Project>\Export\UWP\Lonely Shadows\Unprocessed\UnityEngine.dll” “C:\ <Project>\Export\UWP\GeneratedProjects\UWP\Assembly-CSharp-firstpass\obj\x64\Debug\x64\Debug” “-lock=C:\ <Project>\Export\UWP\GeneratedProjects\UWP\Assembly-CSharp-firstpass\project.lock.json” “@C:\ <Project>\Export\UWP\GeneratedProjects\UWP\Assembly-CSharp-firstpass\SerializationWeaverArgs.txt” “-additionalAssemblyPath=C:\ <Project>\Export\UWP\Lonely Shadows\Unprocessed” “-unity-networking=C:\ <Project>\Export\UWP\Lonely Shadows\Unprocessed\UnityEngine.Networking.dll”” exited with code 1.
Assembly-CSharp-firstpass          C:\ <Project>\Export\UWP\GeneratedProjects\UWP\Assembly-CSharp-firstpass\Assembly-CSharp-firstpass.csproj   

If you dig further, you may also expose the underlying error code here:

System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at UnityEditor.Scripting.Compilers.NuGetPackageResolver.Resolve()
   at Unity.NuGetAssemblyResolver..ctor(String projectLockFile)
   at usw.Weaver.ReaderParameters(String assemblyPath, ConversionOptions options)
   at usw.Weaver.Weave()
   at usw.Program.RunProgram(ConversionOptions options)
   at usw.Program.Main(String[] args)

This prevents you building / updating projects from Unity to the UWP Platform.

Once discovered, both Unity and Microsoft worked closely together to resolve the issues and updated their respective parts as quickly as possible.

Fixing the problem

The fix for this problem is fairly easy. However, it is a little time consuming (unless you have a mega fast download connection) as mostly it requires updating to the latest Unity and Visual Studio patch releases.

1: Install Unity 2017.1p5 or 2017.2.0f3

Image result for unity logo

The first step, is to simply update your installation of Unity:

  • If you are on Unity 2017, then this is 2017.1p5 (or newer)
  • If you are on Unity 2017.2, then this is 2017.2.0f3 (or newer)
  • For the 5.x cycle, just update to the latest patch (although I haven’t tested this)

This will update both Unity and your install of the Visual Studio Tools for Unity

2: Update VS 2017 to 15.3.3

Once Unity is up to date, you will need to update your installation of Visual Studio.  If you are still on VS 2015, then there is no action but you won’t be able to build UWP packages targeting the newer Creators update and won’t be able to build Mixed Reality platform.

I highly recommend updating to 2017, even the free Community edition of 2017 (which is free) if you are doing UWP development.  It’s just better.

To update Visual Studio 2017, simple close all open instances of Visual Studio and launch the Visual Studio Installer

image

Once it’s running (the first step may be to update the installer first), simply hit “Update” on your specific instance of Visual Studio (the installer will happily update ALL installed instances if you wish) and once it’s complete you will be on the latest version.

Open Visual Studio to verify, click “Help –> About Visual Studio” in the menu and you should be running 15.3.3 (or newer). If not, check your internet connection and try running the installer again.

image

3: (Optional) Set player settings for project to .NET & .NET4.6 
(NOT IL2CPP, XBL project does not have support for IL2CPP, yet)

Not strictly required but highly recommended for UWP projects, is to update the .NET Api Compatibility Level that is used in your built project.  This allows you to use more modern C# 6 functionality if you wish without causing errors when you build it in Unity.

To update this, open the Player Settings window in the editor using either “Edit –> Project Settings –> Player” in the editor menu, or using the “Player Settings” button on the “Build Settings” build window.  In the Other section on this configuration page you will find the following settings.

image

Not to be confused with the “Scripting Runtime Version”, which I’m told breaks UWP project builds using Xbox Live (although I haven’t personally tested yet)

Quote

*Note, I'm not saying don't use IL2CPP (which is required for some Unity features, such as the new Post Processing stack) as it is a cleaner build.  It's just NOT compatible with the Xbox-Live-Unity plugin at present.

4: Build project targeting UWP SDK 14393 or higher

To build for Modern UWP, you need to be targeting a minimum API level of 14393 (Anniversary Edition), For Mixed Reality builds you will need a minimum API level of 15063 (Creators Update).  Either will work but you need to ensure you select the version that is right for your target.  The current advice with new builds is to always target the latest but that is completely up to you.

You will find the SDK selection on the “Build Settings” screen when you have the “Universal Windows Platform” target selected:

image

5: Open project in VS

Once you have built your project, open it in Visual Studio to continue.

6: UPDATE NETCore NuGet package to 5.4+ <- without this, it still doesn’t work

In testing I have found this is critical still for existing projects or when you build your first (ever) UWP project, you need to have the latest NETCore NuGet package downloaded and available else it will fail.  you don’t have to update the other NuGet packages if you don’t want to (UWP Packages come bundled with the Application Insights NuGets for Windows Store integration for example), just the NETCore package.

When writing this article, I tried to replicate the error (after fixing it) and couldn’t generate the error even with new projects.  This step may not actually be needed but I still Highly Recommend updating any and all NuGet packages in your built project.

 

If you are unsure as to what NuGet is, you can read all about it here. Basically, NuGet is a dependency manager for .NET solutions, allowing you to disconnect your project from the source of a dependency.  It can then be updated independently without affecting your project (unless the API changes).  You will find most modern .NET packages from Microsoft (like the .NET Framework) are now NuGet packages so they can more rapidly update the framework without having to build and distribute new MSI packages.

To check and update the versions of the NuGet packages, right-click on the “Solution” in the “Solution Explorer” within Visual Studio and select “Manage NuGet Packages for Solution…

image

Alternatively, you can also simply right-Click the “References” branch in your projects structure, also in the “Solution Explorer” in VS, this however will only show/update the NuGet’s installed in that single project and not the entire solution:

image

Once the NuGet manager is open you will see the installed NuGet packages, with a notification if any updates are available (provided you have an internet connection).

image

Simply select the NuGet package to update, NETCore in this case, select the version to update to on the right and click “Install”.   You will then be walked through a set of screens to accept the license for that package (if one exists) and then a final “get out of jail free” accept or reject screen.   Once complete, all the required references included in that package will be updated.

7: Build and Run for x64 only (x86 or Arm is a no go still)

With everything in place, all that is left is to build your project. By default, Unity still insists on selecting the ARM platform as the default (don’t know why but I guess it’s too small a thing to want to change), so you will need to update this to the x64 platform (don’t use x86 unless you really need it, most UWP systems all target x64 now).  After that, you can build.

If you are unsure about which Solution Configuration to select (read, Build Type), remember what they are there for:

  • Debug

    Used obviously for debugging, enables extra debugging information to be sent to an attached instance of Visual Studio (whether you run it from Visual Studio or just “attach” to it later).  Will cause a performance hit when running but this is needed so you can walk through the code if there are any issues.  It will also enable the debug window inside Unity to report errors to the screen should they occur.

  • Release

    Builds the project but without all the debugging stuff. just runs your project.  With Unity however, it’s keen to note you are still running your entire project with all the superfluous code that Unity has in a project.  DO NOT SHIP THIS!!!

  • Master

    This is a special Solution Configuration (just for Unity) that also runs code in Unity to strip mine unnecessary code / services and packages everything together neatly.  This makes your Unity project run as fast as it can.  <- SHIP/PUBLISH THIS!!!

All well and good

With everything in this article, you should have no further issues building your UWP projects and once you have gone through it at least once (I’ve found) you need not do it again (apart from updating NuGets, you should always do that)

Any issues, let me know or comment on this post. 

 

datesgrey-pdn

 
Cancel Save
1 Likes 1 Comments

Comments

SimonDarksideJ

In response to Tautvydas Zilys comments (who is an awesome member of the Unity team!)

1. I wouldn't recommend saying "no to IL2CPP" right away, especially if you haven't tried it. It is the future of scripting on UWP in Unity, and it is the default scripting backend for UWP in Unity 2017.2. We have no known issues with Xbox Live on IL2CPP, and there have been multiple games that shipped with IL2CPP and Xbox Live functionality. It also enables you to port your game to UWP much quicker compared to using .NET scripting backend, since you have exact same C# API surface on IL2CPP as other Unity platforms. On .NET, you only get a small "Microsoft blessed" subset of APIs.

(SJ) Updated article to highlight this only relates to IL2CPP use with the Xbox Live Unity plugin.  There are many great features with IL2CPP that are worth exploring.

2. 2017.2p9 doesn't exist. I assume you meant 2017.2.0b9?

(SJ) I stand corrected.  Also updated since 2017.2 is now released

3. "Not to be confused with the “Scripting Runtime Version”, which I’m told breaks UWP project builds" - that sounds like something that should be reported to us and addressed. I haven't heard anyone complain about this.

(SJ) Tested myself with the Xbox Live Unity plugin and it doesn't work.  In fact any build attempting to use the Unity.Tasks DLL breaks using that build and makes Async inaccessible

4. There is only one reason to target Windows SDK 14393 or newer: if you want to use APIs added to that SDK. Using any SDK is perfectly valid for shipping a UWP game.

(SJ) Incorrect. Xbox LIVE is only supported from 14393 onwards.  This article was solely about Xbox Live UWP support, not general UPWP support (which yes, you can use any build that meets your criteria)

5. The Unity logo is bastardized. I'm not sure where you took it from. You can find the proper one here: https://unity3d.com/public-relations/brand

(SJ) The original logo did come from the Unity site, but I will use the updated branding in articles going forward. Thanks for the link

As a side note.  There is now a way to use Xbox Live and IL2CPP but it is not for the feint hearted. You can't use the handy Xbox Live Unity asset (that won't work atm), so you have to build it yourself from scratch.
See this article for more details:
https://docs.microsoft.com/en-us/windows/uwp/xbox-live/get-started-with-partner/partner-unity-uwp-il2cpp

October 24, 2017 09:29 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!

With the Dream Build Play competition in full swing, it came to light that a bug had developed with the Visual Studio Tools for Unity (VSTU) when building Universal Windows Projects (UWP) which is critically needed for Competition entries. Let's fix that!

Advertisement

Other Tutorials by SimonDarksideJ

Advertisement