A couple of weeks back we noticed that our builds, made on our workstations, started to report a error when creating Store Packages which included a 86x Master package in Visual Studio. Luckily our Build-PC wasn’t affected but sadly it has now.
Creating a 86x Debug package works fine but we won’t be able to push that to the Windows Store. A 64x Master package works fine as well but we have to support x86 systems as well.
Most “fixes” that I could find didn’t work, see the list below.
This usually indicates that Microsoft’s .NET native toolchain runs out of memory. Unfortunately there could be multiple reasons for that, including you having too much code or you hitting some pathological path in the compiler. Since it started happening recently, do you know what change you made that had it start happening?
It’s really hard to say, the build PC which we’d usually make the builds with didn’t change at, maybe a sneaky Windows update happened but I’m not sure. About the project, it changes constantly and it contains quite a bit of classes, folders, assets and code but what would be “too much”?
I’m not sure what a pathological path would be, not a native English speaker. Is there a way to track this down or maybe some best practices to avoid issues like that?
Something I figured out yesterday that I’m able to build with .NET Native enabled but only when I disable the “Optimize code” option in Visual Studio. I tried to figure out what this option does and I sounds like disabling that would be a bad idea. I’m not even sure if the app would be able to go through the validation process.
Are there any things we’d be able to try? We tried all of these things below but no acceptable results.
Force 64 bit compiler.
Enable ShortcutGenericAnalysis.
Updating/Downgrading the various NuGet packages.
Removing the default directive from the .rd.xml file.
Adding custom directives to stop optimization or inlining of some assemblies.
Using Visual Studio 2015.
Building the Unity project with different settings, target PC only, target older SDK, etc.
Disable Anti-virus during building. (Why did I even try this?)
Stripped unused scenes and assets from the project. (Didn’t strip any code though)
Tried compiling the Unity project using IL2CPP backend. (Sadly this causes a lot of other issues to pop up so we cancelled trying this)
Disabling .NET Native tool chain. (Works, but the app won’t be accepted in the store)
Disabling Optimize code. (Works, but we have no idea what the side effects are)
Our previous packages are already on the Windows Store, we planned to release an update this thursday but it seems we’ll only be able to push a 64x packages this time. Hopefully we don’t have much users that use the 86x application because that’s probably going to cause issues.
Would using Assembly Definition Files to split our codebase into a couple of Assemblies be a way to ease it on the .NET Native compiler? That’s something we’re trying now but requires quite some fixes because it does not support circular references.
I do not know whether it will work. It’s worth a try.
Last time I talked with Microsoft, they said that the compiler can handle around 250-300K methods without going out of memory. Any more than that and you’ll be pushing it.
“Pathological path” would be a small piece of code that causes other code (in this case the compiler) to behave incorrectly (crash by going out of memory, in this case).
Are you using source control for your project? If you are, you could try bisecting which change introduced the failure. It’s definitely something in your code or plugins that you use - it won’t be a change in toolchain or windows update.
We very recently saw a similar thing reported to us and it turned out to be caused by the compiler choking on v.4.1.2.0 of Photon3Unity3D.dll. Are you by any chance using that plugin? If so, the workaround is to use a slightly different version (we found v.4.1.1.17 works).
We’re using source control so I’ll try some earlier versions. I should be able to compare the method count as well. According to the build output we’re already on 291k+ methods.
We don’t use the Photon plugin but I’ll rip out some plugins and hopefully I’ll be able to figure out what’s causing our problem.
Thanks for the information, I’ll keep this thread updated.
I am a colleague of Roy and working on the same issue now. As far as I know the issues happened after the big windows april update (1803).
I even tested with an older version from 3 months back. Which worked perfect at that time. But gives the same error now.
I will do some more tests to see if I can find a solution for this problem.
We have shifted our project to Unity 2018.2.9f1 and started using the IL2CPP to circumvent this issue. We’re now able to create 86x packages again but sadly some functionality that was previously working fine results in a WinStore App and Unity Editor crash.