-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RabbitMQ.Client v7 breaks Aspire.RabbitMQ.Client component #3956
Comments
Version 7 has binary breaking changes that cause the Aspire.RabbitMQ.Client component to fail loading with a MissingMethodException. Contributes to dotnet#3956
Version 7 has binary breaking changes that cause the Aspire.RabbitMQ.Client component to fail loading with a MissingMethodException. Contributes to dotnet#3956
Version 7 has binary breaking changes that cause the Aspire.RabbitMQ.Client component to fail loading with a MissingMethodException. Contributes to dotnet#3956
Version 7 has binary breaking changes that cause the Aspire.RabbitMQ.Client component to fail loading with a MissingMethodException. Contributes to #3956
Version 7 has binary breaking changes that cause the Aspire.RabbitMQ.Client component to fail loading with a MissingMethodException. Contributes to #3956
RabbitMQ.Client v7 is now release! |
And doesn't recognize CreateConnection() anymore :) I hope this will be fixed. I did rollback my upgrade. |
Until aspire team made all the changes described above we can't use them without creating a custom integration. We have already did since the date of this issue and works good so if you needed it you can create a AddRabbitMQV7() method to add resource and use the new shipped api of the v7 (which have some breaking changes) to do connection and health checks. |
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.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 the7.0.0
version, which will break their app.7.0.0
stable package during the .NET Aspire8.x
lifetime, we can add a new, forked component namedAspire.RabbitMQ.Client.v7
which will have a dependency on7.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.Aspire.RabbitMQ.Client
package will be updated to depend on version 7 of RabbitMQ.Client.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
The text was updated successfully, but these errors were encountered: