Ignoring `launchSettings.json` does not make much sense. Now .NET CLI even considers this file when running with `dotnet run`, as you can read [here](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-run?tabs=netcore2x).
This settings will be useful if shared among project members, so it should be commited to the repo.
Also, on the default `.gitignore` file generated by Visual Studio it is not ignored, so this causes confusion, as depending on how `.gitignore` was created it could be commited in or not.
MFractor is a Xamarin/Visual Studio Mac productivity tool used by 1000's of Xamarin developers.
The `.mfractor/` folder should not be included in source control (but often is).
Nobody is using v1 of typings anymore on new projects and 'typings' is the recommended name for the folders of your custom types.
On the other hand the official Visual Studio ignore is not ignoring this folder.
The latest update of Visual Studio 17 (15.5.5) introduces a new backup folder called "ServiceFabricBackup" before upgrading service fabric applications.
* Add *.snk strong name key files
Strong name key files shouldn't be included in a repository AFAIK. they are intended to sign build output to verify that it comes from the correct publisher. having an *.snk in a repository would allow anyone to produce build as if they were the original publisher.
I guess some OSS projects might like to have *.snk files in their repos but that would be an exception to the rule.
* Make use of *.snk optional
Add note explaining use.
* Reduce explanation
Just use a link instead
It looks like VS2017 changed it's nuget package directory name to be capitalized.
When using Ubuntu for Windows, directory name casing of NuGet package folder becomes important and detected as a change by git,. This change is to ignore regardless of casing.
AxoCover is a Code Coverage Tool. It creates a **.axoCover** folder where are created:
- settings in settings.json
- sub-folders into **run** folder which contain code coverage results.
All content into **.axoCover** folder must be ignored except the **settings.json** file.
- It is recommended to include the packages.config file when using Cake
- This ensures that the Cake version that is being used is *pinned* and updated only when the user decides
.jfm files have started blocking checking for .sqlproj projects in Visual Studio. .jfm files are a new file-type created by the Microsoft ESENT database engine - this is a recent improvement only in Windows 10 Anniversary update. As the SSDT .sqlproj type in Visual Studio uses this engine for .dbmdl metadata files, and this file is locked by the user, this currently blocks users from checking into Git repositories.
This fix helps mitigate this by avoiding checkin of this file type.
I've just upgraded to ASP.NET Core RC2, and I've found that Visual
Studio is producing a file called project.fragment.lock.json. When I
delete the file it is recreated during build. Given project.lock.json is
already ignored this looks like another file to ignore.
Commit a25589c921 introduced an ignore line for ApplicationInsights.config. This change breaks builds on certain systems, namely VSTS.
The current ASP.NET 4 template adds ApplicationInsights.config to the project's .csproj file. When VSTS attempts to build the project, it will fail if it cannot find ApplicationInsights.config.
ApplicationInsights.config is a required application file and should not be ignored.
The authoring of NuGet packages quite often include `build` folders, and when this is .gitignore'd it's very often the source of bugs in files that don't get checked in.
I've never seen a Visual Studio project that builds to a `build` folder (`bin` is the default name). As this is a Visual Studio template file, and we have real projects that include `build` folders that include source code, I recommend we remove suppression of this folder.
StyleCop.Analyzers is the modern re-invention of StyleCop, and uses a StyleCop.json file that the default .gitignore file made very difficult to check in, and easy to think was checked in but isn't.
See 32057fff82/documentation/Configuration.md (source-control) for the documented case.
Looking through history, this line was last touched to make it case insensitive, and before that the line was in the original VisualStudio.gitignore file, without justification for why it should ignore all file extensions. From my experience with stylecop, the only file I remember it creating was stylecop.cache. I would change `[Ss]tyle[Cc]op.*` to `[Ss]tyle[Cc]op.cache` but there is already a line for suppressing all *.cache files (which wasn't there when the stylecop line was originally added). So I believe this line is now obsolete, and as I explain above, actually problematic.
Added extensions of new database engine for C++ (sqlite-based) from
Visual Studio 2015
(Tools - Options - Text Editor - C/C++ - Experimental - Enable New
Database Engine)
Ignoring directory "efc" and "rfc" created by the Windows Azure Emulator
Directory before starting emulator the first time:
Directory: C:\temp\AzureCloudService1\AzureCloudService1
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 9/1/2015 9:16 AM bin
d----- 9/1/2015 9:16 AM WorkerRole1Content
-a---- 9/1/2015 9:16 AM 3014 AzureCloudService1.ccproj
-a---- 9/1/2015 9:16 AM 144 AzureCloudService1.ccproj.user
-a---- 9/1/2015 9:16 AM 505 ServiceConfiguration.Cloud.cscfg
-a---- 9/1/2015 9:16 AM 505 ServiceConfiguration.Local.cscfg
-a---- 9/1/2015 9:16 AM 428 ServiceDefinition.csdef
And after starting the Emulator:
Directory: C:\temp\AzureCloudService1\AzureCloudService1
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 9/1/2015 9:16 AM bin
d----- 9/1/2015 9:19 AM csx
d----- 9/1/2015 9:19 AM ecf
d----- 9/1/2015 9:19 AM obj
d----- 9/1/2015 9:19 AM rcf
d----- 9/1/2015 9:16 AM WorkerRole1Content
-a---- 9/1/2015 9:16 AM 3014 AzureCloudService1.ccproj
-a---- 9/1/2015 9:16 AM 144 AzureCloudService1.ccproj.user
-a---- 9/1/2015 9:16 AM 505 ServiceConfiguration.Cloud.cscfg
-a---- 9/1/2015 9:16 AM 505 ServiceConfiguration.Local.cscfg
-a---- 9/1/2015 9:16 AM 428 ServiceDefinition.csdef
In Windows Phone 8 development each profiler session generates a new .sap file, which is automatically added to the root of the project. This is an XML manifest describing the detailed profiler logs created in the PerfLogs folder.
Matthias Schäfer