DllNotFoundException: System.Native when executing RuntimeInformation.IsOSPlatform on mono

[svick]

I'm trying to run a basic ASP.NET Core application on Ubuntu 16.04 using mono 4.2.1 and .Net Core 1.0:

1. mkdir webapp, cd webapp, dotnet new -t web
2. in project.json, remove Microsoft.NETCore.App from dependencies, change frameworks to: "net451": { }, remove prepublish from scripts
3. dotnet restore, dotnet publish
4. mono bin/Debug/net451/ubuntu.16.04-x64/publish/webapp.exe

At the last step, I get an exception:

Unhandled Exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: System.Native
  at (wrapper managed-to-native) Interop+Sys:GetUnixNamePrivate ()
  at Interop+Sys.GetUnixName () <0x40d02200 + 0x0000b> in <filename unknown>:0 
  at System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform (OSPlatform osPlatform) <0x40d02190 + 0x00023> in <filename unknown>:0 
  at Microsoft.Extensions.Logging.Console.ConsoleLogger..ctor (System.String name, System.Func`3 filter, Boolean includeScopes) <0x40d01bb0 + 0x00153> in <filename unknown>:0 
[snip]

Since there is no System.Native in the publish directory, I attempt to work around this by adding "runtime.ubuntu.16.04-x64.runtime.native.System": "1.0.1" to dependencies.

This copies System.Native.so (and System.Native.a) to publish, but I still get the same exception. Then, by setting MONO_LOG_LEVEL="debug", I figure out that mono is mostly looking for libSystem.Native (or libSystem.Native.so). So I run mv System.Native.so libSystem.Native and now the application finally executes.

Trivial console application trying to reproduce the issue behaves differently. dotnet publish publishes a different version of System.Runtime.InteropServices.RuntimeInformation.dll: it seems it's the one from runtimes/unix/lib/netstandard1.1 from the NuGet package for the ASP.NET Core application, and the one from lib/net45 for the trivial console application. I believe this is caused by referencing the libuv package, which forces the use of runtimes.

Note: I didn't use dotnet run at first, because that encounters a a different bug. But the workaround for that (use dotnet run -c Release) throws the same DllNotFoundException as above.

Originally reported as dotnet/core#205.

[TheRealPiotrP]

The dotnet CLI does not support producing mono-compatible outputs at this time.

[jasoncavett]

I believe I just ran across this same issue, so I wanted to double check before investigating down a different path. Does this basically mean that, at this time, there is no recourse for developing a net451 (or similar) application on OSX?

If it makes any difference, I'm seeing this issue when I use dotnet run and I'm on RTM. I'm running mono 4.4.1.

If the answer is the same, what is the plan (if any) to support mono-compatible outputs? Is there an alternative?

[CL0SeY]

@jasoncavett I've worked around it by putting this into my Dockerfile for mono builds but that would probably have side-effects if you're looking to target future versions of the framework. Not sure if it works on OSX either, but could give it a go.

ln -s /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Native.so /usr/lib/libSystem.Native.so

[jasoncavett]

Thanks @CL0SeY. As I'm on OSX, I see that I have no *.so files in the shared libraries. Instead, I have System.Native.a and System.Native.dylib. Is this what I want? (Not sure if you know or not.)

[CL0SeY]

@jasoncavett It would probably be something similar. Give it a go and see? :)

[jasoncavett]

Hi @CL0SeY. I think I'm going to bypass this altogether and spend time switching to use netcore. I appreciate your help. Thank you.

[aggieben]

@jasoncavett see dotnet/cli#3964 . You might be able to make use of the same install_name_tool workaround described there.