FileLoadException.FileName can be null

[SimonCropp]

So here https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Hosting/Helpers/AssemblyScanner.cs#L302

We have

            foreach (var ex in e.LoaderExceptions)
            {
                var loadException = ex as FileLoadException;

                if (loadException != null)
                {
                    var assemblyName = new AssemblyName(loadException.FileName);

But as per the doco https://msdn.microsoft.com/en-us/library/system.io.fileloadexception.filename%28v=vs.100%29.aspx FileLoadException.FileName can be null

This property returns the name of the file supplied to the constructor for the current instance, if any. If the file name was not specified or is a null reference, this property returns a null reference.

Hence the reason this user is not getting a useful error message https://groups.google.com/forum/#!topic/particularsoftware/Jbiar-UP19s

[johnsimons]

@SimonCropp what version do you propose we fix this in ?

[SimonCropp]

6

[bhandfast]

Is it possible to get this merged into the 4.x and 5.x versions too?

[timbussmann]

@bhandfast as far as I could tell from the original issue, this bug mainly hides the original issue during assembly scanning. Are you running into a scenario where you can't resolve the original source of the exception (e.g. by excluding the assembly from loading)?

[bhandfast]

@timbussmann I've already spent too much time hunting bugs related to this. We have 250+ endpoint projects and our commit policy doesn't allow for committing binary files if not needed. Today I need to manually build NSB and copy the dll to each endpoint to track down bugs.

If we had a Nuget package it would be a simple operation to update all dependencies. If it's possible to get this distributed in Nuget I'd really appreciate it :)

[bhandfast]

Do you have any plan on releasing new Nuget packages?

[timbussmann]

since the support for version 4 has expired, I don't think there will be a backport to version 4.

@bhandfast Can you help me to reproduce the issue? Do you have any available assembly which causes said exception?

[bhandfast]

I guess since you opened this issue yourself you had a scenario already. If you don't want to create new packages then I'll continue with manual patching.

We had an issue with ReportViewer that probably generates new assemblies somehow in a IIS application which is scanned. It quite hard to reproduce. The fix in this issue fixes the problem.

Please consider updating at least version 5 of NServiceBus.

[bhandfast]

I see now that you opened a issue for v5. Thanks :)

[timbussmann]

@bhandfast as you already noticed, there's a PR #4121 targeting v5 which should solve your issue.

[timbussmann]

This is fixed in release 5.2.16.

@bhandfast the package should be available on nuget very soon.