.NET Standard

Does Unity adopt .NET Standard?

https://docs.microsoft.com/en-us/dotnet/articles/standard/library
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

For example, I'm creating a library with no dependencies targeting `netstandard1.2` in C# 6 (with no `dynamic` and `async`) in Visual Studio 2017 RC (outside the Unity). Can Android, iOS, WSA and other platforms use this assembly? What about `netstandard1.6`, `netstandard2.0`?

Upd. See also: https://feedback.unity3d.com/suggestions/dot-net-standard-compatibility

 

@JoshPeterson @Tautvydas-Zilys Is it safe to reference `netstandard1.6` assembly (built with MSVS 2017 RC) from Unity 5.5?

 

@JoshPeterson @Tautvydas-Zilys
Please consider using standard `netstandard1.*` instead of home-made “.NET Subset”.

 

@JoshPeterson I have build a class library with .net standard 1.6 and I am having a hard time to import it with Unity 2017.

// library .csproj file
<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>netstandard1.6</TargetFramework>
</PropertyGroup>
</Project>

I get an error in Unity: System.Object is defined in an assembly that is not referenced.

I have tried targeting netstandard1.4 as well, but the problem persists.
Any ideas if I should I target the .net4.6 framework directly or if there something else I am missing ?

 

@JoshPeterson
Any news about .NET Standard support? Neither 2017.2 nor all following Beta versions tell anything about it in the version infos....would be cool if we could get a state update about the progress...

 

I got a chuckle out of microsoft's description of net standard. Typical "we made a lot of terrible decisions in a hurry, and none of our products work until 2 years later. But we promise this product, which we made in a hurry and is less than a year old, will be different."

Remember when they decided to make a Window's version for tablet and PC at the same time, which everyone except them knew was a terrible idea? Before that they were trying a windows version on cell phones (this was before Android.) That's the stuff net standard is unifying, right?

Their page even mentions Unity3D, I think. It mentions Unity mono, running on 20 platforms (20? really?) as one of the things they want to unify. So somebody at MS might be returning phone calls from Finland.

 

Once it's in, will it be mentioned in the patch notes and to use it do we just select it Scripting Runtime Version? Also, what do we gain by targeting Standard 2.0? Future compatibility? Will it be more performant or give us access to something we currently don't have?

 

Actually, yes. It will give you access to a lot of high-quality libraries written for .NET Standard in Unity-agnostic way. Currently in general you cannot reliably use third party .NET libraries which was created without Unity in mind, because Unity is so hm... special.

 

@JoshPeterson thanks for the reply, this sounds very promising!

To make an example: If you want to use high level drivers like the MongoDB .NET driver, it is currentliy not possible to run that build under Linux ( and other operating systems) because this driver is written for native .NET and/or .NET Standard. With Unitys .NET Standard 2.0 compatibility this will get possible over .NET Core which is the first "real" multiplatform SDK for .NET.
just look here for further informations:
https://www.microsoft.com/net/core#linuxubuntu

 

But would anyone using Unity ever want to use MongoDB in it?

It's a noSQL database. Those aren't good for storing game data - credit card companies use those to quickly guess whether to flag a transaction. And even so, don't you run a database on your server, and have Unity run it through the www class?

 

@Owen-Reynolds You might not want to use MongoDB. But there are a plethora of other libraries that you might find useful and that will now be available to you. In my case, I am eager for this new feature because I will finally be able to write one set of libraries and share them between ALL of the environments I work in. Currently, Unity is the only environment that I have to write custom code for. Now I will be able to write one set of libraries and use them in Asp.Net Core, Xamarin Mobile apps, and Unity. It will be a glorious day when this feature gets released into the wild!

 

@Owen-Reynolds It's not about the database actually.
I'm working on a multiplayer project and I decided to use share single code on both client and server. Save me more than half time coding, testing and maintain. Thanks .net4.6 introduced in Unity 2017.x.

But if netstandard2.0 supported.
It will unlock the high performance of .netcore on the server side and left just .net4.6 on Unity.

 

However, It's not on 2017.3 then when...

 

Are there any details on the new scripting runtime that will support .NET Standard 2.0? Is the plan to ship the new scripting runtime in Unity3D 2018.1? It would be cool to get this plan listed on the .NET Standard page: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

 

Will it still be "experimental"? What's the level of confidence in this?

 

I'm really looking forward to this, is there any timeline on 2018.1?

I'm looking at building an implementation of OmniGUI for Unity3d, but it requires .net standard.

 

Looking forward to this, just ran into a project where I need .net standard 2.0

 

I need this as well hoping for it soon!

 

Anyone managed to get SignalR Core working with Unity 2018.1 Beta? I've set .Net Standard 2.0 in the player settings but still get some issues with some DLLs for the SignalR Core Client. I know everything is still beta, but would be nice to have at least simple messaging working for the moment.

 

Anyone here confirmed 2018.1 working with netstandard2.0?

 

I tried it and it works for my own .Net Standard Libraries, but when I tried to add SignalR client to Unity3d some DLLs do not compile in the editor

 

I've been trying to get OmniGUI to work without success, the editor throws errors about it causing runtime instability and prevents the load.

 

My netstandard library also work well. Didn't tried others dependencies

 

The new SignalR targeting core 2.0 is a complete re-write. see https://blogs.msdn.microsoft.com/webdev/2017/09/14/announcing-signalr-for-asp-net-core-2-0/. That means the client side libraries for SignalR 2.2.2 will not work in the new SignalR for netcore 2.0 - you'll need to get the new packages. The way signalr works has changed and some features removed too. See that blog for initial details - this is still very early days for the new signalr as is unity 2018.1. We are experimenting but have no plans to commit dev resources until this gets out of beta as we expect things to change.

 

I get some weird behaviour when enabling .net standard 2.0 where it just seems to get confused as to if it should be referencing .net standard 2.0 or .net framework assemblies. Just to confirm you can use .net 4.x version with .net 2.0 standard api level?

Existing assets seem to go a bit beserk when I enable the 2.0 standard like Zenject or UniRx but not sure if I have some larger issue going on here. On 2018.1b7

 

We're noticing that the .csproj generated by 2018.1b10 still directly references the .NET Framework 4.6 instead of the .net standard 2.0 API level. This seems to cause issues for development on mac where .NET Framework 4.6 is not available. We can manually construct a .csproj that targets .net standard 2.0 and seems to compile the project, but it would be better to rely on the generated project.

Any news on when the .csproj generation will be updated when using .NET Standard 2.0 Api Compatibility Level?

 

Right now, putting the .net Core SignalR Client library to the project (configured with netstandard2.0 api) causes the following problems:

Unloading broken assembly Assets/Plugins/Microsoft.AspNetCore.SignalR.Client.Core.dll, this assembly can cause crashes in the runtime

Unloading broken assembly Assets/Plugins/System.Threading.Channels.dll, this assembly can cause crashes in the runtime

Unloading broken assembly Assets/Plugins/Microsoft.AspNetCore.Sockets.Abstractions.dll, this assembly can cause crashes in the runtime

Unloading broken assembly Assets/Plugins/Newtonsoft.Json.dll, this assembly can cause crashes in the runtime

Probably looking at why these errors occur would make sense even before there's final version of SignalR Core.

 

Is dynamic IL code generation supported by IL2CPP for netstandard library? I tried bond.core.csharp netstandard 1.6 library. It works with mono backend, but not with IL2CPP. I used link.xml to force include some stripped types. But I can't get IL2CPP to work with Expression<TDelegate>.Compile API. The bond library uses that API to dynamically generate IL code.

 

.NET 4.6 <> .NET Core. Unity is adopting Netstandard 2.0 support but I think there's some general confusion. Netstandard simply defines the API surface area. .NET Core and full framework are still not entirely the same beast, so importing something built to work with .NET Core is not necessarily going to work, and I wouldn't expect it to.

 

Hmm, Unity's experimental runtime supports .netstandard2.0, this SignalR Core Client library is marked as targeting .netstandard2.0. Why shouldn't I expect it to work on Unity's runtime then?

 

If it targets Netstandard and does not have a reference to something like NetCore.App, then it should work. Let me see if I can illustrate this... Microsoft hasn't done a good job of making it clear and there always seems to be some confusion.... so I'll try to simplify.

.NET Framework is the full framework... the "legacy" framework.

.NET Core is a more modular version of .NET Framework but redesigned

NetStandard isn't a framework at all. NetStandard is just a "contract" that defines the set of API's that will be available. NetStandard does not have all of the APIs that are in the full framework, and it does not have all of the APIs that are available in .NET Core. But it does say "anything that supports NetStandard will support this minimum set of APIs".

So, if an assembly purely targets NetStandard 2.0, it means that it will work in any version of .NET Framework or any version of .NET Core that supports that version of NetStandard. However, it is possible for a DLL. So, as long as your assembly only targets NetStandard and does NOT take a dependency on something like NetCore.App, then it'll be fine.

 

Diagram is not precise. .NET Standard is subset of intersection: there are APIs that are available in both .NET Framework and .NET Core but still are not part of .NET Standard, therefore cannot be referenced in library targeting netstandard.

 

That is true, but at that level it becomes hard to accurately diagram. It wasn't meant to be "precise" but rather to illustrate the point that Netstandard is just a definition of API surface area.

 

Hello @ericnondahl, can you share with us your .netstandard2.0 project template ?

 

It cannot have such reference. If it does, it won't restore properly:

log  : Installing Microsoft.NETCore.App 2.0.7.

error: Package Microsoft.NETCore.App 2.0.7 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package Microsoft.NETCore.App 2.0.7 supports:

error:   - netcoreapp (.NETCoreApp,Version=v0.0)

error:   - netcoreapp2.0 (.NETCoreApp,Version=v2.0)

error: Package 'Microsoft.NETCore.App' is incompatible with 'all' frameworks in project 'C:\Users\milosz.kosobucki\Documents\Projects\TestLib\TestLib.csproj'.

I still don't understand in what situation, a class library that targets .netstandard2.0 fails to run on .netstandard2.0 compliant runtime.

 

You're correct, I meant those two things exclusively not in combination. If it targets Netstandard 2.0 then it should run on Netstandard 2.0.

 

Hey, it turned out that I had some missing dependencies. After I got it straight, SignalR Core started to work in Unity. Yay!

Maybe I'll get to writing some blog post about it.

 

Update: After updating to SignalR Core RC1 and AspNetCore packages to 2.1rc1 it stopped working. Some inners of ASP Http client are trying to enumarate client certificates. This seems to not be properly implemented in Unity, so I'm getting NotImplementedException:

https://gist.github.com/MiKom/c8df9079fda00586cb88f933664c2f04

The code that connect to SignalR looks like this:

Code (CSharp):

1. using UnityEngine;
2. using Microsoft.AspNetCore.SignalR.Client;
3.  
4.  
5. public class SignalRBehaviour : MonoBehaviour {
6.  
7.     async void Start () {
8.         Debug.Log("Entering SignalR init");
9.         HubConnection _connection = new HubConnectionBuilder()
10.          .WithUrl("http://10.117.0.111:5000/chat")
11.          .Build();
12.  
13.         _connection.On<string, string>("broadcastMessage", (name, message) =>
14.             Debug.Log($"Message from {name}: {message}")
15.         );
16.         Debug.Log("Establishing SignalR connection");
17.  
18.         await _connection.StartAsync();
19.         await _connection.InvokeAsync("Send", "username", "is now connected");
20.     }
21. }
22.  

And here are the full projects:
Client (Unity):
https://drive.google.com/file/d/1s8aVzcY7UaYF_V4i3y3dupbjLa8LERk1/view?usp=sharing

Server (adapted from https://github.com/aspnet/SignalR-samples/tree/master/ChatSample):
https://drive.google.com/file/d/1vYxt5dOYMq8zRc50AAE_GDuWUGtW0JHe/view?usp=sharing

It seems that TLS in HttpClient is not even implemented in Mono, so I won't hold my breath to have it supported here. Too bad.

 

It seems to be related to Mono's sketchy conformance to .netstandard2.0:
https://github.com/aspnet/SignalR/issues/2232

 

I've also been working on this problem. The problem with TLS & the signalR libraries seems to be fixed on the SignalR side with the v1.0 release (it ignores TLS errors on Mono). Unity2018.2 beta release notes promises to fix it as well.

SignalR works well now in the Editor and standalone Windows, but sadly I can't get it to work in UWP. The dependency injection components throws a null-reference exception when it builds the HubConnection. I'm guessing something is being garbage collected at the wrong time. I've seen this happen with Il2CPP method delegates before.
I've got a sample built in Unity 2018.1 here: https://github.com/hannesne/SignalR_WMR_Sample/tree/dotnetcoredev/SignalRSimpleChatClientDotNetCore
It's setup to point at a SignalR server that I keep running for debug purposes, so you don't have to worry about the server component. You can also disable the VR component in the UWP player settings, to make debugging easier if you don't have VR stuff.

 

I've filed a bug-report for this issue. Will update this thread if I learn more about it.