Add AssemblyLoadContext.LoadFromStream overload to populate Location and CodeBase

[albahari]

Currently, assemblies loaded via AssemblyLoadContext.LoadFromStream end up with a blank Location and a CodeBase of System.Private.CoreLib.dll.

This causes trouble when you load an assembly that includes code such as this:

GetExecutingAssembly().Location

If you don't own the library that you're loading, you can't factor out this code, so the library breaks and LoadFromStream is effectively useless.

Can we have a new overload which loads an assembly from a stream while populating these properties:

public Assembly LoadFromStream(Stream assembly, Stream assemblySymbols, string location, string codeBase)

My own scenario for using LoadFromStream is to load an assembly without locking it so that it can be updated. The alternative is to copy the assemblies to a temporary location (and re-copy it each time it's updated) which is clumsy and inefficient. The temporary location causes two other problems. First, the assembly in question may rely on non-binary resources in the same folder as itself (or subfolders) which are now gone. Second, it makes it hard to diagnose issues related to loading the right DLL from the right place, because the original load location is obfuscated.

[vitek-karas]

/cc @sdmaclea @swaroop-sridhar

[swaroop-sridhar]

The current semantics for Assembly.Location is that it is the honest actual location of the file.
The manual says:

The location of the loaded file that contains the manifest. If the loaded file was shadow-copied, the location is that of the file after being shadow-copied. If the assembly is loaded from a byte array, such as when using the Load(Byte[]) method overload, the value returned is an empty string ("").

Existing code may depend on this property (Location empty string when loaded from memory) to be true.

[swaroop-sridhar]

Maybe we can have a different API (say Assembly.Origin) which gives us anything that the loading module wants.

[albahari]

Yes, I see your point. There may be code which assumes that if Location is non-empty, it must return a valid file, and so would skip doing a File.Exists check on it. Introducing an overload that invites you put anything into Location and CodeBase might be too much risk.

Your suggestion of a new properly such as Origin would still be better than the current situation with memory-loaded assemblies, which is having no useful property at all.

Origin would presumably match Location for assemblies loaded normally via LoadFromAssemblyPath, and would be user-specified for assemblies loaded via LoadFromStream.

And in the case of assemblies loaded directly into memory from a single-file bundle, Origin could return the path of the .EXE that contained the assembly.

Another option worth considering is to store just the directory (Assembly.BaseDirectory instead of Assembly.Origin). This would avoid the confusion of having three file path properties (Location, CodeBase and Origin). Assembly.BaseDirectory would always return Path.GetDirectoryName(Location) except in the special case when Location is blank, which keeps it simple to document and understand.

[jkotas]

suggestion of a new properly such as Origin

The new property would help only if you are able to change the affected library. And if you are changing the affected library, it would be best to fix it to allow the configuration to be passed in explicitly from outside and avoid dependency on Assembly.Location or similar APIs completely.

[albahari]

But there's a big difference between making a request to a library author that they use Assembly.BaseDirectory instead of Assembly.Location, versus getting them to agree on, spec up, and implement a new API to allow configuration or other dependencies to be passed in from outside.

[jechter]

FWIW, in Unity we could also use something like this. We currently use mono in the Unity editor to load assemblies from memory, while supplying the location on disk, using mono_image_open_from_data_with_name. We need to load assemblies via memory, as they can be modified on disk while being used. We are experimenting with using CoreCLR, and running into the same issue - that existing third-party code querying Assembly.Location will not get a valid path name for assemblies loaded from memory using LoadFromStream, and that there is no API to supply such a path.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.