Exclude dynamic assemblies from Configuration

[timbussmann]

Under certain circumstances it's possible for NServiceBus to include dynamic assemblies containing messages in the assembly scanning process (e.g. using AllAssemblies API and hosting multiple endpoints in the same AppDomain). This results in settings.GetAvailableTypes() returning types from these dynamic assemblies. NHibernateSagaStorage adds all assemblies from message types to the Configuration:

        var scannedAssemblies = settings.GetAvailableTypes().Select(t => t.Assembly).Distinct();
        foreach (var assembly in scannedAssemblies)
        {
            configuration.AddAssembly(assembly);
        }

NHibernate seems to throw an exception when adding a dynamic assembly to the Configuration.

Seems like the simplest solution would be to exclude dynamic assemblies on these usages.
Not sure whether this is also something to be handled in the core? (/cc @Particular/nservicebus-maintainers )

Related google groups topic: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/particularsoftware/PAVC4NHZzjY/mz-Ur9UhBQAJ

[danielmarbach]

On the fence about the core. Can we envision scenarios where users actually would like to include dynamic assemblies from a core perspective? What would they be able to do with these types? In theory you could write dynamic code into an assembly containing message handlers or other things like startables and such. I'd say the safest solution right now would be to exclude it in NHibernate.

[danielmarbach]

Can you also document the workaround here in the description?

[andreasohlund]

Seems safest to not exclude them by default in the core but have a config.ExcludeDynamicAssembliesFromScanning() or similar?

Did v5 include dynamic asms? (pretty sure it does)

[timbussmann]

Did v5 include dynamic asms? (pretty sure it does)

this bug is v5 related, did not verify v6 behavior yet.

Can you also document the workaround here in the description?

will do, currently awaiting feedback from the groups topic.

[SzymonPobiega]

@timbussmann how to repro this? Is it enough to generate an empty assembly dynamically?

[timbussmann]

@SzymonPobiega I think it would need to have at least a type in the assembly. I think creating the dynamic assembly with a type should be enough to repro on v5. An alternative approach might be to start an endpoint using interface messages (creates dynamic assemblies as well) twice in the same appdomain.

I think this might not be an issue in v6 as it doesn't scan appdomain assemblies by default, but you can explicitly enable it to do so. That behavior might also change for v7 where we might enable appdomain assembly scanning by default.

[SzymonPobiega]

@timbussmann fine with me closing it unless we get evidence it gets broken in V7 or subsequent release? If this is an issue in V5 and (correct me if I am wrong) throws at startup then we don't need to patch it.

[timbussmann]

@SzymonPobiega your call on closing/fixing this. But I think it might be worth to at least investigate latest major in combination with core v6's "ScanAppDomainAssemblies" option. If that doesn't work I can pretty much guarantee problems with v7.