Unable to start Silo in 1.0.10 Mono + Ubuntu

[KodrAus]

Hi all, I'm trying to sink my teeth into Orleans, but am running into an issue on Mono in Ubuntu when following the Minimal Orleans Application tutorial. The error looks like this:

ERROR   100439  Silo    127.0.0.1:11111]    !!!!!!!!!! Exception during Silo.Start  
Exc level 0: System.Collections.Generic.KeyNotFoundException: Unable to find a type named Orleans.Providers.IProvider, Orleans, Version=1.0.0.0, Culture=neutral, PublicKeyToken=070f47935e3ed133
   at Orleans.Runtime.CachedTypeResolver.ResolveType (System.String name) in <filename unknown>:line 0
   at Orleans.Runtime.TypeUtils.ResolveReflectionOnlyType (System.String assemblyQualifiedName) in <filename unknown>:line 0
   at Orleans.Runtime.TypeUtils.ToReflectionOnlyType (System.Type type) in <filename unknown>:line 0
   at System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].MoveNext () in <filename unknown>:line 0
   at System.Linq.Buffer`1[TElement]..ctor (IEnumerable`1 source) in <filename unknown>:line 0
   at System.Linq.Enumerable.ToArray[TSource] (IEnumerable`1 source) in <filename unknown>:line 0
   at Orleans.Runtime.AssemblyLoaderCriteria.LoadTypesAssignableFrom (System.Type[] requiredTypes) in <filename unknown>:line 0
   at Orleans.Runtime.AssemblyLoaderCriteria.LoadTypesAssignableFrom (System.Type requiredType) in <filename unknown>:line 0
   at Orleans.Runtime.SiloAssemblyLoader.LoadApplicationAssemblies () in <filename unknown>:line 0
   at Orleans.Runtime.SiloAssemblyLoader..ctor () in <filename unknown>:line 0
   at Orleans.Runtime.GrainTypeManager.Start (Boolean strict) in <filename unknown>:line 0
   at Orleans.Runtime.Silo.DoStart () in <filename unknown>:line 0
   at Orleans.Runtime.Silo.Start () in <filename unknown>:line 0

It looks like it's trying to locate a service of type IProvider instead of an implementation of IProvider? Is that expected? Or am I just missing some bootstrapping because I'm not on Windows / Visual Studio?

Thanks :)

[KodrAus]

I've been poking around and it looks like it's loading types from assemblies based on the executing assembly path. Does that fact that I'm running via dnx make any difference? Given that its assemblies are in memory?

[sergeybykov]

I don't know what dnx is. It simply scans assemblies via Reflection trying to find interesting types (grain classes, providers, etc.).

In your case it may be failing for some reason to resolve the dependency on IProvider which is defined in Orleans.dll, but I'm not 100% sure.

[KodrAus]

Is there any way I can interact with the dependency resolver with the 1.0.10 package to see if I can work around it?

DNX is the new .NET project design/execution environment that runs cross platform. It's living under the aspnet project right now, but is suitable for any kind of .NET app. On non-Windows platforms if your application targets .NET 4.5.* then dnx will run your application on mono, otherwise you can use coreclr.

Orleans already has a project.json file, so I assumed it was all fully compatible :) I might go reach out to some guys I saw working to get the Orleans project building and running on Ubuntu and see how that's going.

[gabikliot]

@kidraus, did you manage to solve this? You may try now, with the latest code from master branch, which includes the new code generation #528.

[KodrAus]

@gabikliot I'd just started using it on Windows instead, but will give it another go. Thanks!

[KodrAus]

So I had another crack at running on Ubuntu with dnx 1.0.0-rc1-15838 and mono Stable 4.0.4.1/5ab4c0d.

I compiled and packed npkgs of the latest source on a Windows box and added them to a local nuget feed in Ubuntu. I'm now getting a different error:

Mono: The class Orleans.CodeGeneration.OrleansCodeGenerationTargetAttribute could not be loaded, used in Orleans, Version=1.0.0.0, Culture=neutral, PublicKeyToken=070f47935e3ed133
Can't find custom attr constructor image: /home/ashley/.dnx/packages/Microsoft.Orleans.OrleansRuntime/1.0.10/lib/net45/OrleansRuntime.dll mtoken: 0x0a00000d
System.TypeLoadException: Could not load type 'Orleans.CodeGeneration.OrleansCodeGenerationTargetAttribute' from assembly 'Orleans, Version=1.0.0.0, Culture=neutral, PublicKeyToken=070f47935e3ed133'.
  at OrleansDemo.Host.Program.InitSilo (System.String[] args) [0x00000] in <filename unknown>:0 
  at OrleansDemo.Host.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 

Logging in Mono is set to debug:

export MONO_LOG_LEVEL="debug"
export MONO_LOG_MASK="asm,type"

I'm guessing there's something about OrleansCodeGenerationTargetAttribute that isn't compatible with mono? I'm not too sure at the moment, but will keep digging.

For reference, I've made a gist with the complete mono output when spinning up (it's enormous).

[veikkoeeva]

@KodrAus I just wanted to note that you are sailing on somewhat uncharted waters here as there is only one ticket, https://github.com/dotnet/orleans/issues/332, before you about this. This is definitely something that is worked towards to, but thus far the majority, if not all, of the active contributors are running Windows boxes, so progress on Linux compatibility has been more as a by product of other efforts. It looks like @dVakulen is also on CoreCLR refactoring spree, which further reduces the xplat gap.

Roslyn support was just recently pushed to master, so it might help to stem out some code generation issues you encounter (Roslyn on Mono looks a tad complicated though).

[grahamehorner]

@veikkoeeva @KodrAus to allow Orleans to run under DNX on Windows/Linux/iOS it firstly has to be CoreCLR compliant which is a big task in itself, given a lot of reflection/dynamic assembly loading has changed (for the better) and AppDomain don't exist. I'm trying out my own implementation of Orleans that is feature compatible and can run under DNX; but as yet can publish as it's not work yet. :8ball:

[sergeybykov]

@KodrAus, did you compile it with the published 1.0.10 NuGets or ones built from current master? The Roslyn codegen change is only in master at this point.

[KodrAus]

@veikkoeeva and @grahamehorner I understand this is new stuff not only for Orleans, but for many .NET projects, so I'm just playing around and reporting my finding in case they help anyone else :) I fully intend to continue tinkering and seeing what I can do to help with cross-platform compatibility.

@sergeybykov I built 1.0.10 packages from master and put them in a local Nuget feed so I could reference them in my project. I think I'll put together a simple Ubuntu HyperV container with Mono and DNX on my Windows machine, share a drive with Windows-built Orleans packages and use that for rapid cross-platform testing.

I'm really keen to work towards getting Orleans running on Ubuntu, then in a Docker container, and then as a Mesosphere framework.

Thanks for the awesome work :)

[gabikliot]

Thumbs up @kodraus! We would live that to happen!

[sergeybykov]

@KodrAus Curios if you were able to make any progress here. You could try 1.1.0-beta1 instead of 1.0.10 now.

[KodrAus]

@sergeybykov I've managed to get my test environment all set up for dev on Windows and running on Ubuntu, but that's where I'm up to. I'll try to actually run with the latest source over the next few days and will report how it goes.

Is there a nightly Nuget feed for Orleans? If not is this something you think might be useful? I see there's a build for 1.1.0-beta1 on Nuget.org though.

[sergeybykov]

Excellent.

We don't produce nightly NuGets because we have to codesign binaries. Can't you easily build them locally form the sources?

[KodrAus]

That's what I'm now doing actually. So I build the Orleans packages on Windows in a shared drive, which is also a package source on my Ubuntu vm. So it's basically a local nightly feed

[gabikliot]

@KodrAus , could you please provide a step by step guide on how you build on Linux? It would be great to include that in our docs, for example as a page here http://dotnet.github.io/orleans/, something like "Building and Running on Linux" under the Installation section. You can submit a PR against the gh pages branch: https://github.com/dotnet/orleans/tree/gh-pages

[KodrAus]

Can do. I'll write everything up and submit a PR once I get it actually working. I'll also bring my sample HelloGrain DNX/mono app in line with the other samples and submit it too. I'm back to the IProvider problem on Ubuntu using the latest Orleans bits, but I'm actually getting some Orleans logging output, so there's progression there which is awesome.

I'll dig around what's causing the CachedTypeResolver to get confused on mono (I suspect it's what's calling it) and will open a separate issue for that once I have a clearer idea. The code does work on Windows.

I have also had to include the Microsoft.Framework.DependencyInjection.Abstractions package as a dependency manually in my project because it wasn't on my Ubuntu machine by default.

Should I also open an issue about perf stats? I get a warning that Windows perf counters aren't working... Which is fair enough because it's not running on Windows.

[gabikliot]

Thanks @KodrAus !

The Microsoft.Framework.DependencyInjection.Abstractions should be solved soon, with https://github.com/dotnet/orleans/pull/1007 and https://github.com/dotnet/orleans/pull/1029.

No need to open an issue on perf counters. We are well aware of that problem, and the solution is in the works (https://github.com/dotnet/orleans/issues/368 and https://github.com/dotnet/orleans/pull/1026). As long as it does not prevent the silo from running, we are OK for now.

[galvesribeiro]

@KodrAus you will not able to get dnx to run Orleans until we finish #368 (which is real close, only 2 more items to address and we can start testing)

I did a test here on a Hyper-V Ubuntu VM:

gutemberg@GUTO-UBUNTU:~/Debug$ uname -a
Linux GUTO-UBUNTU 3.19.0-28-generic #30~14.04.1-Ubuntu SMP Tue Sep 1 09:32:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

and Mono:

gutemberg@GUTO-UBUNTU:~/SRC/LinuxNoRoslynTestSilo$ mono --version
Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1.1)
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

If you try the latest 1.1.0-beta1 you will fall in endless errors since the new codegen is based on Roslyn and it is currently not supported by Mono and as far as I recently talked with Mono guys, it will not be(at least not so soon). Mono4 introduced C# 6 language structs but not Roslyn compiler/SDK.

If you try latest stable 1.0.10 as you did, you will fall on some errors on dependencies on Microsoft's .Net framework implementation (mostly parts of the framework which rely on Win32 API which wasn't implemented on Mono).

My advice? Wait a bit for us to get #368 done so you will have a fully supported build of Orleans for CoreCLR as @gabikliot mentioned. We are really close. I wouldn't rely on Mono today for new endeavors (that is my personal opinion) after the recent news regarding coreCLR.

Regarding the performance counters, we are going to implement it as a external ITelemetryConsumer on #1026. This will completely decouple it from Orleans and that will not be a problem for coreCLR. I've already looked for something as a replacement to performance counters for Linux (even if that rely on native code and P/Invokes) and so far, the only think I've found is logd to log/traces (which I'll implement to replace the Trace/ETW consumers on Linux) but nothing like application performance counters for linux (only found hardware ones like PAPI). If you you know anything like this for linux, please share with us on #992 and I'll be happy to implement it.

[TheDevelolper]

I'm looking to use Orleans on a mono environment. This ticket is still open so I assume that I should perhaps consider using Akka.NET instead? Would you agree? Have there been any movements on this?

[KodrAus]

@KiransHub you're probably better off targetting .NET Core rather than Mono. As far as I know that's where the cross-platform effort is going. Is there a specific reason you need a Mono environment?

[TheDevelolper]

Ashley, Thanks for getting back to me. I'm targeting Mono because I guess that's where the support currently is. I didn't know that .NET Core was actually available for consumption right now. Thank you for the link. I will target that instead! Great suggestion!

Kind Regards, Kiran Randhawa - Prime By Design Consulting Ltd

[image: View Kiran Randhawa's profile on LinkedIn] http://uk.linkedin.com/pub/kiran-randhawa/25/91a/2b "Let's exchange ideas"

On 13 November 2016 at 12:05, Ashley Mannix notifications@github.com wrote:

@KiransHub https://github.com/KiransHub you're probably better off targetting .NET Core rather than Mono. As far as I know that's where the cross-platform effort is going. Is there a specific reason you need a Mono environment?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/orleans/issues/912#issuecomment-260182131, or mute the thread https://github.com/notifications/unsubscribe-auth/AD1wueNK3dPLHHhZxOWiryN39jgmV_shks5q9v0PgaJpZM4GPVk- .

[sergeybykov]

I'll close this because we are not targeting Mono. No do we test on it. .NET Core is the cross-platform target.

But if there are specific issues that are blocking running Orleans on Mono, we would consider those if they are straightforward to fix.