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.

[Eli-Black-Work]

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.

[avivanoff]

Would be nice to have per-user launch settings that does not need to be committed.

[ghost]

@avivanoff: Agreed. launchSettings.user.json would address this issue handily, the same way appsettings.user.json does.

[svdHero]

Any update on this?

[avivanoff]

More than 4.5 years? Really?

[jzabroski]

I don't think you should expect anything to be done here. For one, vscode and Visual Studio Big Brother have different formats for these files. For two, there was a GitHub Spaces initiative to have a mechanism to bootstrap environments with required build tools, called init, but that never made it into Visual Studio Big Brother.

[sharifmamun]

This issue probably should be closed saying will not be done.

[Balfa]

This is (at time of writing) the 14th most thumbed open issue in the repo, and this repo has plenty of activity. I think it's unfair to assume this will never be done. Get all your friends to thumb the issue if you care deeply about it.

@drewnoakes I think at this point it's a very standard workflow to have appsettings.json overridden by appsettings.Development.json which is the de facto configuration when deployed to a shared dev environment. Then environment variables in launchsettings.json override that for when we hit F5 on a developer's laptop, because I probably need to point at a different dependency URL when I'm outside the dev environment. We need this so that anybody who clones the repo anew will be able to F5 without friction. But then I want to make sure that my local debugging uses my own credentials against some shared resource, I need env variables in launchsettings.json.user to override everything else and these, being my own credentials, should not be committed to version control. Currently, I have to either keep launchsettings.json changed locally and keep remembering not to accidentally commit it, or I need to create some windows-level environment variables before I start VS. Both workarounds are nasty.

Am I missing anything? This feels like such a common workflow (and workaround). I'd really love to see this issue get some love 😀

[labeled]

We have a need for this as well. Multiple developers working with SQS or RabbitMq queues. If we only get one launch setting for the solution we all connect to the same queue and process each others messages. Would be great to have a launchsettings.user.json file that allows us to specify a custom exchange per developer instead.

**Edit

We've actually used user secrets to solve this problem. Generate a user secret for your project, check in the source, and have individual developers overwrite their settings with the secrets.json file.

[jzabroski]

I have a rough idea on how we can side-step the project system and get something working here, based on kzu's https://github.com/devlooped/SmallSharp project, which is really only intended for C#9 top-level program switching, but has general ideas that could be retrofitted to support user launch files, VScode or VS Big Brother be a monkey's uncle

1. MSBuild supports .user files viz a viz "Microsoft.Common.CurrentVersion.targets imports $(MSBuildProjectFullPath).user"
   1. Source: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#user-file
2. MSBuild "God" Daniel Cuzzolino (kzu) has put together JsonPoke and JsonPeek MSBuild nuget packages , probably based on Manish KP's bitbucket project
3. Use GeneratePathProperty="true" to generate an MSBuild variable PKG_JsonPoke that we can then copy to the launchSettings.json directory
4. Import task <UsingTask AssemblyFile="JsonPeek.MSBuild.dll" TaskName="JsonPoke" />
5. Call the task, similar to https://github.com/devlooped/SmallSharp/blob/6017c59d9743f22c423148858fc3c208a71b95bd/src/SmallSharp/SmallSharp.targets#L145-L152
6. Buy me a coffee?