Kestrelhttpserver: Can't run with Linux/Mono/dotnet-cli

Created on 11 Jul 2016  路  9Comments  路  Source: aspnet/KestrelHttpServer

Please see: https://github.com/dotnet/cli/issues/3835

I believe there was an error in the last version (1.0.0) and even though Kestrel runs on Linux it still tries to call WS2_32.dll

Rolling back to RC2, everything works.

Thanks!

Most helpful comment

@davidfowl, when did mono stop being apart of your test matrix? I don't recall seeing an announcement that mono was longer even tested on. There are use cases that .net coreclr doesn't yet support that mono does. Why remove it from the test matrix? Especially given that it was part of the original project announcement that mono was going to be a tested and supported platform.

All 9 comments

It's related to this https://github.com/dotnet/corefx/issues/9012.

PS: We don't support mono. I'd recommend following up on this issue there.

Hello David, thanks for replying!

Do you mean that because OS detection is broken at the moment Kestrel tries to load a Windows DLL? That explains it, I guess.

I tried the workaround in https://github.com/aspnet/KestrelHttpServer/issues/942 however I am still getting the DLL not found exception for WS2_32.dll. :(

I know Mono isn't supported, but the application I am working on has some libraries which are not yet compatible with .NET Core runtime and that's why I'm still targeting net451. Everything works super fast and great on Windows and Azure, by the way, it's just that I would like to have the ability to test the application on Linux too. Also, whilst still on the RC2 bits, there were some issues with Mono and EF Core date casting giving exceptions. Do you, by any chance know if that is Mono related or ASP.NET Core related?

Thanks for your help.

Do you mean that because OS detection is broken at the moment Kestrel tries to load a Windows DLL? That explains it, I guess.

Yep! The workaround won't work I'm assuming it's picking the windows dll with the fedora.24-x64 RID for some reason. You can try rebuilding after doing something like DOTNET_RUNTIME_ID=linux and see if that makes a difference

it's just that I would like to have the ability to test the application on Linux too

On unsupported mono? Test for what purpose?

Also, whilst still on the RC2 bits, there were some issues with Mono and EF Core date casting giving exceptions. Do you, by any chance know if that is Mono related or ASP.NET Core related?

No idea, we no longer test on mono.

@davidfowl, when did mono stop being apart of your test matrix? I don't recall seeing an announcement that mono was longer even tested on. There are use cases that .net coreclr doesn't yet support that mono does. Why remove it from the test matrix? Especially given that it was part of the original project announcement that mono was going to be a tested and supported platform.

We're currently working on the message. Will update things soon.

Yep! The workaround won't work I'm assuming it's picking the windows dll with the fedora.24-x64 RID for some reason. You can try rebuilding after doing something like DOTNET_RUNTIME_ID=linux and see if that makes a difference

Tried it, still not working but I am getting a different error: https://gist.github.com/nmilosev/30da19909b83570f8e4e4a59af401cfe

On unsupported mono? Test for what purpose?

I'm developing on Linux with Visual Studio Code, so it would be nice to be able to run the application without a virtual machine. I also tried Docker, but since it is also Linux (Ubuntu) inside, it does not work.

I'll stick to Windows VM for now, but I hope we will be able to use Mono to test/run full CLR applications on Linux, at least until more libraries are compatible with .NET Core.

Thanks again for your time David!

I made it work.

You have to use latest mono:

Mono JIT compiler version 4.4.1 (Nightly 4.4.1.0/4747417 Thu Jun 23 18:55:25 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           __thread
    SIGSEGV:       altstack
    Notifications: epoll
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug 
    LLVM:          supported, not enabled.
    GC:            sgen

I installed it from Fedora Rawhide repository.

Afterwards you have to do the following:

# Fix for not finding System.Native
sudo ln -s /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Native.so /usr/lib/libSystem.Native.so 

# this is where libraries should be
cd /usr/lib/mono/xbuild-frameworks 

# get all libraries here
cp -rf ../4.5/* . 

# some of them are here
cp -rf Facades/* . 

# run with:
DOTNET_RUNTIME_ID=linux COMPlus_INTERNAL_ThreadSuspendInjection=0 dotnet run

Application runs now, and everything is the same as with RC2, which means that the only thing not working is the date cast I mentioned. :( I think that's Mono related so I will try to see there or with the EF Core team.

Gonna try to fix that.

Thanks David for DOTNET_RUNTIME_ID=linux!

I was also having this problem on OSX, and when I looked at the debug output of Mono, I noticed that the reason System.Native wasn't being loaded was because Mono claimed it was the wrong architecture. After digging a bit (with an assist from @akoeplinger on slack), this is what I found.

As you can see here: https://github.com/dotnet/cli/blob/04f40f906dce2678d80fb9787e68de76ee6bf57e/src/dotnet/commands/dotnet-run/RunCommand.cs#L194

CLI is just exec'ing 'mono'. On my system (El Capitan on a new MacBook Pro), I installed mono via homebrew, and the mono binary in the path is located at /usr/local/bin/mono. This file is just a symlink to /Library/Frameworks/Mono.framework/Commands/mono, which is the 32-bit Mono runtime. The file command reveals that most of the framework libraries packaged with Mono are _universal_ Mach O-Files (containing both 64-bit and 32-bit images), while the System.Native.dylib shipped with CLI preview2 is 64-bit only.

Setting MONO_ENV_OPTIONS='--arch=64' (_not_ MONO_OPTIONS) will cause Mono to re-exec itself using the 64-bit runtime, and the System.Native library should load just fine at that point.

P.S. - if mono isn't finding the System.Native library at all, then you can create symlinks (I did), or you can use DYLD_LIBRARY_PATH to tell dlopen where to find it. In the end, this should work:

$ DYLD_LIBRARY_PATH=/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0 MONO_ENV_OPTIONS='--arch=64' dotnet run <kestrel app>

Simply symlinking the library was enough to get it to work for me:

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

After that, running mono MySite.exe worked fine.

Was this page helpful?
0 / 5 - 0 ratings