[UWP][ARM][.Net] VS2019 fails building project generated for empty scene. Unity 2018.4.17

I am trying to support a customer of ours on Hololens 2. They (have to) use .Net as scripting backend, so I got 2018.4.17f1. I generate a project ("build" button) but trying to build that in VS2019 fails. Even for an empty project with just TextMesh Pro and the Package Manager UI in it.

The errors:

Is there any UWP SDK version that's known to work? Or a a specific Unity version?
Any settings I should check?

 

Update: I was only trying to build the config "ARM" as this targets Hololens 2. That failed.
I selected x64 and built that in VS. Success.
Back to ARM: It also builds.

I am puzzled.

 

Typically these errors indicate a bad or conflicting VS/Unity installation or a missing .NET framework installation. See this thread for more details: https://forum.unity.com/threads/pre...ined-or-imported-what-do-i-have-to-do.588151/. But in this case (since it builds for x64) something else is amiss.

I was able to repro the issue on my machine and found changing the Language Version to C# 6 appears to fix the problem.

1. Open the VS Project Properties (settings)
2. Select 'Build' tab and click 'Advanced' button
3. Change the Language Version (1st drop-down) from "C# Latest Major Version (default)" to "C# 6"

For me the project now successfully builds.

 

Thanks for the input.
Yes, I have also had projects fail to build once but refresh NuGet on the next attempt. Then I typically saw some indication in the VS project that some reference wasn't available (yellow triangle icon).

I will test the Language Version switch and report.

 

Thanks for the input.
Yes, I have also had projects fail to build once but refresh NuGet on the next attempt. Then I typically saw some indication in the VS project that some reference wasn't available (yellow triangle icon).

Update: I tried to set the Language Version for the project but can't in the UI. Quick search gets me this:

So, I add <LangVersion>6</LangVersion> and next I run into a problem with the AssemblyConverter:

The Error Panel shows:

This is still for an empty Unity 2018.4.17 project I just "Build". Edited the .csproj and trying a "Build" in VS for Debug, ARM.

 

I added a few (random) parts to my VS installation and now I am at a point where a "Rebuild All" works on the second attempt. NuGet will restore packages on the second attempt and then build.

This is what I added. No idea which one "helped":

 

New problem: When I add a newer .NetStandard 2.0 build of our library, Unity can't build this anymore.
Error: "CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'."


Background:

I am now able to build a project in Unity and VS and to run it on HL2 in release config.
Our customer needs a "Master" config build. This brings the native toolchain into the mix and the result is a "divide by zero exception", which I can't locate properly yet.
The exception happens in a UWP 8.1 "metro" build of the dll. There is a newer setup for it, with .NetStandard 2.0 target.

As the "metro" style dll is somewhat outdated and a problem, I want to figure out what happens with a new compile of the assembly (.NetStandard 2.0).

I removed our older dlls from the Unity project and setup the new dll. Closed Unity, deleted the library and temp folders and re-opened everything.
Everything works fine in Editor (.Net 4.x, .Net runtime and .Net Standard compatibility).

A "Build" now fails right in Unity with the error above.

Do I have to avoid .NetStandard dlls?

 

Using .NET Standard shouldn't be a problem, since it's basically just a wrapper that brings .NET Framework, .NET Core, and XAMARIN into a single API, i.e. "One library to rule them all". If your project was just using .NET Framework before. .NET Standard shouldn't make any difference (unless you're using APIs from Framework that aren't supported in Standard).

The error you're getting basically means VS is confused about the location of the .NET libraries (for some reason) and isn't providing the proper library path to the C# compiler. Unfortunately there isn't a fixed solution, and you just have to fiddle with the VS installation or NuGet packages until it works.

 

Sorry I was wrong about .NET Standard: it's not supported using the .NET Scripting Backend and can only be used with Mono and IL2CPP.

 

@timke: I want to make sure I understand this correctly:
UWP projects with .Net Scripting Backend have to select Api Compatibility ".Net 4.x"?
And can't have .Net Standard 2.0 assemblies in the project?

What would be the "optimal" target framework for assemblies in such projects?

 

Oh dang.
So "Class Library (Universal Windows)" with minimum supported OS version 10240 is the only way to produce suitable assemblies for that backend?
I hoped I could provide .NetStandard assemblies and be done with it.

 

Hm. I see. Thanks for that info!
It may help somewhat with the setup of projects for the plugin.