Add support for setting an additional assembly scanning path #5653
Conversation
|
I don't think this new setting should override the existing scan locations, but should be an additional scan location that can be configured. |
SeanFeldman
force-pushed
the
custom-assembly-scanning-paths
branch
from
ef62338
to
c9f51b5
Compare
Could you please provide an example when an additional location would be used in conjunction with the predefined locations, @bording? |
|
The thought process was that if we are exposing this API publicly, then we should make it generally safe to use. If we replace the default location when this is called, then assembly scanning breaks if all of the assemblies that need to be scanned aren't in that location (minus whatever happens to already be loaded if appdomain scanning is enabled) If this is an additional location that can be scanned, then someone could locate assemblies in some other path and have those picked up in addition to the assemblies in the default locations. |
I think this could be done by the user by just loading whatever they want from wherever into the AppDomain (or load contexts) manually and NServiceBus should pick it up as part of scanning the loaded assemblies. That logic should be easy to implement given that in such cases there isn't a lot of "filtering" and optimizations required. At least from this perspective, this can already be achieved today if there is an urgent need for it and it would not depend on the implementation of this feature. |
|
btw. I think there is an interesting angle to this to "disable" the assembly scanning by providing a different path that wouldn't be possible when using "additional" scanning locations. Arguably that might be more of a "misuse" of a feature but I at least that would be a feature more appealing to me :D |
Co-authored-by: Sean Feldman <feldman.sean@gmail.com>
SeanFeldman
force-pushed
the
custom-assembly-scanning-paths
branch
from
c9f51b5
to
11221bd
Compare
SeanFeldman
changed the title
|
The PR was updated to support an additional path rather than replacing a path. |
Co-authored-by: Bob Langley <bob.langley@particular.net>
SeanFeldman
force-pushed
the
custom-assembly-scanning-paths
branch
from
0b8321c
to
e8874d3
Compare
src/NServiceBus.Core/Hosting/Helpers/AssemblyScanningComponent.cs
Outdated
Show resolved
Hide resolved
src/NServiceBus.Core/Hosting/Helpers/AssemblyScanningComponent.cs
Outdated
Show resolved
Hide resolved
src/NServiceBus.Core/Hosting/Helpers/AssemblyScanningComponent.cs
Outdated
Show resolved
Hide resolved
| { | ||
| if (TryLoadScannableAssembly(assemblyFile.FullName, results, out var assembly)) | ||
| foreach (var assemblyFile in ScanDirectoryForAssemblyFiles(directoryToScan, ScanNestedDirectories)) |
There was a problem hiding this comment.
This means that nested directories for the additional scanning path will also be potentially scanned. I'm wondering if this should be an option for the additional scanning path.
There was a problem hiding this comment.
I don't know but assuming the assumptions about the primary path should apply to the additional path.
Co-authored-by: Brandon Ording <bording@gmail.com>
Partially addresses https://github.com/Particular/NServiceBus.AzureFunctions/issues/44 part 1:
The Core doesn't allow assembly scanning with an alternate path