New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't run with Linux/Mono/dotnet-cli #963

Closed
nmilosev opened this Issue Jul 11, 2016 · 9 comments

Comments

Projects
None yet
6 participants
@nmilosev

Please see: dotnet/cli#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!

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Jul 11, 2016

Member

It's related to this dotnet/corefx#9012.

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

Member

davidfowl commented Jul 11, 2016

It's related to this dotnet/corefx#9012.

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

@nmilosev

This comment has been minimized.

Show comment
Hide comment
@nmilosev

nmilosev Jul 11, 2016

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 #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.

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 #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.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Jul 11, 2016

Member

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.

Member

davidfowl commented Jul 11, 2016

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.

@smbecker

This comment has been minimized.

Show comment
Hide comment
@smbecker

smbecker Jul 12, 2016

@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.

@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.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Jul 12, 2016

Member

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

Member

davidfowl commented Jul 12, 2016

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

@nmilosev

This comment has been minimized.

Show comment
Hide comment
@nmilosev

nmilosev Jul 12, 2016

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!

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!

@nmilosev

This comment has been minimized.

Show comment
Hide comment
@nmilosev

nmilosev Jul 12, 2016

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!

nmilosev commented Jul 12, 2016

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!

@aggieben

This comment has been minimized.

Show comment
Hide comment
@aggieben

aggieben Aug 1, 2016

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>

aggieben commented Aug 1, 2016

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>
@Daniel15

This comment has been minimized.

Show comment
Hide comment
@Daniel15

Daniel15 Aug 22, 2016

Contributor

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.

Contributor

Daniel15 commented Aug 22, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment