orleans: Cannot find an implementation class for grain interface: "custom grain". Make sure the grain assembly was correctly deployed and loaded in the silo.

Hello every one. I get this exception on orleans 3.0.2 I’m sure it is not by localization (i have win 10 rus), because i’v tried run this app on centOS 7, dotnet 3.1 and got the same exception Then the silo is started - i can see that both my grains is loaded correctly (9 grains total) I saw similar topics about this ex, but dont find answer… Can anyone help me. Silo is local, code below.

private static async Task<ISiloHost> StartSiloAsync() 
        {
            ISiloHost silo = new SiloHostBuilder()
                .UseLocalhostClustering()
                .Configure<EndpointOptions>(options => options.AdvertisedIPAddress = IPAddress.Loopback)
                .ConfigureApplicationParts(parts => parts.AddFromApplicationBaseDirectory())
                 .ConfigureLogging(logging =>
                    logging.AddConsole().SetMinimumLevel(LogLevel.Information)
                    )
                .UseEnvironment("Dev")
                .AddSimpleMessageStreamProvider("MessageProvider")
                .AddMemoryGrainStorage("MemStorage")
                //.AddMemoryGrainStorageAsDefault()
                 .Build();
            await silo.StartAsync();
            return silo;
        }

sorry for code markup, it just ignored, don’t understand how its works

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 25 (9 by maintainers)

Most upvoted comments

Hi @nofate83, check these things:

  • Your grain class inherits from the Grain base class
  • Your grain interface and grain class projects have the Microsoft.Orleans.CodeGenerator.MSBuild NuGet packages installed
  • Your silo project references your grain interface and grain class projects

In your example, you have a call to ConfigureApplicationParts - I’d remove that if I were you. That alone may solve your problem

  • Microsoft.Orleans.CodeGenerator.MSBuild

This always gets me

Came here with the same problem. During the investigation to complete the issue, I discovered that indeed I was being silly. One of my grains was trying to communicate with another method, and I was using .GetGrain<Implementation> instead of .GetGrain<Interface>. The confusing part for me was that this error was showing up in the frontend logs, not in the silo logs. Don’t write code tired.

Small remark @ReubenBond : removing ConfigureApplicationParts breaks everything. My custom grains no longer show in the SiloStart up. Bringing it back makes things work, so I’m sticking with it.

Oh, and it’s the way the documentation states we should configure clients and servers.

Cheers and thanks for the good work.

Well, I have bad news and good news.

The bad news is that I can not consistently reproduce this…and it keeps happening. Maybe twice a day, my web api randomly begins throwing this exception and I have no idea what triggers it.

The good news is that this seems to be a Rider issue for me and I can fix it every time by using “Restart and Invalidate Caches” in Jetbrains Rider. So if you are getting this error in Rider, try doing that to fix!

Are you using the OrleansDashboard project in your application, @kdenney? If so, it appears to inadvertently add application parts which stops Orleans’ default behavior and that may be messing with your (rightly) expected results. I’ll submit a fix to the dashboard project. The troublesome expression is .WithReferences() here: https://github.com/OrleansContrib/OrleansDashboard/blob/5d53f2e49caf45ccabc63f693914ea982dd2bc91/OrleansDashboard/ServiceCollectionExtensions.cs#L86

If not, do you have reminders in your application? Reminders which were targeted at a grain type which has since been deleted can cause this. Eg, if you have a reminder for a grain of type PlayerGrain but then you delete that class, this will occur when the reminder eventually fires.

Alternatively, are you using a heterogeneous cluster with a Web frontend and is this happening during startup of one of the machines? This could be a race during startup where a client tries to message a grain before the process knows of any compatible silo in the cluster. If that’s the case, it’s a bug which we need to fix.