Replace launchSettings.json with MSBuild properties

[drewnoakes]

In legacy projects, debugging settings were specified in the project file:

<PropertyGroup>
  <StartAction>Program</StartAction>
  <StartProgram>C:\MyRemote\Executable.exe</StartProgram>
  <RemoteDebugEnabled>true</RemoteDebugEnabled>
  <RemoteDebugMachine>MyRemoteMachine</RemoteDebugMachine>
</PropertyGroup>

With SDK-style projects, they're kept in launchSettings.json which is a hold-over from the project.json/.xproj days:

{
  "profiles": {
    "ConsoleApp152": {
      "commandName": "Project",
      "remoteDebugEnabled": true,
      "remoteDebugMachine": "MyServer"
    }
  }
}

This file is stored in the Properties folder and tends to end up in version control.

Now that we support remote debugging, putting the remote host name in version control does not make much sense. We want to put some of these values in version control, and others in the user's local state.

By moving the properties to the project we could have some in .csproj and others in .csproj.user. Longer term we could control them per configuration/target framework/other dimension.

[drewnoakes]

@davkean points out:

This requires thought, launchSettings.json supports multiple profiles, legacy support only supports 1.

[davkean]

Triage: This needs design and its unclear what actual problems this will solve that cannot be solved by combining user file settings with the launchsettings.json file. Please come up with a design and send back to triage.

[Nirmal4G]

You could refer to the design of the Publish profiles that the ASP.NET Core team uses. The concept is similar to this but instead of launching and debugging properties they have publish properties.

[mgnslndh]

I would like to add a launch setting by referencing a NuGet package. This could be done if multiple launch settings were supported by MSBuild.

This would solve a problem where I write a plugin as a class library and a test host for the plugin is provided by the plugin's SDK NuGet package.

[mgnslndh]

I found out that using <RunCommand> in a .targets file contained in the plugin SDK NuGet package I could control the application that is executed when the class library is debugged. The application then loads the class library and it can be debugged plugged into the application.