Build errors in the Unity Editor from networking from HoloLens

This is something that has been a thorn in my side for a little while. We are looking into networking solutions for the HoloLens and have tried several options. So far, the unity built in networking Unet and Photon are the only ones to build without issues. Things like Ulink, Forge, Nakama and a basic AdHoc setup all have had build errors due to using things from System.Threading, System.Net, NativeWifi and other basic System or Common Networking namespaces. Even though many or all of them are basic System usings, they cause build errors in the unity editor, and often only there.
I am coming to the conclusion that this is an issue only for the HoloLens, as I can for example, make a new unity project, import the networking package, import the HoloLens package, setup the scene and run an example in the editor. But when I go to build the solution for the HoloLens, suddenly there is a namespace error in the editor for one of these functions. It is also sometimes (but not always) accompanied by a host of errors in the visual studios debugger for broken reference from default HoloLens files or other files.
I can’t use the unity editor here due to the build compile errors, but there is another strange behavior where if the unity app is restarted, the editor can be played again until another build is attempted. I have setup the simplest project where I have the error and will link it at the end of this post. My process and issues with the Nakama package are listed below

Nakama trail of build errors:
Install package Nakama – attempt pc standalone build – built as normal
Install HoloToolkit – attempt pc standalone (not really supposed to build as this anyway for HoloLens, just doing it for science) – build errors in unity and in vs, vs errors go away with some includes or just looking at the place where the error happens.
HoloToolkit – attempt windows store build with settings for the default HoloLens build configuration – 2 build error in the editor about a system enum, ConsoleColor being not found while clearly fine in VS and a “Compiler errors so can’t build” type of error. In VS, rebuilding now finds 60 odd errors, about “couldn’t be found”, “are you missing an assembly reference?”, “does not exist in the current context” things like that. These are usually unrelated to the functions the editor claims is causing build errors. I can add a single using HoloToolkit.Unity and every single one (which were over multiple different files) can go away. I deleted the added using statement and rebuilt VS but errors didn’t return. I attempted to rebuild the executable and got the same error building unity player, compiler errors as before but the vs errors don’t return. I assume this is some odd VS error that is probably unrelated to my problem.

Basically, I’m looking if this is a common thing with networking for HoloLens which seems doubtful as I haven’t found much on the internet, but it is a new platform still, any solutions people have, any other Networking Solutions that are known to work with the HoloLens or any general information people might have on dealing with HoloLens networking.

Sorry for the lengthy post and thanks in advance for the responses.

broken project:
goo.gl/UkP31U

I'm not familiar with all those libraries and such, but have you tried building with IL2CPP? That should at least get around the quoted issue, but I'm not sure about the rest.

I tried building with IL2CPP in projects with errors from a System namespace and I got a mountain of warnings and 11 errors. some of the errors are from what appears to be a custom class from the HoloLens scripts and several errors from System.Threading. I'm going to try the answer in https://forums.hololens.com/discussion/2730/unity-missing-namespaces, which I wish I found earlier, and see if that will make it compatible.

It's kind of odd, all the errors are coming from inside the #if UNITY_METRO && !UNITY_EDITOR guards. shouldn't they prevent the compile errors here, isn't that their exact purpose? that answer also doesn't seem to help, as I guess it's already built expecting UWP so it doesn't matter?

Any chance you have your API compatibility level set to 2.0 in player settings? If you use IL2CPP, you'll need to set it to 4.6 to be able to access all the new Windows APIs.

I'm not sure if I can alter that when building for windows store in the editor. the option for API compadibility is WSA Subset but the option is greyed out so I can't change it there. I know there is code to change the API compatibility level, but if my error is at compile time that won't help.

However, I have been able to make a build somehow, though I'm not sure if it has the same functionality without testing. switching to IL2CPP helped, then I had to go through the hololens files and comment out everything in the #if x guards except a few of #if !UNITY_EDITOR alone. after that there were still some errors with missing references from the Type namespace, so I removed the problem functions and just returned the Type as it was passed to the function (which will invariably break something) but it is at least a start.

Are you on an ancient version on Unity? Because on Unity 5.6 and newer, I have 3 options for API compatibility level on Windows Store.

not ancient, but it's 5.5.3 so old enough. on 5.6 I have the option and tried setting it to 4.6 but many errors remain. I got it down to a few errors but some namespaces like System.Threading are missing some functions/delegates in the UWP framework and are too integrated into the networking solutions to bother trying to take them out.

Unet isn't giving us these issues so we have decided to drop the other options for being incompatible with UWP for now.

With IL2CPP and .NET 4.6 you should have all the APIs available. What kind of errors do you get?

there's several namespace not found type errors, most of it seems to come from System.Net.Sockets, and there are some from System.Threading like OpenStreamForReadAsync(). these 2 have been the usual suspects whenever the build fails. it did help for several of them though. several of the problem namespaces like NativeWifi were able to be recognized, and Nakama was able to be built without any changes. Forge had issues with TCPListener and NetworkStream. uLink is a bit outdated and might just have errors from that, it has a lot of RPC calls that are obsolete now, though that shouldn't be causing build errors. another one just had to remove a couple functions that used System.Threading and it could be built.

Ah yeah, OpenSteramForReadAsync is one of very few methods we didn't get to implementing yet.