Skip to content

Commit 52da36d

Browse files
TaojunshenMugBergerFriesbradlitterellopbld17colin-home
authored
9/22/2022 AM Publish (#4536)
* Updated C6101 Mirror of my public PR. Added an example. Added proper spacing between headers and code blocks, matched formatting to my other PRs * Updated C6101 Minor changes in response to Acrolinx report * Updated C6101 More Acrolinx changes, split a run-on sentence * Updated C26495 Matched formatting to my other PRs. Added more information to the example. * Updated C26495 Fixed spelling error * Updated C6101 Updated to the latest format * Updated C6101 Single backticks and InOut->Inout * Updated C26495 Updated to the new format NOTE: This warning has no code analysis name. Per @MichaelSquires instructions, I omitted the usual keywords and 'Code analysis name:' section to match * Update compiler-warning-level-4-c4464.md @corob-msft proposal. I don't warrant it shouldn't be worded in a better way. * Update compiler-warning-level-4-c4464.md typo fix * fix: delete unnecessary asterisk followup fix of MicrosoftDocs#4136 * optimize prime test * Update floating-point-support.md Explain what "ulp" stands for * Updates for cpp-docs 4161 * Update integritycheck-require-signature-check.md * alt-text * Update abstract-cpp-component-extensions.md * Add syntax highlighting to atl-mfc-shared * Updated C26495 Added code analysis ID * alt-text updates * customer fix * minor updates * Incorporate changes in rewrite Updates for style and clarity. Also give it an Acrolinx pass. * Clarify version support * Tweak language for minimum support * Add code style, comment @MugBergerFries It's a good idea to use code styling for mentions of variable or class names (especially when they're easily confused generic names like "value"). I also added a comment to the fixed code sample to amplify the change and what it was doing. * acrolinx * cleanup pass * [BULK] DocuTune - Rebranding * alt-text updates * update alt-text * Update README.md * Address cpp-docs 4149 __umulh on ARM64 * Add slashes per cpp-docs 4150 * update alt-text code and removed 'experimental' from images * Update clang-support-msbuild.md Updated for better visibility of LLVMToolsVersion property. Note the text was also misleading because it kind of implies that LLVMToolsVersion supports side-by-side version of clang/LLVM in the same `LLVMInstallDir`, but that's not how clang/LLVM works. If you want to select a different version, you need to point it to a different path. * test fix * test fix * test fix * alt-text updates plus acrolinx * acrolinx * Split props file and IDE sections When both path and version are merged in the .props file discussion, a division between the .props approach and the IDE approach seems more natural than repeating the same content twice. * Update to add /std requirement * Test of build checks features * Update cpp-linter-overview.md * Provide F1 links to articles for VS linker properties (#4529) * Update F1 links for Linker Properties * F1 Project: Linker Properties part 1 * Finish Linker properties F1 links * Fix typo * Fix acrolinx related issues Co-authored-by: Samuel Berger <sjamesberger@gmail.com> Co-authored-by: Brad Litterell <49081806+bradlitterell@users.noreply.github.com> Co-authored-by: opbld17 <opbld17@microsoft.com> Co-authored-by: Colin Robertson <3836425+corob-msft@users.noreply.github.com> Co-authored-by: opbld16 <opbld16@microsoft.com> Co-authored-by: Kisaragi <48310258+KisaragiEffective@users.noreply.github.com> Co-authored-by: Courtney Wales <62625502+Court72@users.noreply.github.com> Co-authored-by: opbld15 <opbld15@microsoft.com> Co-authored-by: TylerMSFT <Tyler.Whitney@microsoft.com> Co-authored-by: Bryan Gold <101299717+19BMG00@users.noreply.github.com> Co-authored-by: Edward Breeveld <42862235+EddieBreeveld@users.noreply.github.com> Co-authored-by: Jeff Borsecnik <36546697+jborsecnik@users.noreply.github.com> Co-authored-by: jsuther1974 <jsuther@microsoft.com> Co-authored-by: Austin Morton <apmorton@users.noreply.github.com> Co-authored-by: Jak Koke <v-jokoke@microsoft.com> Co-authored-by: HO-COOH <42881734+HO-COOH@users.noreply.github.com> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: James Barnett <v-jabarnett@microsoft.com> Co-authored-by: Dennis Rea <v-denrea@microsoft.com> Co-authored-by: Alex Buck <abuck@microsoft.com> Co-authored-by: Tyler Whitney <tylerw6502@gmail.com> Co-authored-by: Feng Xu <fenxu@microsoft.com> Co-authored-by: Chuck Walbourn <walbourn@users.noreply.github.com> Co-authored-by: Colin Cooper <72402153+v-ccolin@users.noreply.github.com>
1 parent 481e25c commit 52da36d

File tree

43 files changed

+622
-581
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

43 files changed

+622
-581
lines changed

‎docs/build/clang-support-msbuild.md‎

Lines changed: 13 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,31 +1,31 @@
11
---
22
description: "Learn more about: Clang/LLVM support in Visual Studio projects"
33
title: "Clang/LLVM support in Visual Studio projects"
4-
ms.date: 06/29/2022
4+
ms.date: 09/20/2022
55
ms.description: "Configure a Visual Studio MSBuild project to use the Clang/LLVM toolchain."
66
helpviewer_keywords: ["Clang support for C++ MSBuild projects"]
77
---
88
# Clang/LLVM support in Visual Studio projects
99

1010
::: moniker range="<=msvc-150"
1111

12-
Clang support for both CMake and MSBuild projects is available in Visual Studio 2019.
12+
Clang/LLVM support for both CMake and MSBuild projects is available in Visual Studio 2019 and Visual Studio 2022.
1313

1414
::: moniker-end
1515

1616
::: moniker range=">=msvc-160"
1717

18-
You can use Visual Studio 2019 version 16.2 and later with Clang to edit, build, and debug C++ Visual Studio projects (MSBuild) that target Windows or Linux.
18+
You can use Visual Studio 2019 version 16.2 and later with Clang/LLVM to edit, build, and debug C++ Visual Studio projects (MSBuild) that target Windows or Linux.
1919

2020
## Install
2121

22-
For best IDE support in Visual Studio, we recommend using the latest Clang compiler tools for Windows. If you don't already have the tools, you can install them by opening the Visual Studio Installer and choosing **C++ Clang tools for Windows** under **Desktop development with C++** optional components. You may prefer to use an existing Clang installation on your machine; if so, choose **C++ Clang-cl for v142 build tools**.
22+
For best IDE support in Visual Studio, we recommend using the latest Clang compiler tools for Windows. If you don't already have the tools, you can install them by opening the Visual Studio Installer and choosing **C++ Clang tools for Windows** under **Desktop development with C++** optional components. You may prefer to use an existing Clang installation on your machine; if so, choose **C++ Clang-cl for v142 build tools** or **C++ Clang-cl for v143 build tools**.
2323

2424
The Microsoft C++ Standard Library requires at least Clang 8.0.0.
2525

2626
![Screenshot of the Visual Studio installer with the Individual components tab selected and the C plus plus Clang components visible.](media/clang-install-vs2019.png)
2727

28-
Later versions of Visual Studio provide newer versions of the Clang toolset. The bundled version of Clang gets updated automatically to stay current with updates in the Microsoft implementation of the Standard Library. For example, Visual Studio 2019 version 16.9 includes Clang v11.
28+
Later versions of Visual Studio provide newer versions of the Clang toolset. The bundled version of Clang gets updated automatically to stay current with updates in the Microsoft implementation of the Standard Library. For example, Visual Studio 2019 version 16.11 includes Clang v12.
2929

3030
## Configure a Windows project to use Clang tools
3131

@@ -52,58 +52,36 @@ To configure a Visual Studio Linux project to use Clang:
5252

5353
On Linux, Visual Studio by default uses the first Clang location that it finds in the PATH environment property. If you're using a custom Clang installation, then either change the value of the `LLVMInstallDir` property or else enter the path under **Project** > **Properties** > **Configuration Properties** > **VC++ DIrectories** > **Executable Directories**. For more information, see [Set a custom LLVM location](#custom_llvm_location).
5454

55-
## <a name="custom_llvm_location"></a> Set a custom LLVM location
55+
## <a name="custom_llvm_location"></a> Set a custom LLVM location and toolset
5656

57-
You can set a custom path to LLVM for one or more projects by creating a *Directory.build.props* file. Then, add that file to the root folder of any project. You can add it to the root solution folder to apply it to all projects in the solution. The file should look like this (but use your actual LLVM path):
57+
To set a custom path to LLVM and set a custom LLVM toolset version for one or more projects, create a *Directory.build.props* file. Then, add that file to the root folder of any project. You can add it to the root solution folder to apply it to all projects in the solution. The file should look like this example (but use your actual LLVM path and version number):
5858

5959
```xml
6060
<Project>
6161
<PropertyGroup>
6262
<LLVMInstallDir>C:\MyLLVMRootDir</LLVMInstallDir>
63+
<LLVMToolsVersion>15.0.0</LLVMToolsVersion>
6364
</PropertyGroup>
6465
</Project>
6566
```
6667

67-
You can combine this property with a custom LLVM toolset version. For more information, see [Set a custom LLVM toolset version](#custom_llvm_toolset).
68+
## <a name="custom_llvm_toolset"></a> Set a custom LLVM toolset version in the IDE
6869

69-
## <a name="custom_llvm_toolset"></a> Set a custom LLVM toolset version
70+
Starting in Visual Studio 2019 version 16.9, you can set a custom toolset version for LLVM in Visual Studio. To set this property in a project:
7071

71-
Starting in Visual Studio 2019 version 16.9, you can set a custom toolset version for LLVM. To set this property in a project in Visual Studio:
72-
73-
1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](./working-with-project-properties.md).
72+
1. Open the project's **Property Pages** dialog box. For more information, see [Set C++ compiler and build properties](./working-with-project-properties.md).
7473

7574
1. Select the **Configuration Properties** > **General** property page.
7675

77-
1. Modify the **Platform Toolset** property to *LLVM (clang-cl)*, if it isn't already set.
76+
1. Modify the **Platform Toolset** property to *LLVM (clang-cl)*, if it isn't already set. Choose **Apply** to save your changes.
7877

7978
1. Select the **Configuration Properties** > **Advanced** property page.
8079

8180
1. Modify the **LLVM Toolset Version** property to your preferred version, and then choose **OK** to save your changes.
8281

8382
The **LLVM Toolset Version** property only appears when the LLVM platform toolset is selected.
8483

85-
You can set the toolset version for one or more projects by creating a *Directory.build.props* file. Then, add that file to the root folder of any project. Add it to the root solution folder to apply it to all projects in the solution. The file should look like this (but use your actual LLVM path):
86-
87-
```xml
88-
<Project>
89-
<PropertyGroup>
90-
<LLVMToolsVersion>11.0.0</LLVMToolsVersion>
91-
</PropertyGroup>
92-
</Project>
93-
```
94-
95-
You can also combine this property with a custom LLVM location. For example, your *Directory.build.props* file could look like:
96-
97-
```xml
98-
<Project>
99-
<PropertyGroup>
100-
<LLVMInstallDir>C:\MyLLVMRootDir</LLVMInstallDir>
101-
<LLVMToolsVersion>11.0.0</LLVMToolsVersion>
102-
</PropertyGroup>
103-
</Project>
104-
```
105-
106-
When you add a *Directory.build.props* file, the settings appear as the default in the project Property Pages dialog. However, changes to these properties in Visual Studio override the settings in the *Directory.build.props* file.
84+
When you add a *Directory.build.props* file to a project or solution, the settings appear as the default in the project Property Pages dialog. However, changes to these properties in Visual Studio override the settings in the *Directory.build.props* file.
10785

10886
## Set additional properties, edit, build, and debug
10987

‎docs/build/reference/cetcompat.md‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2,12 +2,12 @@
22
description: "Learn more about: /CETCOMPAT (CET Shadow Stack compatible)"
33
title: "/CETCOMPAT (CET Shadow Stack compatible)"
44
ms.date: 09/22/2021
5-
f1_keywords: ["/CETCOMPAT"]
5+
f1_keywords: ["VC.Project.VCLinkerTool.CETCompat", "/CETCOMPAT"]
66
helpviewer_keywords: ["/CETCOMPAT linker option", "/CETCOMPAT"]
77
---
8-
# /CETCOMPAT (CET Shadow Stack compatible)
8+
# `/CETCOMPAT` (CET Shadow Stack compatible)
99

10-
Specifies whether to mark an executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack.
10+
Specifies whether the linker marks an executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack.
1111

1212
## Syntax
1313

@@ -21,7 +21,7 @@ Specifies that the executable shouldn't be marked compatible with CET Shadow Sta
2121

2222
## Remarks
2323

24-
Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature. It provides capabilities to defend against return-oriented programming (ROP) based malware attacks. For more information, see [A Technical Look at Intel’s Control-flow Enforcement Technology](https://software.intel.com/content/www/us/en/develop/articles/technical-look-control-flow-enforcement-technology.html).
24+
Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature. It provides capabilities to defend against return-oriented programming (ROP) based malware attacks. For more information, see [A Technical Look at Intel's Control-flow Enforcement Technology](https://software.intel.com/content/www/us/en/develop/articles/technical-look-control-flow-enforcement-technology.html).
2525

2626
The **`/CETCOMPAT`** linker option tells the linker to mark the binary as CET Shadow Stack-compatible. **`/CETCOMPAT:NO`** marks the binary as not compatible with CET Shadow Stack. If both options are specified on the command line, the last one specified is used. This switch is currently only applicable to x86 and x64 architectures.
2727

@@ -31,7 +31,7 @@ The **`/CETCOMPAT`** option is available beginning in Visual Studio 2019.
3131

3232
Starting in Visual Studio 2019 version 16.7:
3333

34-
1. Open the **Property Pages** dialog box for the project. For more information, see [Working with Project Properties](../working-with-project-properties.md).
34+
1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
3535

3636
1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
3737

@@ -41,7 +41,7 @@ Starting in Visual Studio 2019 version 16.7:
4141

4242
In previous versions of Visual Studio 2019:
4343

44-
1. Open the **Property Pages** dialog box for the project. For more information, see [Working with Project Properties](../working-with-project-properties.md).
44+
1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
4545

4646
1. Select the **Configuration Properties** > **Linker** > **Command Line** property page.
4747

‎docs/build/reference/clrsupportlasterror-preserve-last-error-code-for-pinvoke-calls.md‎

Lines changed: 17 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,39 +1,39 @@
11
---
22
description: "Learn more about: /CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)"
33
title: "/CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)"
4-
ms.date: "11/04/2016"
5-
f1_keywords: ["/CLRSUPPORTLASTERROR"]
4+
ms.date: 09/19/2022
5+
f1_keywords: ["VC.Project.VCLinkerTool.CLRSupportLastError", "/CLRSUPPORTLASTERROR"]
66
helpviewer_keywords: ["/CLRSUPPORTLASTERROR linker option", "-CLRSUPPORTLASTERROR linker option"]
77
ms.assetid: b7057990-4154-4b1d-9fc9-6236f7be7575
88
---
9-
# /CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)
9+
# `/CLRSUPPORTLASTERROR` (Preserve Last Error Code for PInvoke Calls)
1010

11-
**/CLRSUPPORTLASTERROR**, which is on by default, preserves the last error code of functions called through the P/Invoke mechanism, which allows you to call native functions in DLLS, from code compiled with **/clr**.
11+
**`/CLRSUPPORTLASTERROR`**, which is on by default, preserves the last error code of functions called through the P/Invoke mechanism, which allows you to call native functions in DLLS, from code compiled with **`/clr`**.
1212

1313
## Syntax
1414

15-
```
16-
/CLRSUPPORTLASTERROR{:NO | SYSTEMDLL}
17-
```
15+
> **`/CLRSUPPORTLASTERROR`**\
16+
> **`/CLRSUPPORTLASTERROR:NO`**\
17+
> **`/CLRSUPPORTLASTERROR:SYSTEMDLL`**
1818
1919
## Remarks
2020

21-
Preserving the last error code implies a decrease in performance. If you do not want to incur the performance impact of preserving the last error code, link with **/CLRSUPPORTLASTERROR:NO**.
21+
Preserving the last error code implies a decrease in performance. If you don't want to incur the performance cost of preserving the last error code, link by using **`/CLRSUPPORTLASTERROR:NO`**.
2222

23-
You can minimize the performance impact by linking with **/CLRSUPPORTLASTERROR:SYSTEMDLL**, which only preserves the last error code for functions in system DLLs.
23+
You can minimize the performance penalty by linking with **`/CLRSUPPORTLASTERROR:SYSTEMDLL`**, which only preserves the last error code for functions in system DLLs.
2424

2525
> [!NOTE]
26-
> Preserving the last error is not supported for unmanaged functions that are consumed by CLR code, in the same module.
26+
> Preserving the last error isn't supported for unmanaged functions that are consumed by CLR code in the same module.
2727
28-
- For more information, see [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md).
28+
- For more information, see [`/clr` (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md).
2929

3030
### To set this linker option in the Visual Studio development environment
3131

32-
1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](../working-with-project-properties.md).
32+
1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
3333

34-
1. Select the **Configuration Properties** > **Linker** > **Command Line** property page.
34+
1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
3535

36-
1. Enter the option into the **Additional Options** box.
36+
1. Modify the **Preserve Last Error Code for PInvoke Calls** property. Choose **OK** or **Apply** to save your changes.
3737

3838
### To set this linker option programmatically
3939

@@ -56,7 +56,7 @@ __declspec(dllexport) double MySqrt(__int64 n) {
5656
}
5757
```
5858
59-
The following sample consumes the DLL, demonstrating how to use **/CLRSUPPORTLASTERROR**.
59+
The following sample consumes the DLL, demonstrating how to use **`/CLRSUPPORTLASTERROR`**.
6060
6161
```cpp
6262
// CLRSUPPORTLASTERROR_client.cpp
@@ -109,5 +109,5 @@ GetLastError for system call succeeded (183).
109109

110110
## See also
111111

112-
[MSVC linker reference](linking.md)<br/>
113-
[MSVC Linker Options](linker-options.md)
112+
[MSVC linker reference](linking.md)\
113+
[MSVC linker options](linker-options.md)

‎docs/build/reference/clrunmanagedcodecheck-add-suppressunmanagedcodesecurityattribute.md‎

Lines changed: 14 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,38 @@
11
---
22
description: "Learn more about: /CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)"
33
title: "/CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)"
4-
ms.date: "05/16/2019"
4+
ms.date: 09/19/2022
55
ms.topic: "reference"
6-
f1_keywords: ["/CLRUNMANAGEDCODECHECK"]
6+
f1_keywords: ["VC.Project.VCLinkerTool.CLRUnmanagedCodeCheck", "/CLRUNMANAGEDCODECHECK"]
77
helpviewer_keywords: ["-CLRUNMANAGEDCODECHECK linker option", "/CLRUNMANAGEDCODECHECK linker option"]
88
ms.assetid: 73abc426-dab0-45e2-be85-0f9a14206cc2
99
author: "corob-msft"
1010
ms.author: "corob"
1111
---
12-
# /CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)
12+
# `/CLRUNMANAGEDCODECHECK` (Remove SuppressUnmanagedCodeSecurityAttribute)
1313

14-
**/CLRUNMANAGEDCODECHECK** specifies that the linker does not apply <xref:System.Security.SuppressUnmanagedCodeSecurityAttribute> to linker-generated `PInvoke` calls from managed code into native DLLs.
14+
**`/CLRUNMANAGEDCODECHECK`** specifies that the linker doesn't apply <xref:System.Security.SuppressUnmanagedCodeSecurityAttribute> to linker-generated `PInvoke` calls from managed code into native DLLs.
1515

1616
## Syntax
1717

18-
> **/CLRUNMANAGEDCODECHECK**[**:NO**]
18+
> **`/CLRUNMANAGEDCODECHECK`**\
19+
> **`/CLRUNMANAGEDCODECHECK:NO`**
1920
2021
## Remarks
2122

22-
By default, the linker applies the **SuppressUnmanagedCodeSecurityAttribute** to linker-generated `PInvoke` calls. When **/CLRUNMANAGEDCODECHECK** is in effect, **SuppressUnmanagedCodeSecurityAttribute** is removed. To explicitly apply the **SuppressUnmanagedCodeSecurityAttribute** to linker-generated `PInvoke` calls, you can use **/CLRUNMANAGEDCODECHECK:NO**.
23+
By default, the linker applies the `SuppressUnmanagedCodeSecurityAttribute` attribute to linker-generated `PInvoke` calls. When **`/CLRUNMANAGEDCODECHECK`** is in effect, `SuppressUnmanagedCodeSecurityAttribute` is removed. To explicitly apply the `SuppressUnmanagedCodeSecurityAttribute` attribute to linker-generated `PInvoke` calls, you can use **`/CLRUNMANAGEDCODECHECK:NO`**.
2324

24-
The linker only adds the attribute to objects that are compiled using **/clr** or **/clr:pure**. However, the **/clr:pure** compiler option is deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later.
25+
The linker only adds the attribute to objects that are compiled using **`/clr`** or **`/clr:pure`**. However, the **`/clr:pure`** compiler option is deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later.
2526

26-
A `PInvoke` call is generated by the linker when the linker cannot find a managed symbol to satisfy a reference from a managed caller but can find a native symbol to satisfy that reference. For more information about `PInvoke`, see [Calling Native Functions from Managed Code](../../dotnet/calling-native-functions-from-managed-code.md).
27+
A `PInvoke` call is generated by the linker when the linker can't find a managed symbol to satisfy a reference from a managed caller but can find a native symbol to satisfy that reference. For more information about `PInvoke`, see [Calling Native Functions from Managed Code](../../dotnet/calling-native-functions-from-managed-code.md).
2728

28-
Note that if you use <xref:System.Security.AllowPartiallyTrustedCallersAttribute> in your code, you should explicitly set **/CLRUNMANAGEDCODECHECK** to remove the **SuppressUnmanagedCodeSecurity** attribute. It is a potential security vulnerability if an image contains both the **SuppressUnmanagedCodeSecurity** and **AllowPartiallyTrustedCallers** attributes.
29+
If you use <xref:System.Security.AllowPartiallyTrustedCallersAttribute> in your code, you should explicitly set **`/CLRUNMANAGEDCODECHECK`** to remove the `SuppressUnmanagedCodeSecurity` attribute. It's a potential security vulnerability if an image contains both the `SuppressUnmanagedCodeSecurity` and `AllowPartiallyTrustedCallers` attributes.
2930

30-
See [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/framework/windows-identity-foundation/secure-coding-guidelines-for-unmanaged-code) for more information about the implications of using **SuppressUnmanagedCodeSecurityAttribute**.
31+
For more information about the implications of using `SuppressUnmanagedCodeSecurityAttribute`, see [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/framework/windows-identity-foundation/secure-coding-guidelines-for-unmanaged-code).
3132

3233
### To set this linker option in the Visual Studio development environment
3334

34-
1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](../working-with-project-properties.md).
35+
1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
3536

3637
1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
3738

@@ -43,5 +44,5 @@ See [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/fram
4344

4445
## See also
4546

46-
- [MSVC linker reference](linking.md)
47-
- [MSVC Linker Options](linker-options.md)
47+
[MSVC linker reference](linking.md)\
48+
[MSVC linker options](linker-options.md)

0 commit comments

Comments
 (0)