Should I check the dotnet-tools .config directory into source control?

Question

Recently I've noticed a .config directory being created by Visual Studio with a dotnet-tools.json file in. Should this be .gitignored or checked into source control?

Lepanto

I'm not sure what is this specific config file but your answer is simple. first check the config, if it contains some global configurations that can help other users using your project you should add it to your repo but if it contains any personal information (related to you or your system) you should ignore it. – Verleneverlie

for example, I'm using vs-code. I added tasks.json to my repo but ignored settings.json from .vscode folder in my project directory. – Verleneverlie

We always ignore the .vscode folder, it mostly contains user specific configuration – Sigmoid

Answer 1

.config directory with dotnet-tools.json file is created when you install a tool for your project with dotnet tool install command. This file dotnet-tools.json contains details like version, installation command etc. about all the tools installed for your project. It is more of a local configuration related to setup on local machine. If you want your colleague to install the same tools on her/his machine then you should check-in this file and your colleague is required to clone and run command to restore the same tool on her/his machine. This is very much similar to NuGet packages.

You can safely add this to .gitignore. In this case, your collegue will still be able to perform a fresh install of the same tool using dotnet tool install with same or different version.

Here is a good article on this topic

Caviness

I would suggest to always check in the dotnet-tools.json, and use "dotnet tool restore". Background: When you use tools like dotnet-format, test-reports-generation or other tools, they do may not exist on your environment, so may git hooks will fail. Calling local or global dotnet tools are different, so with dotnet-tools.json under source control you can "enforce" local usage and avoid polluting your system with global installations. Nice benefit: You see exactly which versions are you using inside the file. – Sagitta

Answer 2

Sometimes Visual Studio creates this file when you simply open the "publish" dialog without even touching any settings. Visual Studio tries to detect EF-migrations/DB-context/etc. in your project by running dotnet ef -blahblah; and for that it installs the ef tool; and because of that the install generates this file.

If you're not using Entity Framework not only you're safe to .gitignore this file, but you're safe to completely delete it after closing the "publish" settings dialog (again, if you're not using EF).

Periwinkle

Be aware that there are some other dotnet tools that a project can use. I have a project that is using a GraphQL client generator and a code formatter, for example. Remove the file if it has tools you really don't want associated with the project, but check first. I think in the long run you're better off checking this file in and maintaining it for consistency across the project. – Borehole