Assembly.CodeBase returns nonexistent path for assemblies from single-file

[vitek-karas]

• Assembly.CodeBase
• Assembly.EscapedCodeBase
• AssemblyName.CodeBase
• AssemblyName.EscapedCodeBase

all these APIs when called on an assembly loaded from single file return nonexistent path - basically as if the assembly file lives next to the executable.

The question is what is the correct behavior:

• empty string - similar to Assembly.Location
• The executable path - this would be logically similar to the behavior of in-memory loaded assemblies which return location of CoreLib as their CodeBase/EscapedCodeBase even though Assembly.Location returns empty string

[ghost]

Tagging subscribers to this area: @swaroop-sridhar, @agocke
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

/cc @MichalStrehovsky @jkotas

I don't know what the intent is for CodeBase/EscapedCodeBase APIs, so it's hard to tell what the correct behavior should be.
I know we're making them obsolete in .NET 5, but that still doesn't mean they should not work.

[jkotas]

I don't know what the intent is for CodeBase/EscapedCodeBase APIs

The original intent for these APIs was to return URL to use for Code Access Security checks. E.g. if the assembly was downloaded from internet, these APIs can return http://something.

I do not have a strong opinion about what to do about these for single file.

[jkotas]

Returning empty string sounds most reasonable to me.

[agocke]

In the single-file case, even corelib will likely be in the bundle and so have an empty string location, so empty string seems most consistent and simplest to understand. I also don't have strong feelings.

[MichalStrehovsky]

From .NET Native experience:

This API is similar to the Assembly.Location API - the Location API has empty string as a documented value on MSDN and .NET Native used that. We got a lot of questions about this API and bug reports (failure in a NuGet package that the developer is not able to root cause that we then later root caused to not handling the empty string and using it for stuff that later ended up with NullReferenceException within the NuGet).

For CodeBase, .NET Native just threw PlatformNotSupportedException and we didn't receive any questions about this as far as I know. Empty string is not a documented value here. We would need to update the doc.

I would just go with throwing an exception with a message. We are obsoleting the APIs; no need to spend more energy on things like updating docs.

[jkotas]

Good point. Throwing from APIs like this makes diagnostic a lot easier.

[agocke]

One complication: we've apparently doc'd the behavior when the assembly is loaded as a byte array:

If the assembly was loaded as a byte array, this property returns the location of the caller of the Load(Byte[]) method overload, not the location of the loaded assembly.

Obviously in the bundle case every case would be loaded from a byte array, so this behavior isn't well specified, but I'm not sure how we would deal with this in the code.

[agocke]

All of these APIs throw in 5.0 and 6.0