MissingMethodException: Method not found: 'Void RabbitMQ.Client.ConnectionFactory.set_UseBackgroundThreadsForIO(Boolean)'.
Microsoft.Extensions.Configuration.Binder.SourceGeneration.<BindingExtensions_g>F4A9562478640BAD0160976753D96FF712B41D5A2B91D22C8BB8580DF176A8A3D__BindingExtensions.BindCore(IConfiguration configuration, ref ConnectionFactory instance, bool defaultValueIfNotFound, BinderOptions binderOptions)
Microsoft.Extensions.Configuration.Binder.SourceGeneration.<BindingExtensions_g>F4A9562478640BAD0160976753D96FF712B41D5A2B91D22C8BB8580DF176A8A3D__BindingExtensions.Bind_ConnectionFactory(IConfiguration configuration, object instance) in BindingExtensions.g.cs
Microsoft.Extensions.Hosting.AspireRabbitMQExtensions+<>c__DisplayClass5_0.<AddRabbitMQClient>g__CreateConnectionFactory|0(IServiceProvider sp) in AspireRabbitMQExtensions.cs
But I assume there will be many others after this.
We will need to handle this breaking change by splitting our component into 2, one for each major version.
For the current Aspire.RabbitMQ.Client package, we should put a NuGet version limit on our dependency: [6.8.1,7.0.0). This way people won't be able to update to the 7.0.0 version, which will break their app.
If RabbitMQ.Client ships an official 7.0.0 stable package during the .NET Aspire 8.x lifetime, we can add a new, forked component named Aspire.RabbitMQ.Client.v7 which will have a dependency on 7.0.0 and contain any updates so the .NET Aspire component will work with v7. People who explicitly want to use version 7 can opt into using this package.
When .NET Aspire 9 ships, we can "swap" the dependencies around.
The Aspire.RabbitMQ.Client package will be updated to depend on version 7 of RabbitMQ.Client.
If RabbitMQ.Client v6 is still in support, we can create Aspire.RabbitMQ.Client.v6 which has the dependency limit [6.8.1, 7.0.0) and works with the version 6 of RabbitMQ.Client.
Aspire.RabbitMQ.Client.v7 will be dead-ended. We won't make new .NET Aspire 9 versions of this package.
Note that we shouldn't need to do this for every component when the underlying client library ships a new major version. We will only need to follow this model when major breaking changes come into the underlying client library such that our library doesn't even work anymore (or other major breaks that convince us it is worth doing this).
cc @sebastienros @radical @joperezr @DamianEdwards
There have been some major binary breaking changes in https://www.nuget.org/packages/RabbitMQ.Client/7.0.0-alpha.5. Our component doesn't even load when using this version. The first error I get is:
But I assume there will be many others after this.
We will need to handle this breaking change by splitting our component into 2, one for each major version.
Aspire.RabbitMQ.Clientpackage, we should put a NuGet version limit on our dependency:[6.8.1,7.0.0). This way people won't be able to update to the7.0.0version, which will break their app.7.0.0stable package during the .NET Aspire8.xlifetime, we can add a new, forked component namedAspire.RabbitMQ.Client.v7which will have a dependency on7.0.0and contain any updates so the .NET Aspire component will work with v7. People who explicitly want to use version 7 can opt into using this package.Aspire.RabbitMQ.Clientpackage will be updated to depend on version 7 of RabbitMQ.Client.Aspire.RabbitMQ.Client.v6which has the dependency limit[6.8.1, 7.0.0)and works with the version 6 of RabbitMQ.Client.Aspire.RabbitMQ.Client.v7will be dead-ended. We won't make new .NET Aspire 9 versions of this package.Note that we shouldn't need to do this for every component when the underlying client library ships a new major version. We will only need to follow this model when major breaking changes come into the underlying client library such that our library doesn't even work anymore (or other major breaks that convince us it is worth doing this).
cc @sebastienros @radical @joperezr @DamianEdwards