Review of `FEATURE_ASSEMBLIES` and `ReflectionUtil`

tl;dr; I think there are some issues with how ReflectionUtil is currently behaving, having investigated #619. I’m digging into/learning the differences between Assembly handling for Framework/Standard/Core with respect to this functionality to understand it better. If anyone has experience with this area of the code please shout!

long version After digging into #619, I’ve been trying to get my head around the ReflectionUtil class, where the FEATURE_ASSEMBLIES switch does things. I think there might be a few [potential] bugs here, both with some of the logic (e.g. IsAssemblyFile, IsApplicationAssembly), incorrect usage of Assembly.Load/Assembly.LoadFile and around the handling of Framework/Standard/Core.

System.Runtime.Loader is pulled in for the netstandard2.0 targeting, but it sounds like really it should only be used for projects targeting Core - the package being pulled in dates from around the release of .net Core 1.1, but https://github.com/dotnet/runtime/issues/20849 (from a year later) suggests it doesn’t work with .net Framework (https://docs.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext has only .net Core as supported). I can’t see how to reconcile targeting netstandard2.0 and crossing this boundary without the risk of runtime errors (unless the nuget package shims the behaviour for Framework?). I’m going to do some more digging into the source to understand, but I’m assuming this isn’t usually an issue as Framework consumers will just consume the net462 package.

For Assembly.Load/Assembly.LoadFile, the code currently uses IsAssemblyFile but Load should only be used for referenced assemblies, LoadFile should be used for others being pulled in, and IsAssemblyFile doesn’t validate this - there’s no checking for referenced assemblies. Annoyingly I can’t now find the page I was reading about this, but in a similar area I’m going to dig into AssemblyLoadContext as I suspect Windsor could be leveraging this more for Core.

The notes on Assembly.Load have this remark:

Do not use an AssemblyName with only the CodeBase property set. The CodeBase property does not supply any elements of the assembly identity (such as name or version), so loading does not occur according to load-by-identity rules, as you would expect from the Load method. Instead, the assembly is loaded using load-from rules. For information about the disadvantages of using the load-from context, see the Assembly.LoadFrom method overload or Best Practices for Assembly Loading

GetAssemblyName(string filePath) does this at the moment, which might be intentional, but might not be.

If anyone’s got any good links/background knowledge, please let me know!

[Jevonius]

Hi all, apologies for the absence, have been busy elsewhere; didn’t realise quite how long it had been! Just getting my head back into this. I’m still working through the assembly handling to understand it fully (and how System.Runtime.Loader package fits in). I agree that dropping netstandard2.0 wouldn’t be great for those dealing with mixed environments, although at some point the time will come; be nice to keep it around for a while longer though.

[jonorossi]

I don’t really understand the problems here, but your comment from #621:

Currently concerned we might need to consider dropping targeting netstandard2.x to avoid the risk of a run-time error.

Personally I don’t see the need for .NET Standard 2.x anymore. .NET Core 3.1 is only supported for a very short time. I’d be fine with .NET 6 and .NET Framework 4.x.x.