AssemblyScanner duplicated assembly loading with possible System.IO.FileLoadException: Assembly with same name is already loaded about nservicebus HOT 7 CLOSED

Unfortunately, as we said above, the risk of changing the AssemblyScanner and the potential introduction of edge cases to our customers is too high for us to proceed. That is true for both the original suggestion and the public token change. The public key exclusions are intended to be Microsoft's runtime assemblies only.

As stated previously, we do have exclusion APIs that cover the scenario in question. If there is no other way to avoid this scenario, you could consider building an extension that allows your customers to use the exclusion APIs without code changes. For example, you could write something that reads a file containing a list of assemblies and then calls the assembly scanner exclusion API for each one of them.

from nservicebus.

@alexeypukhov thank you for your suggestion. Given the broad use of the AssemblyScanner, we can't guarantee such a change wouldn't introduce errors or added corner cases for other customers. The exclude functionality is an extensibility point that was added to cover situations like yours and is the recommended path forward. To solve your problem you'll need to have your customers use the exclusion APIs to exclude whatever assemblies are causing the issues.

from nservicebus.

@kentdr Thank you for your reply. I understand that I am suggesting a kind of fundamental change in the AssemblyScanner which require thorough analysis and I totally respect your concerns however why would one want to load an assembly for a name that was already loaded especially if it may come with an application crash or potential duplicated loading? In my case the AsemblyScanner loads my net framework assembly into a customer application running in net core environment and then fail to load the net core assembly. In this case I would prefer the AssemblyScanner to skip the net framework assembly and try to load only net core assembly. I wouldn't have a problem then. Would you be willing to improve the AssemblyScanner in this direction?

Also, even if we forget about my APM dependency, if a customer loads an assembly from bytes and then AssemblyScanner will pick this assembly up and load it again, the assembly will end up being loaded twice and who knows what will happen on duplicated initialization and how much it may cost the customer to realize this.

That being said can we make this behavior opt-in versus current opt-out? Meaning by default AssemblyScanner skips the assemblies for the names that were already loaded unless a configuration is set to proceed with it. Similar to what you currently have with AssemblyScanner.ScanAssembliesInNestedDirectories for nested directories, it is turned off by default

from nservicebus.

in my case the AsemblyScanner loads my net framework assembly into a customer application running in net core environment and then fail to load the net core assembly.

This really sounds like a deployment concern. If you're running a .NET Core application, then the .NET Framework version of the assembly shouldn't be in the bin folder in the first place.

Also, even if we forget about my APM dependency, if a customer loads an assembly from bytes and then AssemblyScanner will pick this assembly up and load it again, the assembly will end up being loaded twice and who knows what will happen on duplicated initialization and how much it may cost the customer to realize this.

This again sounds like a deployment concern. Loading an assembly from bytes is already a rather advanced/unusual thing to be doing, but if that is the case, it should be easy enough to either move the assembly out of the assembly scanner path, or add an exclusion for it.

That being said can we make this behavior opt-in versus current opt-out?

We have had that sort of API in the past, and we ended up removing it because it led to too many problems.

from nservicebus.

@bording thank you for chiming in.
I respect your risk strategy, you are right, we are talking about edgy-edge cases here and as I said I'm totally aware of the workarounds. I am just trying to see if we can avoid back-and-forth for this tricky situation. Because if our customers suffer from this issue they are also your customers who are suffering from this issue. Unfortunately I cannot predict all possible deployments that the customers may choose and we are not always coming as a nuget dependency (where the nuget would decide the right dll to extract) but I can see situations where they may easily hit this problem unintentionally. We will definitely put a note to our documentation but if they come to you with this problem, how fast will it take your team to figure out what to do with an assembly that failed to load because the assembly with the same name is already loaded. Same with us.

My problem with the excludes is that it requires changes to the application code and for some of the large corporate customers it is usually costly to redeploy production environments. Is there a way to configure excludes through environment variables or config files?

from nservicebus.

@bording, the problem with current exclude functionality that it requires code change. In many companies APM monitor is installed and configured by some IT ream responsible for application monitoring after development team provided an application artifacts to them. Such teams usually can change application config or environment variables, but can not change application code.
In our case, APM monitor installation requires extracting APM files and setting environment variables to make it be loaded by runtime. In some cases, customers may select the application folder as a place to extract our files, which will be resulted in attempt of NServiceBus to load it - with no way to suppress that behavior through any config.

from nservicebus.

@bording @kentdr I understand your hesitation about changing the design of AssemblyScanner global behavior so I have an alternative suggestion.
I see you already filter out Microsoft assemblies by their public key tokens here:

// Cisco AppDynamics .Net Agent token
"3F604D9E4F8E4985" => true,

from nservicebus.