Closed trreeves closed 7 years ago
Work that I think still needs doing to get this finished:
[x] 1. Get all ContainerTests passing
[x] 2. Remove NetCoreServiceProviderContainer
adapter
[x] 3. Clean up IBus property and field in HandlerServiceProvider - I've just realised it's not used at the moment in this implementation, but I guess the bus needs to be disposed when application is stopping?
[x] 4. Remove Main_Old
function from sample - I've left that in there at the moment as a comparison for the PR review.
Hi @trevorreeves , are the tests passing when you run them locally?
Just getting round to looking at them now. Fixed my new ones. The container tests are failing, so just digging into them to understand the situation...
@mookid8000 So, The ContainerTests mechanism just isn't compatible with the way ServiceCollection and ServiceProvider work (the registrations inside ServiceProvider are immutable, so the IBus must be defined with a factory function registration). It's not possible to get those tests to pass, without some refactoring of the ContainerTests.
Hi @trevorreeves , sorry for taking so long to process this.... I have spent some time this morning trying to make the service provider test factory thing simply pick up the types to register lazily, adding them to the service collection when it is time to build a service provider.
I can't seem to find a way to be able to add the bus to the container though. Or the IMessageContext
or the ISyncBus
.
which leads me to this....:
Am I completely off when I am beginning to see the ServiceProvider thing as a simple IoC container meant to be used in ASP.NET Core?
Is it a general .NET Core thing, or is it mostly meant to be used in a web application?
Thanks @mookid8000
Am I completely off when I am beginning to see the ServiceProvider thing as a simple IoC container meant to be used in ASP.NET Core?
No, you're good, don't worry.
Is it a general .NET Core thing, or is it mostly meant to be used in a web application?
It's a general purpose IoC container, and can be used anywhere. The main difference I can see that is significant in the case of configuring Rebus, is that the service registrations are immutable once the provider has been created; you can't register services once your app has started. So, an IBus must be registered with a factory function, that starts the bus the first time it is requested.
I have spent some time this morning trying to make the service provider test factory thing simply pick up the types to register lazily, adding them to the service collection when it is time to build a service provider.
Not entirely sure what you mean. I have just got around to spending some more time on this, and was going to submit PRs on the other repo's - some kind of change to IContainerAdapterFactory and the tests are needed. Hopefully have something for review early next week.
Just pushed changes for the activation tests that use the 'IActivationContext' PR I've just submitted on the Rebus repo which will allow ContainerTests and RealContainerTests to work.
Will need to wait for a new Rebus.Tests.Contracts package before it can compile of course.
I just thought, the (major) version number should increase for this package
I just thought, the (major) version number should increase for this package
To 5? All the 4-versions are in prerelease versions right now, so I don't think the version should be bumped.
OK sure, I didn't realize that. thanks.
Rebus is MIT-licensed. The code submitted in this pull request needs to carry the MIT license too. By leaving this text in, I hereby acknowledge that the code submitted in the pull request has the MIT license and can be merged with the Rebus codebase.