Hi,
I was able to get the Video Chat Demo example working in the Unity editor(2019.2.17f1).
But after importing the Mixed Reality Toolkit, the build fails in Unity.
I am getting the following errors:
Assets\Microsoft.MixedReality.WebRTC.Unity\Scripts\Media\LocalVideoSource.cs(230,21): error CS0234: The type or namespace name 'HolographicSpace' does not exist in the namespace 'Microsoft.Windows.Graphics.Holographic' (are you missing an assembly reference?)
Assets\Microsoft.MixedReality.WebRTC.Unity\Scripts\Media\LocalVideoSource.cs(234,29): error CS0234: The type or namespace name 'ApplicationModel' does not exist in the namespace 'Microsoft.Windows' (are you missing an assembly reference?)
Assets\Microsoft.MixedReality.WebRTC.Unity\Scripts\Media\LocalVideoSource.cs(234,89): error CS0234: The type or namespace name 'ProcessorArchitecture' does not exist in the namespace 'Microsoft.Windows.System' (are you missing an assembly reference?)
How to resolve this issue?
Also I am trying to deploy the application in Hololens 1.
If this was working before importing MRTK then it sounds like MRTK changed something to the project on import. I know they do some checks and change some project settings, but wouldn't know on top of my head what exactly. The error message is curious because those namespaces are from Microsoft and I believe are always automatically imported by Unity whether or not you explicitly set a dependency to them. I tried importing MRTK some time ago and it was working, but didn't try recently.
Are you trying to run in the Editor (Play mode), or are you making a Build, and which one? I assume you're making a UWP x86 build, but just want to be certain. What Windows SDK version are you using? We don't really test nor support anything below 17763 at least, preferably 18362.
Ping @thalbern, @lukastoenneMS, @andreiborodin > Have you ever seen that assembly reference error with MRTK? Any idea what can cause this?
Hi,
I was making a UWP x86 build. The Windows SDK version that I am using is 18362.
I was able to resolve this issue by referencing the global Windows namespace as mentioned here
https://github.com/microsoft/MixedRealityToolkit-Unity/issues/6511#issue-519423415
Alright, sounds like there's something for us to fix then 馃槈
Actually while trying to apply that fix I just realized you are using the .NET scripting backend with UWP, is that correct @Amarnadhp906 ? We do not support that, for several reasons:
See #53 for a similar issue. You need to use the IL2CPP backend with UWP. And then the error will disappear as a consequence.
We don't support .NET Standard 2.0 on .NET scripting backend. It's only supported when using Mono and IL2CPP.
Can you please confirm this is correct? If so I will close as Invalid since we don't support the .NET scripting backend for UWP.
Hi @djee-ms ,
I am using IL2CPP as scripting backend and API level is .NET 4.x with UWP. Unity editor version is 2019.2.17f1.
Sorry I am still confused. You say the build fails, you mean from the Editor's Build menu it fails to generate a Visual Studio solution for UWP, correct? Or do you mean inside the Editor you cannot press Play? For the former, if you use IL2CPP then why would you get an error compiling a C# file? LocalVideoSource.cs should have been transpilled to C++ by IL2CPP, so the C# compiler is not invoked at all in this case (at least as I recall). But the errors you pasted are C# compiler errors (CS0234). Can you please describe in details your repro steps? I don't get any error with IL2CPP, though I didn't try importing MRTK yet.
Hi @djee-ms ,
you mean from the Editor's Build menu it fails to generate a Visual Studio solution for UWP, correct?
Yes, that is correct.
I don't get any error with IL2CPP, though I didn't try importing MRTK yet.
I also didn't get any build(to generate a Visual Studio solution for UWP) errors before importing MRTK. The build error occured after importing MRTK.
Steps to reproduce the build error-
After discussing with a colleague we think that what is happening is:
I will add the missing global:: where necessary. In any case it won't change the behavior, and since you confirmed it prevents the error, it is always good to take.
Adding the global:: keyword worked for me.
Most helpful comment
After discussing with a colleague we think that what is happening is:
I will add the missing
global::where necessary. In any case it won't change the behavior, and since you confirmed it prevents the error, it is always good to take.