Sdk: Follow up - Implement `mode` option for `dotnet publish`

[wli3]

add this issue to remind us to follow up https://github.com/dotnet/cli/pull/9460

9460 is merge to unblock the info bar (insertion to VS) change. However, there is still some discussion have not finished. Please close this issue if there is no more concern on https://github.com/dotnet/cli/pull/9460

[livarcocc]

@nguerrera and @peterhuene any thing left here? Or are you guys in agreement with the current experience?

[peterhuene]

I don't have any additional requested changes to make for the --mode option, at least for the publish command.

If @nguerrera does, I'd be happy to make any needed corrections.

[nguerrera]

I don't have a strong opinion, but this is where I was trending when we last discussed this:

--mode fx-dependent -> same as defaullt, framework-dependent, portable app
--mode fx-dependent -r RID framework dependent, RID specific app (includes exe)
--mode self-contained -r RID -> self contained (by definition RID specific) app

If you really want fx-dependent, rid specific, but no exe, drop down to msbuild:
--mode fx-dependent -r RID -p:UseAppHost=false

(Maybe the name UseAppHost could be a little friendlier: GenerateExecutable?)

My concern is that no-exe featuring prominently as first class in CLI just adds cognitive load for everyday users for a case that they won't ever want.

Again, I don't feel super strongly about it.

[nguerrera]

Adding @KathleenDollard

[peterhuene]

If we were to eliminate fx-dependent-no-exe, I'd almost advocate for removing the --mode option entirely since --self-contained already exists and --self-contained=false implies being framework-dependent (perhaps adding --fx-dependent as an alias for --self-contained=false for parity).

It's not hard to make that change still, but we have a short window to get this in. I also have no strong opinion on this, but I do want an understandable UX for our users.

[peterhuene]

Retargeting this issue for 2.2.1xx given the recent decisions.

I'm leaning towards just having --fx-dependent be an alias for --self-contained and drop --mode entirely if we don't want a UX on the command line for "framework-dependent but no executable please".

[nguerrera]

I'm leaning towards just having --fx-dependent be an alias for --self-contained

Specifically, an alias of --self-contained false, right?

I second that.

[peterhuene]

Whoops, that's correct. Alias to --self-contained false.

[dasMulli]

If fx-depenent is becoming the new default (I'm all for it), then --mode should really be dropped. This would even make more sense when in 3.0+ this may be required for desktop apps that need a GUI executable and possibly have customisations like app icon, manifest etc.

Is there any 3.0 planning already? it would be interesting to evaluate planned future needs for any CLI UX that affects this kind of build options. e.g. Linking options, desktop/console hosts, portable apps vs self-contained, any other packaging options etc.

[KathleenDollard]

I'm confused, so therefore, we are probably not there yet.

I'm not quite sure why a new developer to .NET would understand what fx-dependent means. Of course everything is fx-dependent!!! what are you talking about!!!!

I understand that we have 4 scenarios one of which we think is sufficiently unexpected (RID specific but no exe) that we are OK forcing users into the MSBuild where they get no help from us.

I feel the user figuring this out, either for the first time or returning, will be thinking about what exe/dll mode they want and will benefit from a single switch with arguments clarifying the different options. Different switches means they will be scattered among the 13 switches (yes, 13) we already have on dotnet publish

[peterhuene]

So I'm ironing this out for 2.2 now. My proposed changes are simply this:

• Change UseAppHost back to default to true in the SDK for all self-contained apps (required to be set) and framework-dependent apps that target >= 2.2.
• Base the TargetLatestRuntimePatch logic off of UseAppHost and not SelfContained. This ensures self-contained apps and framework-dependent apps that are using the apphost get the very latest patch level.
• Since there's confusion over what --fx-dependent would mean to users, I propose no change to the dotnet publish UX at all at this time; if you want a framework dependent application to be published, continue to use --self-contained=false.
• If we think users will want to "opt out" of the apphost creation for framework-dependent apps that target >= 2.2, the we should probably add a new option to dotnet publish. Until we think that is necessary, users can pass -p:UseAppHost=false to dotnet publish. Note that this is a single new file (the apphost) for users and it can be manually deleted from a published application with no ill effect to the application (other than requiring dotnet to activate, like users have to do today).

Thoughts from everyone?

[nguerrera]

Base the TargetLatestRuntimePatch logic off of UseAppHost and not SelfContained. This ensures self-contained apps and framework-dependent apps that are using the apphost get the very latest patch level.

The consequence of this is that FDD with exe will not run on machines that do not have latest patch applied. This makes it lose one of the desirable characteristics of framework-dependent apps. Is the apphost asset isolated to its own package? Is it possible to roll forward just that?

[nguerrera]

Otherwise, looks good, and maybe we can accept this too, but I want to be sure we think through the consequences and alternatives.

[peterhuene]

That's a great point. The apphost is in its own package. Let me see what I can do to isolate this.

[peterhuene]

Ok, so change the second bullet item above to:

• When UseAppHost is true and building/publishing for a framework-dependent application, add an implicit reference to Microsoft.NETCore.DotNetAppHost to the latest patch version. This will ensure the latest-known apphost is copied, while still keeping the application itself targeting the "0 patch level" framework. This allows the application to run on any compatible framework, even if the installed framework is a previous patch-level version than the apphost itself.

[nguerrera]

I think that's better, but acouple more things are occuring to me:

• Are we guaranteed to have a new version of Microsoft.NETCore.DotNetAppHost for every patch of the runtime, or does this mean we have to track the latest app host version separately from latest runtime? cc @steveharter

• The useapphost option will be equally subject to the problems around having to have a consistent value at restore and publish as selfcontained.

I apologize for not raising either of these earlier, these implicit versions are always messy. :(

[nguerrera]

A separate option is to assess the risk to not auto-patching Microsoft.NETCore.DotnetAppHost implicitly. It doesn't have much code, right? We could just keep the option to tell users to ref Microsoft.DotnetAppHost with a fix if they actually hit an issue.

[peterhuene]

Although it does seem that the apphost and runtime are in-sync wrt version numbers currently, explicit referencing is always an option. I'll put up the PR tomorrow and we can discuss it further.

Agreed that UseAppHost will be as problematic as SelfContained regarding consistency with restore and build/publish and project references; unlike SelfContained, at least, UseAppHost likely won't be set as a global property.

[peterhuene]

Closing this issue for now. I think just keeping --self-contained false as the mechanism to get a framework-dependent apphost is best. Users that really want to opt-out of this can specify <UseAppHost>false</UseAppHost> in their project files.