Tools on kenji.blog

A Guide to Building a Cross-Platform C++ Build Environment Using CMake

Sat, 12 Sep 2026 09:00:00 +0900

In C++ software development, choosing and setting up a “build system” has long been a source of frustration for many developers. Since C++ does not have an official standard package manager or build system, it was necessary to use different compilers and build tools (such as MSVC, GCC, Clang, Make, Ninja) depending on the platform (Windows, Linux, macOS).

However, CMake has now established itself as the de facto industry standard. By utilizing CMake correctly, you can elegantly construct a cross-platform build environment from a single CMakeLists.txt.

In this article, we will thoroughly and comprehensively explain the procedure for building a modern, cross-platform C++ build environment using CMake, from the basics to advanced techniques.

1. What is CMake? (The Concept of a Meta-Build System)

CMake itself is not a tool that compiles source code directly. CMake is a “system that generates a build system,” that is, a Meta-Build System.

The main role of CMake is to read abstract configuration files (CMakeLists.txt) that do not depend on platforms or compilers, and automatically generate native build scripts optimized for each environment (e.g., Makefile for Linux, Visual Studio .sln project files for Windows, or the fast build.ninja).

The following diagram illustrates the generation process of CMake.

graph TD A["CMakeLists.txt (Abstract Build Definition)"] --> B["CMake (Configure & Generate)"] B --> C["Unix Makefiles"] B --> D["Ninja Build Files"] B --> E["Visual Studio Solutions"] B --> F["Xcode Projects"] C --> G["Native Build Tool (make, ninja, MSBuild, xcodebuild)"] D --> G E --> G F --> G G --> H["Executable / Shared Library / Static Library"]

As seen here, by interposing CMake, developers can manage C++ projects without having to worry about the minor differences in commands for each OS.

2. Basics of Modern CMake: From Variables to Targets

The notation used in CMake 3.0 and later is called “Modern CMake,” and its design philosophy is fundamentally different from the earlier “Legacy CMake.” In Legacy CMake, the mainstream approach was to rewrite global variables on a per-directory basis (e.g., using include_directories() and link_libraries()), but this often caused severe side effects where settings unintentionally propagated to other modules.

In Modern CMake, everything is treated as Targets and Properties. It is similar to the relationship between classes and member variables in object-oriented programming.

Targets: Executables or Libraries.
Properties: The source files, include directories, compile options, other libraries to link against, etc., required to build that target.

By encapsulating (confining) settings only to specific targets, it becomes possible to define a safe build process that will not break down even in large-scale projects.

A Minimal `CMakeLists.txt`

First, let’s look at the most basic CMakeLists.txt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Specify the minimum required version of CMake
cmake_minimum_required(VERSION 3.20)

# Specify the project name and the language to use
project(MyAwesomeApp VERSION 1.0.0 LANGUAGES CXX)

# Request the C++ standard (C++20)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) # Disable compiler-specific extensions

# Define the executable target
add_executable(MyAwesomeApp main.cpp)

With just these few lines, the portable build settings for an executable file requiring C++20 and disabling compiler extensions are complete.

3. Dependencies and Scope: PUBLIC / PRIVATE / INTERFACE

The most important and difficult concept to master in Modern CMake is the three access modifiers (scopes): PUBLIC, PRIVATE, INTERFACE, used in commands like target_include_directories and target_link_libraries.

These are used to control whether a target’s properties (such as include paths or dependent libraries) are “needed for its own build” and whether they should be “propagated to other targets that depend on it”.

PRIVATE: Only needed for the target’s own build. Does not propagate to dependent targets.
INTERFACE: Not needed for the target’s own build, but does propagate to dependent targets (used in header-only libraries, etc.).
PUBLIC: Needed for the target’s own build, and does propagate to dependent targets (PRIVATE + INTERFACE).

Let’s visualize the propagation of dependencies (Usage Requirements) in the diagram below.

graph TD subgraph "Libraries" MathLib["MathLib (Static Library)"] NetworkLib["NetworkLib (Shared Library)"] HeaderLib["HeaderLib (Header Only)"] end subgraph "Application" App["Main Application"] end App -- "target_link_libraries(App PRIVATE MathLib)" --> MathLib App -- "target_link_libraries(App PUBLIC NetworkLib)" --> NetworkLib NetworkLib -- "target_link_libraries(NetworkLib INTERFACE HeaderLib)" --> HeaderLib note1["App depends on the implementation of MathLib, but does not expose it externally"] note2["NetworkLib exposes the interface of HeaderLib"]

Specific Use Cases of Scope

Suppose a library MyLib uses nlohmann/json as part of its internal implementation, but does not include nlohmann/json in its exposed header file MyLib.hpp. In this case, the user (application) of MyLib does not need to know about the existence of the JSON library.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Define the library
add_library(MyLib src/MyLib.cpp)

# Specify the include directories for the project
# The include directory is needed by those who use MyLib, so set it to PUBLIC
# The src directory is only used in MyLib's implementation, so set it to PRIVATE
target_include_directories(MyLib
 PUBLIC
 $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
 $<INSTALL_INTERFACE:include>
 PRIVATE
 ${CMAKE_CURRENT_SOURCE_DIR}/src
)

# The json library is only used internally, so link it as PRIVATE
target_link_libraries(MyLib PRIVATE nlohmann_json::nlohmann_json)

Conversely, if you write #include <nlohmann/json.hpp> in MyLib.hpp, the side using MyLib will encounter a compilation error unless they also know the JSON header path, so you need to link it as PUBLIC. By setting this scope appropriately, you can reduce build times and prevent the leakage of unnecessary dependencies (re-poisoning).

4. Out-of-source Build

A best practice that you must follow when using CMake is the Out-of-source Build. This is a method where you do not output any build artifacts (object files or executables) in the directory where the source code is located (the source tree), but rather isolate the build in a separate, dedicated directory (usually build/).

graph TD Root["Project Root (Git Repository)"] Root --> Src["src/"] Root --> Inc["include/"] Root --> CMake["CMakeLists.txt"] Root -. "Create build dir" .-> Build["build/ (Out-of-source)"] Build --> Obj["CMakeFiles/ (Object files, caches)"] Build --> Bin["Binaries (MyApp.exe)"] Build --> Gen["Generated Makefile / build.ninja"]

With this structure, if you want to reset the build environment, you simply delete the entire build directory, and since the source tree is not dirtied, Git management also becomes easier (just add build/ to .gitignore).

Steps to Execute a Build

With Modern CMake, you can execute a build using common commands that do not depend on the OS or build tool.

1
2
3
4
5
6
7
8


# 1. Configuration and generation (creating the build directory and setting it up)
cmake -S . -B build

# 2. Actual build (compilation and linking)
cmake --build build --config Release

# (Optional) Use the -j option to build with multiple threads
cmake --build build --config Release -j 8

Here, cmake -S . -B build means “Set the current directory (.) as the source directory, and build as the build directory.”

5. How to Introduce Third-Party Libraries

In C++ development, introducing external libraries (third-party libraries) has always been a high hurdle. However, nowadays, the following three approaches are standard.

5.1. find_package (Searching for System-Installed Libraries)

This is the most traditional method of finding and linking libraries already installed on the system (e.g., OpenSSL or Zlib).

1
2
3
4


find_package(ZLIB REQUIRED)
if(ZLIB_FOUND)
 target_link_libraries(MyAwesomeApp PRIVATE ZLIB::ZLIB)
endif()

5.2. FetchContent (Downloading and Incorporating from Source)

This module was introduced in CMake 3.11 and became more powerful in 3.14 and later. It downloads source code directly from an external Git repository or URL during the build and builds it together as part of the project. Since dependencies can be managed centrally, cross-platform reproducibility is extremely high.

Below is an example of introducing GoogleTest using FetchContent.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


include(FetchContent)

FetchContent_Declare(
 googletest
 GIT_REPOSITORY https://github.com/google/googletest.git
 GIT_TAG v1.14.0
)

# Incorporate the library into the project
FetchContent_MakeAvailable(googletest)

# Create and link the test executable
add_executable(MyTests test/main.cpp)
target_link_libraries(MyTests PRIVATE gtest_main)

5.3. Integration with vcpkg

Using vcpkg, a C++ package manager led by Microsoft, allows you to easily introduce thousands of libraries. vcpkg is designed to integrate seamlessly with CMake.

By simply specifying the vcpkg toolchain file when running CMake, find_package will automatically search for libraries within vcpkg.

1

cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=/path/to/vcpkg/scripts/buildsystems/vcpkg.cmake

Furthermore, by placing vcpkg.json (manifest mode) in the project root, you can fully automate the version control of the required libraries.

6. Compiler Flags for Cross-Platform Support

To successfully build in any environment, whether Windows (MSVC), Linux (GCC/Clang), or macOS (Apple Clang), you need to properly set compiler-specific flags.

By using CMake’s Generator Expressions, you can declaratively write conditional branching such as, “If the compiler is MSVC, use this flag; otherwise, use that flag.” Generator expressions use the syntax $<...> and are evaluated when the build system is generated (the Generate phase).

1
2
3
4
5
6
7
8


# Example of enabling the highest level of warnings on all platforms
target_compile_options(MyAwesomeApp PRIVATE
 # For MSVC
 $<$<CXX_COMPILER_ID:MSVC>:/W4 /WX>

 # For GCC or Clang
 $<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>,$<CXX_COMPILER_ID:AppleClang>>:-Wall -Wextra -Wpedantic -Werror>
)

By using this method, you can prevent CMakeLists.txt from becoming difficult to read due to heavy use of if(MSVC)-like conditionals, and allow for flexible configurations per target.

7. Setting up a Testing Environment (CTest)

Introducing automated testing is essential for quality assurance in a cross-platform environment. CMake comes standard with a test runner called CTest.

The procedure to integrate GoogleTest, introduced earlier via FetchContent, with CTest is as follows.

1
2
3
4
5
6
7
8
9


# Enable testing capabilities (written once in the root CMakeLists.txt)
enable_testing()

add_executable(MyMathTests test/math_test.cpp)
target_link_libraries(MyMathTests PRIVATE gtest_main MyLib)

# Register as a test in CTest
include(GoogleTest)
gtest_discover_tests(MyMathTests)

After building, you can simply run the ctest command in the build directory, and all tests will be executed and the results reported.

1
2


cd build
ctest --output-on-failure -C Release

8. Build System Theory and Mathematical Models

Let’s change our perspective slightly and consider the efficiency of build systems and parallel compilation in large-scale projects using a mathematical model.

Reducing build time (compilation time) is an eternal challenge in C++ development. You can reduce build time by splitting the source code and compiling it in parallel. The speed improvement (Speedup) achieved by this parallelization is modeled by Amdahl’s Law.

If the fraction of the program that can be parallelized is $P$, the fraction that must be executed sequentially (cannot be parallelized) is $1-P$, and the number of processors used is $N$, the overall theoretical maximum speedup factor $S(N)$ is expressed by the following formula:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

In the C++ build process, “compiling each .cpp file to .o or .obj” is independent and parallelizable (the $P$ part), but “the final combining process by the Linker” is basically executed sequentially (the $1-P$ part).

Therefore, no matter how many CPU cores you provide ($N \to \infty$), as long as the bottleneck of link time exists, the maximum speedup factor will asymptote to the following formula:

$$ \lim_{N \to \infty} S(N) = \frac{1}{1 - P} $$

What this formula suggests is that “simply increasing the number of CPU cores has a limit in reducing build time.” In Modern CMake, properly distinguishing between PRIVATE and INTERFACE, and minimizing header file dependencies (such as by utilizing forward declarations) to increase the proportion of $P$ and reduce the targets for recompilation during an incremental build, is practically the most effective strategy for speeding up builds.

Also, to reduce link time, it is important to switch from Static Libraries to Shared Libraries / DLLs, or to adopt a fast linker such as LLD or Mold.

In CMake, you can easily specify the linker as follows:

1
2
3
4


# Set to use the lld linker in a Clang/GCC environment
if(UNIX AND NOT APPLE)
 target_link_options(MyAwesomeApp PRIVATE "-fuse-ld=lld")
endif()

9. Practical Example of a Complex Directory Structure

In actual application development, the directory structure will be a combination of numerous modules. Finally, we show an ideal directory structure for a medium-sized project and the relationship between parent and child CMakeLists.txt files.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


ProjectRoot/
├── CMakeLists.txt (Root: Overall project definitions)
├── vcpkg.json (Dependency library definitions)
├── external/ (External modules)
├── include/ (Public headers)
│ └── myapp/
├── src/ (Source code and internal build definitions)
│ ├── CMakeLists.txt
│ ├── main.cpp
│ ├── math/
│ │ ├── CMakeLists.txt
│ │ ├── Vector3.hpp
│ │ └── Vector3.cpp
│ └── network/
│ ├── CMakeLists.txt
│ └── NetworkManager.cpp
└── tests/ (Test code)
 ├── CMakeLists.txt
 └── math_test.cpp

The root CMakeLists.txt only performs environment settings and overall option definitions, and adds subdirectories using add_subdirectory().

Root CMakeLists.txt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cmake_minimum_required(VERSION 3.20)
project(ComplexApp LANGUAGES CXX)

# Global settings
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# Enable testing
enable_testing()

# Add subdirectories
add_subdirectory(src)
add_subdirectory(tests)

src/CMakeLists.txt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Add each module
add_subdirectory(math)
add_subdirectory(network)

# Final executable
add_executable(ComplexApp main.cpp)

# Link modules
target_link_libraries(ComplexApp
 PRIVATE
 MathLib
 NetworkLib
)

By splitting the CMakeLists.txt for each directory in this way and defining them as dependencies between targets, the reusability of modules increases, and the build parallelization also improves. This is the true worth of the “modular build environment” advocated by Modern CMake.

10. Conclusion

We have explained the procedure for building a cross-platform C++ build environment using CMake. Let’s review the key points.

Understanding the Meta-Build System: CMake is a tool for generating build scripts.
Commitment to Modern CMake: Avoid using variables, and encapsulate settings in a target-oriented manner using add_executable, target_link_libraries, target_include_directories, etc.
Appropriate Scope Settings: Properly distinguish between PUBLIC, PRIVATE, and INTERFACE to control the propagation of dependencies.
Strict Use of Out-of-source Builds: Perform builds inside the build/ directory so as not to dirty the source tree.
Third-Party Integration: Fully utilize FetchContent and vcpkg to automate the resolution of dependency libraries.
Utilization of Generator Expressions: Smartly absorb differences in flags across compilers.
Mathematical Approach: Be mindful of Amdahl’s Law, reduce dependencies, and increase the efficiency of parallel compilation.

CMake might seem difficult to understand at first, but once you grasp the concepts of targets and properties, you will be able to maintain a well-organized build environment, no matter how complex or large your C++ project may be. We hope you will use this article as a reference to construct your C++ development environment using the latest Modern CMake notation.

Easy with vcpkg! How to Install OpenSSL-compatible libcurl in Visual Studio

Mon, 07 Jul 2025 21:46:08 +0900

For using libcurl (with OpenSSL support) in Visual Studio, vcpkg is easy and recommended

When you want to handle HTTP communication in C++, libcurl is often used. However, adjusting builds and dependencies can be unexpectedly troublesome, right?

In such cases, the Microsoft-made C++ library management tool “vcpkg” is very useful. This time, we will introduce the steps from introducing libcurl (with OpenSSL support) using vcpkg to making it smooth to use in Visual Studio.

Installing vcpkg (Only for those who haven’t installed it yet)

First, let’s install vcpkg. Please run the following steps in PowerShell.

1
2
3


git clone https://github.com/microsoft/vcpkg
cd vcpkg
.\bootstrap-vcpkg.bat

If Git is not installed yet, please install it from the Git official website.

Installing libcurl (with OpenSSL support)

Next, we will use vcpkg to install libcurl. To specify the 64bit version with OpenSSL support, run the following command.

1

vcpkg install curl[ssl] --triplet x64-windows

When this command is run, necessary dependencies (such as OpenSSL) are also set up automatically.

Integration settings with Visual Studio

To easily use the library introduced by vcpkg from a Visual Studio project, configure the integration setting with the following command.

1

vcpkg integrate install

By doing this setting, #include <curl/curl.h> can be automatically used in Visual Studio projects, eliminating the need to manually set up library paths and linker settings.

Conclusion

With this, the preparation to introduce libcurl (with OpenSSL support) into Visual Studio is complete.

With vcpkg, troublesome dependencies can be managed all at once.
Easily introduce libcurl with vcpkg install curl[ssl] --triplet x64-windows
Automatic integration with Visual Studio is possible with vcpkg integrate install

After this, just include the header in your project and start developing using the libcurl API. Please utilize the convenient vcpkg and dramatically increase your development efficiency.

How to Undo an Accidentally Executed git reset | Commit Restoration Steps

Wed, 15 May 2024 23:32:43 +0900

How to undo git reset

If you accidentally run git reset after making a git commit, here is how to undo the git reset (restore the state at the time of the git commit).

Check the commit ID before the reset with git reflog
Revert to the state before the reset with git reset --hard HEAD@{number}

That’s how to undo a git reset.

How to Dynamically Set Environment Variables in GitHub Actions [Windows Environment]

Sun, 02 Oct 2022 02:33:35 +0900

To dynamically set variables in Github Actions, you can achieve this by appending to $GITHUB_ENV as shown below.

[For Windows]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


name: Rust

on:
 push:
 branches: [ "master" ]
 pull_request:
 branches: [ "master" ]

env:
 CARGO_TERM_COLOR: always

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Get Environment
 run: |
 echo 'VERSION=1.0.0' >> $GITHUB_ENV
 echo 'NAME=1.0.0' >> $GITHUB_ENV
 - name: Display Environment
 run: |
 echo $env:VERSION
 echo $env:NAME
 - name: Create Release
 id: create_release
 uses: actions/create-release@v1
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 with:
 tag_name: ${{ env.VERSION }}
 release_name: ${{ env.VERSION }}
 draft: false
 prerelease: false
 - name: Upload Release Asset
 id: upload-release-asset
 uses: actions/upload-release-asset@v1
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 with:
 upload_url: ${{ steps.create_release.outputs.upload_url }} # This pulls from the CREATE RELEASE step above, referencing it's ID to get its outputs object, which include a `upload_url`. See this blog post for more info: https://jasonet.co/posts/new-features-of-github-actions/#passing-data-to-future-steps
 asset_path: ./target/release/${{ env.NAME }}.exe
 asset_name: ${{ env.NAME }}.exe
 asset_content_type: application/octet-stream

[For Linux]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


name: Rust

on:
 push:
 branches: [ "main" ]
 pull_request:
 branches: [ "main" ]

env:
 CARGO_TERM_COLOR: always

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Get Environment
 run: |
 echo 'VERSION=1.0.0' >> $GITHUB_ENV
 echo 'NAME=hello' >> $GITHUB_ENV
 - name: Display Environment
 run: |
 echo ${{ env.VERSION }}
 echo ${{ env.NAME }}

How to Easily Generate .gitignore for Projects using the dotnet Command

Tue, 13 Sep 2022 00:25:12 +0900

Since the dotnet.exe command can even build simple programs, it is useful to know how to use it.

Installing the .NET SDK

dotnet.exe is included in the .NET SDK, so we will install the .NET SDK first. Launch cmd.exe with administrator privileges and run the following command:

1

winget install Microsoft.DotNet.SDK.6

Generating .gitignore

The command to generate a .gitignore using dotnet.exe is as follows:

1

dotnet new gitignore

The generated .gitignore is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454


## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.
##
## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

# User-specific files
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates

# User-specific files (MonoDevelop/Xamarin Studio)
*.userprefs

# Mono auto generated files
mono_crash.*

# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
[Ww][Ii][Nn]32/
[Aa][Rr][Mm]/
[Aa][Rr][Mm]64/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/
[Ll]ogs/

# Visual Studio 2015/2017 cache/options directory
.vs/
# Uncomment if you have tasks that create the project's static files in wwwroot
#wwwroot/

# Visual Studio 2017 auto generated files
Generated\ Files/

# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*

# NUnit
*.VisualState.xml
TestResult.xml
nunit-*.xml

# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c

# Benchmark Results
BenchmarkDotNet.Artifacts/

# .NET
project.lock.json
project.fragment.lock.json
artifacts/

# Tye
.tye/

# ASP.NET Scaffolding
ScaffoldingReadMe.txt

# StyleCop
StyleCopReport.xml

# Files built by Visual Studio
*_i.c
*_p.c
*_h.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*_wpftmp.csproj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc

# Chutzpah Test files
_Chutzpah*

# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opendb
*.opensdf
*.sdf
*.cachefile
*.VC.db
*.VC.VC.opendb

# Visual Studio profiler
*.psess
*.vsp
*.vspx
*.sap

# Visual Studio Trace Files
*.e2e

# TFS 2012 Local Workspace
$tf/

# Guidance Automation Toolkit
*.gpState

# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

# TeamCity is a build add-in
_TeamCity*

# DotCover is a Code Coverage Tool
*.dotCover

# AxoCover is a Code Coverage Tool
.axoCover/*
!.axoCover/settings.json

# Coverlet is a free, cross platform Code Coverage Tool
coverage*.json
coverage*.xml
coverage*.info

# Visual Studio code coverage results
*.coverage
*.coveragexml

# NCrunch
_NCrunch_*
.*crunch*.local.xml
nCrunchTemp_*

# MightyMoose
*.mm.*
AutoTest.Net/

# Web workbench (sass)
.sass-cache/

# Installshield output folder
[Ee]xpress/

# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html

# Click-Once directory
publish/

# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
# Note: Comment the next line if you want to checkin your web deploy settings,
# but database connection strings (with potential passwords) will be unencrypted
*.pubxml
*.publishproj

# Microsoft Azure Web App publish settings. Comment the next line if you want to
# checkin your Azure Web App publish settings, but sensitive information contained
# in these scripts will be unencrypted
PublishScripts/

# NuGet Packages
*.nupkg
# NuGet Symbol Packages
*.snupkg
# The packages folder can be ignored because of Package Restore
**/[Pp]ackages/*
# except build/, which is used as an MSBuild target.
!**/[Pp]ackages/build/
# Uncomment if necessary however generally it will be regenerated when needed
#!**/[Pp]ackages/repositories.config
# NuGet v3's project.json files produces more ignorable files
*.nuget.props
*.nuget.targets

# Microsoft Azure Build Output
csx/
*.build.csdef

# Microsoft Azure Emulator
ecf/
rcf/

# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx
*.appxbundle
*.appxupload

# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!?*.[Cc]ache/

# Others
ClientBin/
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.jfm
*.pfx
*.publishsettings
orleans.codegen.cs

# Including strong name files can present a security risk
# (https://github.com/github/gitignore/pull/2483#issue-259490424)
#*.snk

# Since there are multiple workflows, uncomment next line to ignore bower_components
# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622)
#bower_components/

# RIA/Silverlight projects
Generated_Code/

# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm
ServiceFabricBackup/
*.rptproj.bak

# SQL Server files
*.mdf
*.ldf
*.ndf

# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings
*.rptproj.rsuser
*- [Bb]ackup.rdl
*- [Bb]ackup ([0-9]).rdl
*- [Bb]ackup ([0-9][0-9]).rdl

# Microsoft Fakes
FakesAssemblies/

# GhostDoc plugin setting file
*.GhostDoc.xml

# Node.js Tools for Visual Studio
.ntvs_analysis.dat
node_modules/

# Visual Studio 6 build log
*.plg

# Visual Studio 6 workspace options file
*.opt

# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
*.vbw

# Visual Studio LightSwitch build output
**/*.HTMLClient/GeneratedArtifacts
**/*.DesktopClient/GeneratedArtifacts
**/*.DesktopClient/ModelManifest.xml
**/*.Server/GeneratedArtifacts
**/*.Server/ModelManifest.xml
_Pvt_Extensions

# Paket dependency manager
.paket/paket.exe
paket-files/

# FAKE - F# Make
.fake/

# CodeRush personal settings
.cr/personal

# Python Tools for Visual Studio (PTVS)
__pycache__/
*.pyc

# Cake - Uncomment if you are using it
# tools/**
# !tools/packages.config

# Tabs Studio
*.tss

# Telerik's JustMock configuration file
*.jmconfig

# BizTalk build output
*.btp.cs
*.btm.cs
*.odx.cs
*.xsd.cs

# OpenCover UI analysis results
OpenCover/

# Azure Stream Analytics local run output
ASALocalRun/

# MSBuild Binary and Structured Log
*.binlog

# NVidia Nsight GPU debugger configuration file
*.nvuser

# MFractors (Xamarin productivity tool) working folder
.mfractor/

# Local History for Visual Studio
.localhistory/

# BeatPulse healthcheck temp database
healthchecksdb

# Backup folder for Package Reference Convert tool in Visual Studio 2017
MigrationBackup/

# Ionide (cross platform F# VS Code tools) working folder
.ionide/

# Fody - auto-generated XML schema
FodyWeavers.xsd

##
## Visual studio for Mac
##


# globs
Makefile.in
*.userprefs
*.usertasks
config.make
config.status
aclocal.m4
install-sh
autom4te.cache/
*.tar.gz
tarballs/
test-results/

# Mac bundle stuff
*.dmg
*.app

# content below from: https://github.com/github/gitignore/blob/master/Global/macOS.gitignore
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

# content below from: https://github.com/github/gitignore/blob/master/Global/Windows.gitignore
# Windows thumbnail cache files
Thumbs.db
ehthumbs.db
ehthumbs_vista.db

# Dump file
*.stackdump

# Folder config file
[Dd]esktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows shortcuts
*.lnk

# JetBrains Rider
.idea/
*.sln.iml

##
## Visual Studio Code
##
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

Although it contains many files for Visual Studio, it also includes files that generally do not need to be managed on git, such as .DS_Store on Mac.

Reference Sites

Install .NET on Windows