Loading multiple assemblies for static type loading

[mrajkovicpta]

Issue/Wanted Behavior

We are using Wolverine as our RabbitMQ bus but when using WolverineOptions.CodeGeneration.TypeLoadMode = TypeLoadMode.Dynamic we are sometimes getting timeout issues due to cold starts. We tried shifting to TypeLoadMode.Static but due to the mode seemingly only looking for types in the application assembly it is unable to find the message type which is located in a separate assembly due to our project structure.
The WolverineOptions.CodeGeneration.ReferenceAssembly method sounds like it would do this but in the documentation here it says that it will only look in the main assembly.

Proposed Solution

My proposed solution is to simply have the static generation also use assemblies referenced in ReferenceAssembly. This could also lead to confusion in the future as the WolverineOptions.Discovery also has a method for adding assemblies to search through but that one is for Handler discovery, however this is only a minor issue.

Alternatives

For our particular use case we have currently decided to increase the message timeout and it works.

Additional Info

The message type is simply in a separate assembly (c# project) in order for both the sender and the receiver to have access to the message type

Stack trace when TypeModeLoad.Static is enabled, this happens regardless of how I configure referenced/discovery/executing assemblies

JasperFx.CodeGeneration.ExpectedTypeMissingException: Could not load expected pre-built types for code file [MyMessageHandler]1852938429 ([MyMessage] handled by [MyMessageHandler].HandleAsync()) from assembly [MyAssemblyHere], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. You may want to verify that this is the correct assembly for pre-generated types.
   at JasperFx.RuntimeCompiler.CodeFileExtensions.InitializeSynchronously(ICodeFile file, GenerationRules rules, ICodeFileCollection parent, IServiceProvider services) in /_/src/JasperFx.RuntimeCompiler/CodeFileExtensions.cs:line 123
   at Wolverine.Runtime.Handlers.HandlerGraph.resolveHandlerFromChain(Type messageType, HandlerChain chain, Boolean shouldCacheGlobally) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/Handlers/HandlerGraph.cs:line 253
   at Wolverine.Runtime.Handlers.HandlerGraph.HandlerFor(Type messageType) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/Handlers/HandlerGraph.cs:line 215
   at Wolverine.Runtime.Handlers.HandlerGraph.HandlerFor(Type messageType, Endpoint endpoint) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/Handlers/HandlerGraph.cs:line 176
   at Wolverine.Runtime.WolverineRuntime.Wolverine.Runtime.IExecutorFactory.BuildFor(Type messageType, Endpoint endpoint) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/Wolverine.ExecutorFactory.cs:line 27
   at Wolverine.Runtime.HandlerPipeline.<>c__DisplayClass7_0.<.ctor>b__0(Type type) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/HandlerPipeline.cs:line 48
   at JasperFx.Core.LightweightCache`2.get_Item(TKey key) in /_/src/JasperFx/Core/LightweightCache.cs:line 58
   at Wolverine.Runtime.HandlerPipeline.executeAsync(MessageContext context, Envelope envelope, Activity activity) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/HandlerPipeline.cs:line 190
   at Wolverine.Runtime.HandlerPipeline.InvokeAsync(Envelope envelope, IChannelCallback channel, Activity activity) in /home/runner/work/wolverine/wolverine/src/Wolverine/Runtime/HandlerPipeline.cs:line 82

[jeremydmiller]

@mrajkovicpta I'm dubious that this is necessary. As long as you have the handler discovery set up the way you need it to to find all of your handlers -- and you can spot verify this through dotnet run describe -- a call to dotnet run codegen write should write the generated code for every single handler in your system to the main application assembly's folder.

I'm converting this to a discussion for now. There has to be something off one way or another about your configuration. Feel free to ask more questions here or in Discord.

[mrajkovicpta]

@jeremydmiller
Sorry for taking a long time to respond, I've put this issue on the backburner and I finally got to deal with it.
After isolating the project structure to a new solution and reading a bit more on the wiki, I noticed that dotnet run -- codegen write wasn't running properly for me and saw the note that it was in a separate library from wolverine. After including it manually, it started writing the generated files as well as fixing the issue.
I added both JasperFx.CodeGeneration.Commands and JasperFx.CodeGeneration manually as well as messing with some of our Directory.Packages.props and Directory.Build.props configurations and it is running fine now.
There does seem to be a collision between the two packages as JasperFx.CodeGeneration 3.7.2 seems to require Microsoft.Extensions.Hosting 9 while the new WolverineFx 5.2.0 wants it at 10.
Really unsure why it wasnt referenced, but it could have been entirely due to our Directory props setups.

Have a good day