Issue with .NETCore Console app using EventFlow

[trikk86]

We have a pretty big app done using Eventflow. We have 2 ASPNET Core Solutions that work pretty well. We started using EventUpgraders and all works fine.

Now we want to add Eventflow to a Windows Service like app.

The DI registration is as follows:

services.AddEventFlow(options => options .Configure(c => c.ThrowSubscriberExceptions = true) .ConfigureMsSql(MsSqlConfiguration.New.SetConnectionString(configuration.GetConnectionString("TargetDatabase"))) .UseMssqlEventStore() .AddDefaults(assembly));

The issue that we seem to be getting is that the EventDefinitionSource does not update. For the API parts, I can see 32 Events in there, but for this app I get nothing.

When I try to invoke an event on an existing aggregate I get this error:

No versioned type definition for 'MyEventName' with version 4 in 'EventDefinitionService' - System.ArgumentException: No versioned type definition for 'MyEventName' with version 4 in 'EventDefinitionService'

I tried adding the EventVersion attribute but that doesn't seem to work and it doesn't seem to be backwards compatible :(

I tried downgrading the package. to 0.75

[rutgervanwilligen]

+1, we encountered the same problem. Apparently, the .Load() method in the IEventDefinitionService is never called in the default EventFlow setup. It is, however, called when using the AddAspNetCore() extension method (which is why our and your ASP.NET solutions work fine).

If I have some time available in the upcoming days, I might be able to take a look at what the difference is. For now, we've circumvented the problem by adding the following code (based on code found in the EF source) to the Main method of our console applications:

var serviceProvider = SetupDependencyInjection();

var eventsAssembly = typeof(SomeEventClass).Assembly;
var aggregateEventTypes = new HashSet<Type>(eventsAssembly
    .GetTypes()
    .Where(t => IsAssignableToGenericType(t, typeof(IAggregateEvent<,>))));

var eventDefinitionService = serviceProvider.GetService<IEventDefinitionService>();
eventDefinitionService.Load(aggregateEventTypes);

and

private static IServiceProvider SetupDependencyInjection()
{
    var serviceCollection = new ServiceCollection();

    services.AddEventFlow(o => o
        ....
        ....
    );

    return services.BuildServiceProvider();
}

and

private static bool IsAssignableToGenericType(Type givenType, Type genericType)
{
    var interfaceTypes = givenType.GetInterfaces();

    if (interfaceTypes.Any(it => it.IsGenericType && it.GetGenericTypeDefinition() == genericType))
    {
        return true;
    }

    if (givenType.IsGenericType && givenType.GetGenericTypeDefinition() == genericType)
    {
        return true;
    }

    var baseType = givenType.BaseType;
    return baseType != null && IsAssignableToGenericType(baseType, genericType);
}

Not the prettiest solution, but this does make sure the IEventDefinitionService is properly loaded before it's used.

[rasmus]

@trikk86 did you get it to work?

[rasmus]

I know that the load isn’t optimal. I have been try out a few alternative solutions and I might have one that could work.

[trikk86]

Hi,
we used a similar method as @rutgervanwilligen and it works. For some reason the eventdefinitions are not loaded automatically in a .net core non-ASP app apparently.

[rutgervanwilligen]

@rasmus Just to understand more clearly: is the fact that .Load() isn't called automatically in this setup a bug, or is it expected behaviour? It feels as if that should happen by default, but maybe I'm not understanding things correctly.

[rutgervanwilligen]

Hi @rasmus, did you see my question above? I'd be happy to help!

[frankebersoll]

The problem seems to be that the bootstrapper isn't called. In ASP.NET Core, this happens on startup, using an implementation of IHostedService:

https://github.com/eventflow/EventFlow/blob/develop/Source/EventFlow.AspNetCore/ServiceProvider/HostedBootstrapper.cs

You could try retrieving the IBootstrapper instance from the service provider and call StartAsync yourself. This is obviously something that needs to be integrated in the framework.