• 09/22/17 03:19 AM

    Resolving build issues for UWP packages with Unity

    Engines and Middleware

    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

     


      Report Article


    User Feedback

    Create an account or sign in to leave a review

    You need to be a member in order to leave a review

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now


       2 of 2 members found this review helpful 2 / 2 members

    Nice article, though I do have some comments on certain things.

    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.

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

    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.

    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.

    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

    Tautvydas Zilys,
    Developer working on UWP at Unity

    Share this review


    Link to review

      

    Thank you. I've been looking for a solution for a long time.

    Share this review


    Link to review