Runtime binding proposal

[richlander]

Proposal for .NET Core 3.0

Related content:

• Roll Forward On No Candidate Fx doc defines existing behavior.
• Roll forward improvements for COM -- dotnet/core-setup #5062 specifies a proposal (largely) specific to COM.
• --fx-version argument to dotnet exec should apply roll-forward policy -- dotnet/core-setup #4146 specifies a proposal to enable roll-forward for --fx-version.

[nguerrera]

Nit 1: I think the values should all have the same canonical casing, so Patch, Minor, Major

Nit 2: I don't this Use is adding much value, how about LatestMinor, LatestMajor?

[richlander]

Good feedback. Let me share some of my thinking and see what you say. I original went with exactly what you have (ignoring the casing topic) Minor and LatestMinor. The problem is that the two settings are not symmetrical:

• Minor -- Do something only as a fallback case if a preferred runtime version is not found.
• LatestMinor -- Do something always.

That's why I added Use to LatestMinor to make it more obvious that this setting is more of a command than a request/hint. I also thought of ForceLatestMinor but that seemed a bit too forceful.

I also thought of splitting these two forms of configuration into two different settings. That seemed like the worst idea, both because it would be confusing and there is no scenario where both settings would be set.

Thoughts?

Will fix the casing.

[vitek-karas]

Maybe:
AlwaysLatestMinor
AlwaysLatestMajor

[nguerrera]

Maybe more explicit names for all cases?

These are long, but for completeness in the names as an illustration:

LatestPatch
FallbackToNearestMinorWithLatestPatch
FallbackToNearestMajorWithLatestPatch
LatestMinorWithLatestPatch
LatestMajorWithLatestPatch

[nguerrera]

LGTM. I really like the single option, and the elimination of magic [0-2] numeric values. I also never liked the "onNoCandidateFx" name.

[KathleenDollard]

Earlier a project (.csproj/.vbproj) setting was proposed. It's not mentioned here in precedence. Is that because it rolls into the runtimeconfig? Cool, but we should mention it I think.

[richlander]

Is that because it rolls into the runtimeconfig?

Yes. Project values have no meaning at runtime since (in most cases) it no longer exists as an accessible artifact. I will add a note for that.

[vitek-karas]

Well that's not exactly true. If nothing is specified anywhere, the default behavior is Minor - it basically comes from the default rollForwardOnNoCandidateFx. I think this should be stated explicitly.

[richlander]

This is what I see at runtime:

C:\testapps\twooneapp>dotnet bin\Debug\netcoreapp2.1\twooneapp.dll
Hello World!
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.7\System.Private.CoreLib.dll

C:\testapps\twooneapp>dotnet --fx-version 2.1.0 bin\Debug\netcoreapp2.1\twooneapp.dll
Hello World!
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.0\System.Private.CoreLib.dll

for this code:

static void Main(string[] args)
{
    Console.WriteLine("Hello World!");
    Console.WriteLine(typeof(Object).Assembly.Location);
}

This is the basis of the logic I wrote.

[vitek-karas]

I think that is expected. By default (1st case) the app rolls forward to the latest patch only. Note that "Minor" in the new setting is the same 1 in rollForwardOnNoCandidateFx, which only kicks in if the requested Major.Minor doesn't exist. In this case it does exist (the machine apparently has at least 2.1.0 and 2.1.7). So the roll forward logic doesn't really kick in.
Rolling forward on patches is a separate piece of functionality, and that always rolls forward to latest (unless completely disabled).

The second case uses the --fx-version which currently means exactly that version and no other. Absolutely no roll forward will happen (Major/Minor or Patch). So since you requested 2.1.0, you got 2.1.0.

[vitek-karas]

There needs to be another paragraph describing interaction with the existing rollForwardOnNoCadidateFx (even though we're deprecating it, we can't remove it). The interaction should be pretty simple I think - basically if rollForward is specified, then rollForwardOnNoCandidateFx is ignored. I would not try to combine the two in any way as it may be very confusing. And failing if both are set also feels too "dangerous".

[nguerrera]

Does this have a runtimeconfig equivalent today?

[richlander]

I was thinking applypatches. On that note, is the third example wrong on that page?

@vitek-karas was advocating for not adding None to RollForward. I find it hard to reason about --fx-version behavior in absence of a None option.

[vitek-karas]

I guess None would mean rollForwardOnNoCandidateFx=0 and applyPatches=0 in current runtimeconfig.
I'm not sure we should "advocate" it by including it in the setting here. Basically we don't want anybody to use that setting unless there's no other way as it disables security patching.

I think that if we decide to have an option for this behavior in RollForward it should not be called None - mostly because people tend to think about None as the safe default - which this is not (neither default nor safe).
If we include it I would call it DisableAll or something like that - to make it more explicit and more "scary".

[nguerrera]

Last time we spoke in a big group about this topic, there was a lot of openness to Major becoming the default. Is that now off the table? cc @DamianEdwards

I think that this proposal makes configuration easier and the whole process easier to understand, I was really hoping that global tools would start to just workin mismatched major case. cc @wli3

[richlander]

There was more openness to it at the time. I'm not proposing that, however, as the way to move forward. When we flip that lever, the journey to re-inventing the .NET Framework will be complete. Yeahh!

Another way of putting is asking which UX experience we want (since both will exist to some degree):

• Why didn't think app start? Oh, I have to install something from Microsoft. Ain't got time for that. Screw this app!
• Why did this app crash? I don't know. Screw this app!

I'm pushing choice 1 as the good default. The second one is too hard for everyone involved.

[vitek-karas]

There's also the argument about hosting environments (think ASP.NET hosting). That is running my app on a container/VM which is managed by somebody else. If in such case I try to run a 2.* app on a host which only has 3.0 and it silently works... everybody thinks (including the hosting provider), that it will work just fine. In reality there might be some slight behavioral difference which can't be tested for upfront before deployment. It makes it harder for both sides to have a solid experience.

[nguerrera]

OK. Next question: do you consider it OK if we recommend to global tool authors to put RollForward=Major in their csproj. We have a lot of feedback that folks don't like that their global tools do not work with only 3.0 installed.

[jkotas]

OK if we recommend to global tool authors to put RollForward=Major

It is ok as long as the global tool authors understand the consequences. This setting increases probability that the tool won't work.

I think it is manageable for small tools that are unlikely to break. I would not recommend it for large complex tools.

[vitek-karas]

Looks good.
There's one large missing peice - handling of previews. Basically define rules about rolling forward (and versions) from/to previews, in case non-previews are missing and so on.

[vitek-karas]

I guess None would mean rollForwardOnNoCandidateFx=0 and applyPatches=0 in current runtimeconfig.
I'm not sure we should "advocate" it by including it in the setting here. Basically we don't want anybody to use that setting unless there's no other way as it disables security patching.

I think that if we decide to have an option for this behavior in RollForward it should not be called None - mostly because people tend to think about None as the safe default - which this is not (neither default nor safe).
If we include it I would call it DisableAll or something like that - to make it more explicit and more "scary".

[vitek-karas]

There's also the argument about hosting environments (think ASP.NET hosting). That is running my app on a container/VM which is managed by somebody else. If in such case I try to run a 2.* app on a host which only has 3.0 and it silently works... everybody thinks (including the hosting provider), that it will work just fine. In reality there might be some slight behavioral difference which can't be tested for upfront before deployment. It makes it harder for both sides to have a solid experience.

[vitek-karas]

I like the overall outcome of this. The only confusion might arise when all the different ways to specify these settings is combined. If specified on command line together like this, it makes perfect sense. If the RollFoward is specified through an environment variable which is effectively invisible, it gets a bit more complicated (as compared to existing behavior of --fx-version).
Basically if I specify --fx-version today I get some relatively predictable behavior. After this change that behavior becomes less predictable since the ambient env. variable may modify it. Now I have to know about the env. variable (and the runtimeconfig setting to be able to decide the exact behavior.

I'm not sure if it's OK to leave it like that, or if there's something we should do... and I don't know what... just raising a concern.

[richlander]

It is a concern. The order of precedence for command line and ENV is really tough.

Here are two scenarios to consider (where both CLI and ENV config is used):

• --fx-version 3.0.0 & ENV DOTNET_ROLL_FORWARD=Major
• --fx-version 3.0.0 --roll-forward=Patch & ENV DOTNET_ROLL_FORWARD=Major

I now think I have it wrong. I think most people expect that the CLI would beat config in the second case. That said, I do think that the ENV needs to be honored in the first example to enable hosters to have control over a large number of apps.

[vitek-karas]

Can we add some reasoning why this order?
I understand why we want runtimeconfig to be the least important. I'm not sure about ENV winning over CLI. ENV may be "global" while CLI is always very specific to the app.

[richlander]

Ya. I think you are right. I will switch.

[vitek-karas]

It would be good to list the various ways to specify version. Is it the version of framework in runtimeconfig and --fx-version CLI, or is there something else as well?

[richlander]

I am only aware of those two and cannot think of a useful other option. We could have an ENV to specify version, but I suspect you'd largely want that to test latest and we now have an ENV that does that.

[vitek-karas]

OK - those two make sense - maybe we should list them here, as they are not explicitly mentioned together anywhere in this doc I think...

[vitek-karas]

Note that runtimeconfig has two levels. For example rollForwardOnNoCandidateFx can be specified globally (for all frameworks in the app) or locally per-framework.
I assume we would allow the same for rollForward, in which case there's a precedence to define.

[richlander]

What would that look like? I don't think I'm familiar with this scenario.

[vitek-karas]

.runtimeconfig.json can look like this for example:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "applyPatches": false,
    "rollForwardOnNoCandidateFx": 0,
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.0.0",
      "applyPatches": true,
      "rollForwardOnNoCandidateFx": 2
    }
  }
}

The settings per-framework win over those on the global level.

[vitek-karas]

As mentioned below, runtimeconfig should probably support both global and per-framework setting.

[vitek-karas]

LGTM

[vitek-karas]

Probably a copy paste error - the sentence seem to end too early.

[vitek-karas]

Not sure we should explicitly state that this is for COM... it is useful in other cases as well. But if you think it makes sense, I'm fine with it.

[normj]

I think you meant "applications to use that later major version."

[normj]

Will there be any info or warning text when the app starts to warn the user for the major version roll forward?

I see a developer just assuming there app will work for all future versions without knowing that version 4.0 changed his assumptions and the app crashes. If the app transparently rolls forward and crashes the user never realizes they can solve the problem them selves by installing the appropriate version of .NET Core and instead blame the original developer.

[richlander]

Our philosophy is that the developer owns stdout and stderr. In part, one app's stdout in another app's stdin. stderr is more an option, but is also not perfect.

My belief is that it should be uncommon for apps to run in environments where major version rollforward is enabled. If apps crash in such an environment, it should be possible to connect the opt-in rollforward setting with the crash and consider that the setting is the cause of the crash if no other more obvious causes are identified.

Fair?

[vitek-karas]

What other mechanism do you think should be used to notify about the roll-forward happening.
On Windows we were discussing that maybe we should write an information event into the event log.

[richlander]

That's the only good option I have at the moment. We could also expose it via the new runtime events so that various in-proc event loggers could collect this info.

[normj]

I like the idea of it getting put out as a runtime event.

[normj]

typo precendence -> precedence

[normj]

LGTM

It requires a high bar of compatibility between minor versions and protects .NET Core's ability to evolve with breaking changes when they are important for major versions.