Reduced public API#13
Conversation
…figure the routing.
|
Ping @timbussmann @SzymonPobiega |
| <Reference Include="System.Xml" /> | ||
| </ItemGroup> | ||
| <ItemGroup> | ||
| <Compile Include="Properties\AssemblyInfo.cs" /> |
There was a problem hiding this comment.
I need it for InternalsVisibleTo for tests project.
| </ItemGroup> | ||
| <ItemGroup /> | ||
| <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> | ||
| <!-- To modify your build process, add your task inside one of the targets below and uncomment it. |
| @@ -0,0 +1,37 @@ | |||
| using System.Reflection; | |||
|
@SzymonPobiega you need to be more explicit than 🔥 :P I use |
|
@Scooletz I meant, most of the assembly info stuff is rendundant - generated by GitVersion. So leave only |
| /// Enables routing configured with the routing configuration file. | ||
| /// </summary> | ||
| /// <param name="config">The configuration object.</param> | ||
| public static void EnableFileBasedRouting(this EndpointConfiguration config) |
There was a problem hiding this comment.
we could also consider disabling autosubscribe in case it's a transport without native pubsub features
There was a problem hiding this comment.
Should we throw an exception if somebody wants to use centralized routing for events with a transport that supports native event routing?
|
|
||
| namespace NServiceBus.FileBasedRouting | ||
| { | ||
| public static class FileBasedRoutingConfig |
There was a problem hiding this comment.
it's common to postfix the class containing extensions methods with Extensions
| } | ||
|
|
||
| await Endpoint.Create(endpointConfiguration); // to init all features | ||
| var routingTable = endpointConfiguration.GetSettings().Get<UnicastRoutingTable>(); |
There was a problem hiding this comment.
if we name this integration test and rely on internal behavior which can easily change, I think we should instead consider using the acceptance testing framework and start up matching endpoints and do the tests that way. But this isn't a blocker for this PR, I think we should do that in a dedicated test anyway. Thoughts?
There was a problem hiding this comment.
Quite a lot of ceremony in order to validate if we can pass a configuration parameter properly. I've seen this problem a number of times where we need to spin up an endpoint to validate if we are passing values through settings correctly. I'd 🔥 this test provided it was at least once observed to be green -- not likely to break in future.
There was a problem hiding this comment.
let's keep them in here as long as they don't cause any pain since they have been written now anyway. But good to 🔥 them immediately on some sign of issues
…transport uses native routing.
| var route = UnicastRoute.CreateFromEndpointName(endpoint.LogicalEndpointName); | ||
| foreach (var commandType in endpoint.Commands) | ||
| { | ||
| if (nativeSends) |
There was a problem hiding this comment.
that could probably be addressed in a more elegant way by #16
3 participants
All types made internal with only two public extension methods to configure the routing.
PoA:
Addresses #11