Make launchSettings.json handling something that can be reused by other design time tools

[divega]

Issue https://github.com/dotnet/cli/issues/6617 was about supporting launchSettings.json in dotnet run. Visual Studio also has its own way of supporting launchSettings.json.

There are actually other tools that need to honor information from launchSetting.json, such as environment variables and command line options when executing any application code on behalf of the user, but every time we have solved the launchSettings.json problem so far, we have done in and ad-hoc manner (see dotnet/cli#6698 and https://github.com/dotnet/cli/issues/6617#issuecomment-302509090 for what CPS does) that does not allow for the logic to be reused.

This is the case for many of the dotnet ef commands (see dotnet/efcore#8695) but possibly any tool that executes user code will have similar requirements.

cc @bricelam @ajcvickers

[peterhuene]

Pinging @livarcocc (who's currently on vacation, but will hopefully see this when he gets back next week).

We would need to figure out which team would own this shared component, I assume.

[wjrogers]

I noticed that dotnet run ignores commandLineArgs in launchSettings.json; in fact, it seems to support only environment variables. Surprised me because the console message "Using launch settings from..." implies full support that isn't there.

Is adding support for command line arguments a likely side effect of developing this shared component? Would it be helpful if I opened a separate issue specifically about supporting configured command line arguments in dotnet run?

[livarcocc]

cc @vijayrkn @mlorbetske

[divega]

@livarcocc @vijayrkn @mlorbetske what is the status of this? I would like to make sure it didn't fall off the radar when it was moved to the discussions milestone.

[livarcocc]

@divega we have no intention of moving this forward. When this code was originally put into the CLI, my ask was for the VS team to expose the code that handles that file as a library to be consumed by the CLI and by VS. This would allow us to have a fuller comprehension of the file, versus the limited subset we do today. And, it would also keep the line of ownership clear to all folks looking at the code.

The code is owned by @vijayrkn's team, so I will let him comment on his plans for this.

[divega]

Thanks @livarcocc for answering. Will work with the assumption the CLI has no plans for now. @vijayrkn any thoughts? Happy to chat here or in person about the impact of this.

cc @bricelam @ajcvickers

[vijayrkn]

@divega can you please set up some time with @BillHie @MLorbe and me to discuss the details?

[livarcocc]

I am going to close this issue as this is not the right repo to track this and seems like the right people have been engaged.