From a Halp message:
/Properties/launchSettings.json is being ignored in the default .gitignore.
Need to figure out if this is our .gitignore or Visual Studio's .gitignore.
And then if it is actually a problem for .NET Core 2.0 projects.
Same for me... it is included. Repo was created by visual studio about 6 months ago
@grokys @jcansdale have any context on this issue or know why this would be a problem with .NET Core 2.0 projects?
Here is a simple use case that shows why it's a problem:
I hope this makes sense. I imagine it's a very simple thing to fix, I'm also curious as to why launchSettings was included in gitignore in the first place.
You can check this pull request https://github.com/github/gitignore/pull/2705 in ignore project.
Yep, https://github.com/github/gitignore/pull/2705 has been merged a few days ago, so if Visual Studio is consuming this repository (I'm pretty sure that's the case) then they should get this change as part a future update.
I couldn't find a submodule for github/gitignore in here, so I think this is an upstream issue.
I think it was rightly included in gitignore. Local machine-specific settings like launchBrowser, environmentVariables, launchUrl, etc. seem exactly the kind of files gitignore is for, and I'm not sure they should be foisted on other devs by whomever committed first. Also, it clutters commits when devs change their local settings to something more compatibile and either the file settings keep flipping or they have to keep managing the changes when pulling new updates. Connecting local services with arbitary local ports that happen to work on one machine seems more the responsibility of the local dev who controls the local setup. There are other solutions to that kind of thing anyway.
I think it was rightly included in gitignore. Local machine-specific settings like
launchBrowser,environmentVariables,launchUrl, etc. seem exactly the kind of files gitignore is for, and I'm not sure they should be foisted on other devs by whomever committed first. Also, it clutters commits when devs change their local settings to something more compatibile and either the file settings keep flipping or they have to keep managing the changes when pulling new updates. Connecting local services with arbitary local ports that happen to work on one machine seems more the responsibility of the local dev who controls the local setup. There are other solutions to that kind of thing anyway.
This flip side of this is if you want to enforce standards and pre-setup different launch environments for your team. Without checking it in, i'm not sure how you would do that? I guess every developer would need to waste time setting these things up themselves?
So, setting up my first AspNETCore 3.1 Blazor project, and it created a .gitignore which includes the following:
# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/
**/Properties/launchSettings.json
I did a search for launchSettings.json gitignore and this issue is the first entry on the list. :) Further links are not so consistent on whether this file should be checked in or not. Any guidance would be greatly appreciated. 馃憤
@Mike-EEE how did you create the project? If it was within Visual Studio itself (rather than using the GitHub for VS extension) then someone from the VS team needs to refresh the gitignore templates they ship in the box.
Hmm @shiftkey that is a good question. I just now tried creating a new Blazor project from scratch and adding it to source control. I then created a new GitHub repository with a Visual Studio ignore file. Both are the same:
# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/
So it would seem that somehow my launchSettings.json got added to my ignore file. Clearly a lot of moving pieces on my side as I have been dealing with a fire hose quantity of information lately in the realm of Blazor and .NET Core 3.1. I must have accidentally ignored it somehow while turning/pressing all the new knobs and buttons. My luck. 馃槅
In light of this, it would seem that launchSettings.json is meant to _not_ be ignored but instead _included_ in source control.
I hope I have that right. :P
In light of this, it would seem that
launchSettings.jsonis meant to _not_ be ignored but instead _included_ in source control.
This is correct, based on https://github.com/github/gitignore/pull/2705 where @NTaylorMullen gave it this 馃憤:
The
launchSettings.jsonfile has evolved since that last linked issue. It is now an integral part of the run experience in VisualStudio. I'd say this PR is a good thing 馃槈
That was merged in May 2018 (over 18 months ago) and given the default VS project creation and GHfVS repo creation result in the correct template I feel this should be closed.
If anyone spots an old template in the wild I'm happy to chase down whoever needs to update it.
Most helpful comment
Here is a simple use case that shows why it's a problem:
I hope this makes sense. I imagine it's a very simple thing to fix, I'm also curious as to why launchSettings was included in gitignore in the first place.