Add AppContext.ApplicationName

[davidfowl]

There are cases where the exe name and the application are not the same. Consider a scenario where the entry point of the application is not user code, it could be a different host (like when you're running in windows service) that loads your application as a plugin (.dll). We do this today in ASP.NET and there are 2 modes of execution:

• Your web application owns the application entry point.
• Microsoft.AspNet.Hosting owner the entry point your web application is loaded as a plugin.

This name should be settable (and not only by the native host). This should default to the application with the entry point by default.

/cc @lodejard @nguerrera @joshfree @AlexGhiondea

[weshaggard]

@davidfowl is this for display purposes or will there be decisions based upon it? If it is settable is it safe to assume it should fail if someone sets it more than once?

[davidfowl]

@weshaggard not for display. Decisions will be made based on this for sure.

If it is settable is it safe to assume it should fail if someone sets it more than once?

I'm not sure it needs to be that strict. You could imagine a layered system that composes different entry points. Each of those entry points changes the name based on arguments passed into it. It shouldn't throw.

[weshaggard]

Can you point me at code where you use it to make decisions? It seems like it would be trouble if decisions are made and someone changes it and now different decisions are made.

[davidfowl]

https://github.com/aspnet/Hosting/blob/dev/src/Microsoft.AspNet.Hosting/WebHostBuilder.cs#L144

[AlexGhiondea]

I think it is fine to overwrite the value as long as no-one has read it. Once it is read it should be fixed to make sure all the decisions are made based on the same value.

[mellinoe]

I wonder how much usage this would get? My gut reaction is that it is a bit of a niche API, at least the way it's being described (global user-controlled string that is settable/resettable).

I think if I wanted to use an API like this, I would either:

1. Already know the information, based on the context of the code I am writing
2. Know it based on the EntryAssembly (which I think we should add back)
3. Probably want to know something more specific than just the "name" of the application

I'm not really able to follow the example you linked closely, but that's probably because I'm not familiar with this area of ASP.NET. It seems like it's mainly being used as a fallback to a user-configurable string value, where the value has to be equal to the assembly name anyways (just going by the name of the variable "StartupAssemblyName"). Is there a use case in a more simplified context? It's hard to judge whether it would be useful in a general sense with an example that's so closely tied to a specific ASP.NET context.

[davidfowl]

Don't think of it as ASP.NET. Here's another scenario. Lets say I did some assembly loading based on the application name, by default it's the app entry point. Now say that I'm writing a functional/unit test and I want to change that context when running form a unit test since the unit test binary is the host.

[davidfowl]

Maybe of ApplicationName should be an AssemblyName instead.

[AlexGhiondea]

I think AssemblyName is more confusing than ApplicationName but it depends on what you actually end up storing in there.

Can you give an example of the value this will hold?

Regardless of the name, my plan is to allow users to set the value as many times as they want until a read of the value happens. After that. Calls to set will throw.

@davidfowl let me know if that covers your scenario.

[terrajobst]

@AlexGhiondea, can you drive this through the API review? It seems there are still some pending concerns around:

• The return type
• The semantics on how this property can be set, if it can be set, and by whom

[AlexGhiondea]

@terrajobst - absolutely!

[AlexGhiondea]

Reason for API

EntryAssemblyIdentity

There are certain scenarios where the assembly that CLR considers as the 'EntryAssembly' is not the assembly the application considers as the 'EntryAssembly'.

Here are two examples where the host considers the 'EntryAssembly different than what the CLR does:

• Unit test frameworks which host the code to be tested would potentially consider the 'EntryAssembly' the dll that contains the tests
• ASP.NET hosts would like to consider as 'EntryAssembly' the dll which contains the statup code

Proposed API

namespace System
{
    public static partial class AppContext
    {
        public static string EntryAssemblyIdentity { get { return default(string); } set { } }
    }
}

Details

EntryAssembly

By default (if the host does not overwrites it) this API will return the value of the 'EntryAssembly' from the CLR's perspective (which, if you are a host, will be the assembly for the host).

However, managed hosts are able to change this value to something else, depending on their requirements.

The semantics of this API allow setting it multiple times until the value is read once. This ensures that the value has a consistent value once it was read.

Assembly identity

The 'identity' of the assembly is defined as the FullyQualified name of the Assembly (including name, culture and public key) as a string.

The string returned from this property should be parseable by the constructor for 'AssemblyName'.

We chose to expose this information via a string in order to maintain the dependencies of AppContext to a minimum. Having this API return an AssemblyName would require a dependency to System.Reflection which we would like to avoid.

[mellinoe]

Unit test frameworks which host the code to be tested would potentially consider the 'EntryAssembly' the dll that contains the tests

I dunno, would anyone actually want to do this? It seems to me like a stretch to call that the "Entry Assembly", considering how many other assemblies are typically entered before it in a typical testing framework. It feels like this would just be using the property as a "convenient global string".

The semantics of this API allow setting it multiple times until the value is read once. This ensures that the value has a consistent value once it was read.

I'm a bit concerned about the usability of this. For example, if a library wanted to use this value, it would have to make it clear to the application that it needed to set the EntryAssemblyIdentity before calling any of the functions in the library. Also, it would be very weird if you were writing some code, tried to set the EntryAssemblyIdentity, and got an exception because one of the libraries you called had already read the value (without telling you). It's a pretty bad experience, I think.

The Command Line parsing library we use (for GenFacades and others) could potentially use this property (right now it just uses Assembly.GetEntryAssembly). If it wanted to do so, applications would need to set the value before calling CommandLine.Parse, or not set it at all. It would be up to the library author to make it really obvious how that would work, which would end up being very confusing, I think (because people wouldn't document it).

Also, going back to the unit testing use case. If you can only set it once, how will that work for test runners that let you run multiple test assemblies? For example, xunit.console lets you pass multiple test assemblies into the runner, and it will run them one at a time. This wouldn't really work there, because you could only set the property once for the first test assembly.

[AlexGhiondea]

Thanks @mellinoe for you comment! Those are some great points.

I think I heard two major areas for feedback. Let me try and address them:

Unit testing

I dunno, would anyone actually want to do this? It seems to me like a stretch to call that the "Entry Assembly", considering how many other assemblies are typically entered before it in a typical testing framework. It feels like this would just be using the property as a "convenient global string".

That is the point. If there are multiple assemblies loaded, the order in which they are loaded would be irrelevant. The host would be responsible for setting the value of the property to the assembly that contains the code to be tested.

I guess there is nothing that prevents the host from writting anything it wants in the field which would essentially turn it into a global string.

I'm a bit concerned about the usability of this. For example, if a library wanted to use this value, it would have to make it clear to the application that it needed to set the EntryAssemblyIdentity before calling any of the functions in the library.

Indeed.

However, the purpose of this property is to be set by the host and be read by the application. Once the host has correctly setup the AppDomain it should transfer control to the hosted application which would then be able to read the value. I don't expect that we would want libraries to set this value.

One way to think about this is similar to the 'EntryAssembly' property on AppDomain. That property is read-only and it is set at application startup by the runtime. That value cannot be changed by the application.

For example, xunit.console lets you pass multiple test assemblies into the runner, and it will run them one at a time. This wouldn't really work there, because you could only set the property once for the first test assembly.

This is interesting. Do you know if xunit will create a new AppDomain for each of the assemblies it has to test? If so, then for each AppDomain it uses it can correctly set this property corresponding to the tested assembly.

Allowing this to be changed at any time is somewhat problematic. If the value is not consistent across application calls, the application would get different values depending on when it reads the value.

Usability of the API

Also, it would be very weird if you were writing some code, tried to set the EntryAssemblyIdentity, and got an exception because one of the libraries you called had already read the value (without telling you). It's a pretty bad experience, I think.

The idea is that by the time the application has started running, this value is set to its final value and there should be no reason for the application to try and set it.

I did consider an approach where this scenario would be supported:

namespace System
{
    public static partial class AppContext
    {
        public static string EntryAssemblyIdentity { get { return default(string); } }
        public static bool TrySetEntryAssemblyIdentity(string entryAssemblyIdentity) { return default(bool); }
    }
}

If we think the current approach is too hard to figure out then we can remove the setter and add the above method.