Project-system: Allow launch settings to be created at the user level

[tmat]

Repro

1. Create a .NET Core console app
2. Go to project settings, Debug property page and fill in _Application arguments_.
3. F5 to debug the app launched with the specified arguments

Current behavior

The project system creates launchSettings.json file. If the project is under source control (e.g. git) the user needs to add it to .gitignore file or it ends up in the repo, where it affects everyone who works on that project even though the settings are in many cases meant to be used just for a few debugging sessions on the dev machine.

Proposal

Introduce a predefined profile <user specific> created by default for a new project. This profile would be persisted in .suo file instead of launchSettings.json. If the user wants to define settings to be used by other contributors to the repository they do so by creating a new profile.

If the .suo file doesn't contain any settings for given project and launchSettings.json is present, the settings in the first profile in launchSettings.json would be used to initialize the _user specific_ profile. That way the repository can contain defaults for the developers working in the repo.

[4creators]

IMO locating project specific info in suo is sub optimal. It mixes concerns as project specific setting should be associated with project and not solution file. Anyway configuration management via solution file works really bad and currently due to this in all my projects I move it explicitly to custom build props file.

[sharwell]

This is closely related to #2540. I'm assuming that @tmat meant to suggest placing the properties in a .csproj.user file, similar to how the legacy project system persisted them.

[tmat]

.csproj.user file would be fine too, likely better. The important thing is - it should be stored to a file that's commonly listed in .gitignore.

@4creators This information is not meant to be managed by users. It'd be used only to persist the last used settings across instances of Visual Studio on the same machine. You could still use launchSettings.json if you prefer to save the settings in the repository and/or manage them yourself.

[4creators]

@tmat

.csproj.user would be one of the good solutions to the problem

[ghost]

launchSettings.json for me is included in the .gitignore by default?

[Grand-Poobah]

Its been almost a year, this would be a nice feature that we could use today

[drewnoakes]

.csproj.user is an MSBuild file. It would be a fair bit of work to redesign the launch settings code to store its data in properties. I'm not sure how you'd replicate that structure with a flat list of properties.

The issue seems to be that the name launchSettings.json doesn't hint whether the file should be version controlled.

Two ideas come to mind:

1. Move the file to within the .vs folder, where it's clear that it's a VS-only file and shouldn't be under version control
2. Rename the file to end in .user

Is there a reason we could not do the first option? Is this file really only used by VS?

Moving the file could be a breaking change for people using newer and earlier versions of VS on the same machine. We could support the current behaviour but default to creating new files in the .vs folder. This would also allow anyone who actually wants the file in version control to continue doing so.

[tmat]

It would be a fair bit of work to redesign the launch settings code to store its data in properties.

Why not just store the content as a single string property that contains the whole JSON?

[drewnoakes]

While that could work, I'm not a fan, and it'd still be much more work than just adding logic to look in the .vs folder. I don't see there being enough payoff for changing the representation. Docs need updating, people have to re-learn a bunch of stuff. By contrast, allowing this file to be in the .vs folder is a single concept which is easy to understand and document.

[drewnoakes]

Discussed this with the team and the conclusion was that there are valid reasons to have this file in version control (example).

The file also exists per-project, so would need to be renamed if in the .vs folder.

I'm now interpreting this request as for the ability to control whether launch settings at the team vs. workspace (user) level.

[Grand-Poobah]

while you are at it can you look at the settings for running a solution as a website and using the run in express button

To speed development up I prefer setting the site up in IIS, it is faster than having express spin up every time

Other "developers" use the run button since they have no idea how to set up a web site

the issue is that once the run in IIS express has been launched values are added to the web.config that stop the application from running in IIS

thank you

[drewnoakes]

@Grand-Poobah this is unrelated to this issue and potentially unrelated to this GitHub repo. Please file a suggestion as described in https://docs.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2019. Thank you.

[PureKrome]

I've had some grief with this issue for a while. Last night I posted a tweet about this and @VisualStudio said to create a feedback request, which I did.

This issue is about global launchSettings vs user-based launchSettings. I'm hoping to tweek this issue a bit further and say that this should also consider VSCode, not just Visual Studio. VSCode currently has it's own launch.json (and schema) in a .vs folder. So I was hoping, praying*, that in the future we could have 1x schema and it could be in 1x location where VS and VSCode both respect it and use it. Then our teams where some use VS and other use VSCode can live in harmony.

NOTE: Cheers to @davidwengier for pinging me to this issue.
*Aussie Joke: "Thoughts and Prayers".

[jzabroski]

Agree, this would be awesome. We .gitignore this file right now, so it doesn't go into source control. As a result, everyone has the default laugh settings when checking out from source control.

Would LOVE allowing per-user launch.json/launchSettings.json to be checked into source control.

However, if we're talking about user stories behind this request, I will share exactly what we do:

We have a TaskRunner, similar to Adam Ralph's BullsEye. It is a program that recursively opens a C# program. It looks up the program to open based on a task key.

{
  "profiles": {
    "TaskRunner": {
      "commandName": "Project",
      "#commandLineArgs": "TASK1",
      "commandLineArgs": "TASK1 /AsOfDate:05/25/1984"
    }
  }
}

This ends up as a messy user experience in the Visual Studio debug tool pane:

1. I hand-edit the json file and add a # to comment out/toggle the commandLineArgs
2. If I have multiple tasks, I end up having to change the profile name to something like "TaskRunner - TASK1 commandLineArgs", but this is a lot of diddling just to be able to visually see exactly what I am going to run if I click the Green play button.

@davidwengier . also @jonsequitur - Tagging you based on discussions you and I have had in the past about how to simplify the notion of "components" in Visual Studio across "Run Custom Tool", "dotnet.exe new", etc.

[Bosch-Eli-Black]

We're looking for something like this as well.

We have a VS solution that starts multiple projects (websites) when the solution is run. By default, we want each website to launch a browser window, so that people who are new to the project can easily get up and running.

More advanced developers want to ability to run all of the projects but only open browser windows for some of them.

It would be great if we could check in a launchSettings.json file to Git that contained common team settings but also have support for a launchSettings.user.json file that could provide machine-specific overrides.

[tvkit]

Bumping this as a workflow issue primarily related to private/personal environment variables. For example, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

[jzabroski]

@Tvkit , don't use access keys. Use AssumeRole, AssumeRoleWithFederation, AssumeRoleWithWebIdentity (AWS Cognito). You can also do without authentication by creating a VPC link between your account and the cross-account.

[scphantm]

I have a similar use case. I write almost exclusively CLI apps. a CLI app may have 5 or 6 profiles depending on what it is. I have apps that need to read in a file thats not stored in the project for reasons. This is a pretty typical example of a launchsettings.json for me

{
  "profiles": {
    "cmd1": {
      "commandName": "Project",
      "commandLineArgs": "cmd1 --service myservice --file C:\\Users\\me\\source\\helm\\Config\\data\\serviceConfig.json"
    },
    "cmd2": {
      "commandName": "Project",
      "commandLineArgs": "cmd2 --service myservice --file C:\\Users\\me\\source\\helm\\Config\\data\\serviceConfig.json"
    },
    "cmd3": {
      "commandName": "Project",
      "commandLineArgs": "cmd3 --service myservice --file C:\\Users\\me\\source\\helm\\Config\\data\\serviceConfig.json"
    },
    "cmd4": {
      "commandName": "Project",
      "commandLineArgs": "cmd4 --service myservice --file C:\\Users\\me\\source\\helm\\Config\\data\\serviceConfig.json"
    },
    "help": {
      "commandName": "Project",
      "commandLineArgs": "--help"
    }
  }
}

now combine that with multiple developers on multiple OS's (not just windows) and you see why our appsettings files are some of the most volatile files in our SCM. We try putting the service config in an OS level environment variable and that lead to additional problems. A way to do this on a user level would be really helpful.

maybe a way similar to how jetbrains does http requests in their rest client. you have a primary file thats in SCM, but then you can create a user file that defines variables. Those variables can be used in the primary file. Method works great on Jetbrains products.

[jzabroski]

I think I might just build a VS plug-in to replace this launcher since it's not that useful to me.

For CLI programs like ours, @scphantm , if we had a common intermediary format to describe command line args, we could simply export out the a concrete syntax tree and allow direct manipulation via a VS command menu UI. I could also see interacting with this menu would work more like a video game inventory selector than the current experience, which traces back to Alan Cooper VB3 days. Would be very nice to spruce this up.

[tvkit]

@tvkit , don't use access keys. Use AssumeRole, AssumeRoleWithFederation, AssumeRoleWithWebIdentity (AWS Cognito). You can also do without authentication by creating a VPC link between your account and the cross-account.

@jzabroski I only provided an example of something not to be persisted. Appreciate the recommendations though.

[scphantm]

here are the docs for how jetbrains does it with their HTTP Client

https://www.jetbrains.com/help/idea/exploring-http-syntax.html#using_request_vars

We use that a lot around here with webstorm and such. i think a system similar to this for launchsettings would be really helpful. a launchsettings.user.json to define variables that can be used in launchsettings.json. i don't think it needs to be extravagant. If you follow Jetbrains IDE's, you know that HTTP Client replaced their very extravagant REST Client tool. they stripped that out in favor of this text based one because us developers just want it simple.