Merge pull request #4921 from MicrosoftDocs/master637194791719047190

ghogen · web-flow · commit a6e669a6b2b4 · 2020-03-10T16:19:48.000-07:00
For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error
diff --git a/docs/code-quality/ca1712.md b/docs/code-quality/ca1712.md
@@ -56,6 +56,26 @@ The following example shows an incorrectly named enumeration followed by the cor
 
 [CA2217: Do not mark enums with FlagsAttribute](../code-quality/ca2217.md)
 
+## Configurability
+
+If you're running this rule from [FxCop analyzers](install-fxcop-analyzers.md) (and not with legacy analysis), you can configure the analysis for this rule.
+
+You can configure the number of enumeration values required to trigger the rule. For example, to specify that the rule is triggered if one or more the enum values starts with the enum type name, add the following key-value pair to an *.editorconfig* file in your project:
+
+```ini
+dotnet_code_quality.CA1712.enum_values_prefix_trigger = AnyEnumValue
+```
+
+Examples:
+
+| Option value | Summary |
+| --- | --- |
+|`dotnet_code_quality.CA1712.enum_values_prefix_trigger = AnyEnumValue` | The rule is triggered if *any* of the enum values starts with the enum type name.
+|`dotnet_code_quality.CA1712.enum_values_prefix_trigger = AllEnumValues` | The rule is triggered if *all* of the enum values start with the enum type name.
+|`dotnet_code_quality.CA1712.enum_values_prefix_trigger = Heuristic` | The rule is triggered using the default FxCop heuristic (that is, when at least 75% of the enum values start with the enum type name).
+
+You can configure all of these options for just this rule, for all rules, or for all rules in this category (Naming). For more information, see [Configure FxCop analyzers](configure-fxcop-analyzers.md).
+
 ## See also
 
 - <xref:System.Enum?displayProperty=fullName>
diff --git a/docs/deployment/clickonce-and-authenticode.md b/docs/deployment/clickonce-and-authenticode.md
@@ -56,8 +56,6 @@ ms.workload:
 
 - Uninstall the application, and reinstall a new version with a valid certificate.
 
-- Create a command-line assembly that updates the certificate. Step-by-step information about this process can be found at [Microsoft Support Article 925521](https://support.microsoft.com/help/925521).
-
 ### Store certificates
 
 - You can store certificates as a *.pfx* file on your file system, or you can store them inside of a key container. A user on a Windows domain can have a number of key containers. By default, *MakeCert.exe* will store certificates in your personal key container, unless you specify that it should save it to a *.pfx* instead. *Mage.exe* and *MageUI.exe*, the [!INCLUDE[winsdkshort](../debugger/debug-interface-access/includes/winsdkshort_md.md)] tools for creating [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] deployments, enable you to use certificates stored in either fashion.
diff --git a/docs/install/visual-studio-build-numbers-and-release-dates.md b/docs/install/visual-studio-build-numbers-and-release-dates.md
@@ -5,7 +5,7 @@ description: A list of released versions and build numbers for Visual Studio, so
 author: ornellaalt
 ms.author: ornella
 manager: jillfra
-ms.date: 03/02/2020
+ms.date: 03/10/2020
 ms.topic: reference
 ms.workload:
 - multiple
@@ -22,6 +22,8 @@ The following table lists the build numbers and release dates for Visual Studio
 
 | **Version**| **Channel** | **Release date** | **Build version** |
 | ---------------------- | ----------- | ---------------- | ----------------- |
+| 16.4.6 | Release | March 10, 2020  | 16.4.29905.134 |
+| 16.0.12 | Release | March 10, 2020 | 16.0.28803.697 |
 | 16.5.0 | Preview 5 | March 2, 2020 | 16.5.29827.131 |
 | 16.5.0 | Preview 4 | February 25, 2020 | 16.5.29820.132 |
 | 16.5.0 | Preview 3 | February 19, 2020 | 16.5.29814.53 |
@@ -120,6 +122,7 @@ The following table lists the build numbers and release dates for Visual Studio
 
 | **Version**| **Channel** | **Release date** | **Build version** |
 | ---------------------- | ----------- | ---------------- | ----------------- |
+| 15.9.21 | Release | March 10, 2020 | 15.9.28307.1064 |
 | 15.9.20 | Release | February 11, 2020 | 15.9.28307.1033 |
 | 15.9.19 | Release | January 14, 2020 | 15.9.28307.1000 |
 | 15.0.28 | Release | December 11, 2019 | 15.0.26228.102 |
diff --git a/docs/msbuild/calltarget-task.md b/docs/msbuild/calltarget-task.md
@@ -38,6 +38,8 @@ Invokes the specified targets within the project file.
 
  If you want to build the default targets, use the [MSBuild task](../msbuild/msbuild-task.md) and set the `Projects` parameter equal to `$(MSBuildProjectFile)`.
 
+When using `CallTarget`, MSBuild evaluates the called target in a new scope, as opposed to the same scope it's called from. This means that any item and property changes in the called target are not visible to the calling target.  To pass information to the calling target, use the `TargetOutputs` output parameter.
+
  In addition to the parameters listed above, this task inherits parameters from the <xref:Microsoft.Build.Tasks.TaskExtension> class, which itself inherits from the <xref:Microsoft.Build.Utilities.Task> class. For a list of these additional parameters and their descriptions, see [TaskExtension base class](../msbuild/taskextension-base-class.md).
 
 ## Example
diff --git a/docs/msbuild/how-to-extend-the-visual-studio-build-process.md b/docs/msbuild/how-to-extend-the-visual-studio-build-process.md
@@ -22,7 +22,6 @@ The Visual Studio build process is defined by a series of MSBuild *.targets* fil
 - Overriding specific predefined targets defined in the common targets (*Microsoft.Common.targets* or the files that it imports).
 
 - Overriding the "DependsOn" properties defined in the common targets.
-## Override predefined targets
 
 ## Override predefined targets
 
@@ -64,6 +63,45 @@ The following table shows all of the targets in the common targets that you can
 |`BeforeResolveReferences`, `AfterResolveReferences`|Tasks that are inserted in one of these targets run before or after assembly references are resolved.|
 |`BeforeResGen`, `AfterResGen`|Tasks that are inserted in one of these targets run before or after resources are generated.|
 
+## Example: AfterTargets and BeforeTargets
+
+The following example shows how to use the `AfterTargets` attribute to add a custom target that does something with the output files. In this case, it copies the output files to a new folder *CustomOutput*.  The example also shows how to clean up the files created by the custom build operation with a `CustomClean` target by using a `BeforeTargets` attribute and specifying that the custom clean operation runs before the `CoreClean` target.
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk">
+
+<PropertyGroup>
+   <TargetFramework>netcoreapp3.1</TargetFramework>
+   <_OutputCopyLocation>$(OutputPath)..\..\CustomOutput\</_OutputCopyLocation>
+</PropertyGroup>
+
+<Target Name="CustomAfterBuild" AfterTargets="Build">
+  <ItemGroup>
+    <_FilesToCopy Include="$(OutputPath)**\*"/>
+  </ItemGroup>
+  <Message Text="_FilesToCopy: @(_FilesToCopy)" Importance="high"/>
+
+  <Message Text="DestFiles:
+      @(_FilesToCopy->'$(_OutputCopyLocation)%(RecursiveDir)%(Filename)%(Extension)')"/>
+
+  <Copy SourceFiles="@(_FilesToCopy)"
+        DestinationFiles=
+        "@(_FilesToCopy->'$(_OutputCopyLocation)%(RecursiveDir)%(Filename)%(Extension)')"/>
+  </Target>
+
+  <Target Name="CustomClean" BeforeTargets="CoreClean">
+    <Message Text="Inside Custom Clean" Importance="high"/>
+    <ItemGroup>
+      <_CustomFilesToDelete Include="$(_OutputCopyLocation)**\*"/>
+    </ItemGroup>
+    <Delete Files='@(_CustomFilesToDelete)'/>
+  </Target>
+</Project>
+```
+
+> [!WARNING]
+> Be sure to use different names than the predefined targets listed in the table in the previous section (for example, we named the custom build target here `CustomAfterBuild`, not `AfterBuild`), since those predefined targets are overridden by the SDK import which also defines them. You don't see the import of the target file that overrides those targets, but it is implicitly added to the end of the project file when you use the `Sdk` attribute method of referencing an SDK.
+
 ## Override DependsOn properties
 
 Overriding predefined targets is an easy way to extend the build process, but, because MSBuild evaluates the definition of targets sequentially, there is no way to prevent another project that imports your project from overriding the targets you already have overridden. So, for example, the last `AfterBuild` target defined in the project file, after all other projects have been imported, will be the one that is used during the build.
@@ -125,6 +163,60 @@ Projects that import your project files can override these properties without ov
 |`CleanDependsOn`|The property to override if you want to clean up output from your custom build process.|
 |`CompileDependsOn`|The property to override if you want to insert custom processes before or after the compilation step.|
 
+## Example: BuildDependsOn and CleanDependsOn
+
+The following example is similar to the `BeforeTargets` and `AfterTargets` example, but shows how to achieve similar functionality. It extends the build by using `BuildDependsOn` to add your own task `CustomAfterBuild` that copies the output files after the build, and also adds the corresponding `CustomClean` task by using `CleanDependsOn`.  
+
+In this example, this is an SDK-style project. As mentioned in the note about SDK-style projects earlier in this article, you must use the manual import method instead of the `Sdk` attribute that Visual Studio uses when it generates project files.
+
+```xml
+<Project>
+<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />
+
+<PropertyGroup>
+   <TargetFramework>netcoreapp3.1</TargetFramework>
+</PropertyGroup>
+
+<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
+
+<PropertyGroup>
+   <BuildDependsOn>
+      $(BuildDependsOn);CustomAfterBuild
+    </BuildDependsOn>
+
+    <CleanDependsOn>
+      $(CleanDependsOn);CustomClean
+    </CleanDependsOn>
+
+    <_OutputCopyLocation>$(OutputPath)..\..\CustomOutput\</_OutputCopyLocation>
+  </PropertyGroup>
+
+<Target Name="CustomAfterBuild">
+  <ItemGroup>
+    <_FilesToCopy Include="$(OutputPath)**\*"/>
+  </ItemGroup>
+  <Message Text="_FilesToCopy: @(_FilesToCopy)" Importance="high"/>
+
+  <Message Text="DestFiles:
+      @(_FilesToCopy->'$(_OutputCopyLocation)%(RecursiveDir)%(Filename)%(Extension)')"/>
+
+  <Copy SourceFiles="@(_FilesToCopy)"
+        DestinationFiles=
+        "@(_FilesToCopy->'$(_OutputCopyLocation)%(RecursiveDir)%(Filename)%(Extension)')"/>
+  </Target>
+
+  <Target Name="CustomClean">
+    <Message Text="Inside Custom Clean" Importance="high"/>
+    <ItemGroup>
+      <_CustomFilesToDelete Include="$(_OutputCopyLocation)**\*"/>
+    </ItemGroup>
+    <Delete Files='@(_CustomFilesToDelete)'/>
+  </Target>
+</Project>
+```
+
+The order of elements is important. The `BuildDependsOn` and `CleanDependsOn` elements must appear after importing the standard SDK targets file.
+
 ## See also
 
 - [Visual Studio integration](../msbuild/visual-studio-integration-msbuild.md)
diff --git a/docs/msbuild/import-element-msbuild.md b/docs/msbuild/import-element-msbuild.md
@@ -62,7 +62,7 @@ Imports the contents of one project file into another project file.
 
  By convention, shared imported project files are saved as *.targets* files, but they are standard MSBuild project files. MSBuild does not prevent you from importing a project that has a different file name extension, but we recommend that you use the *.targets* extension for consistency.
 
- Relative paths in imported projects are interpreted relative to the directory of the importing project. Therefore, if a project file is imported into several project files in different locations, the relative paths in the imported project file will be interpreted differently for each imported project.
+ Relative paths in imported projects are interpreted relative to the directory of the importing project (with a few exceptions described later in this paragraph). Therefore, if a project file is imported into several project files in different locations, the relative paths in the imported project file will be interpreted differently for each imported project. There are two exceptions. One exception is that in `Import` elements, the path is always interpreted relative to the project that contains the `Import` element. Another exception is that the `UsingTask` always interprets the relative path for the `AssemblyFile` attribute relative to the file that contains the `UsingTask` element.
 
  All MSBuild reserved properties that relate to the project file, for example, `MSBuildProjectDirectory` and `MSBuildProjectFile`, that are referenced in an imported project are assigned values based on the importing project file.
 
diff --git a/docs/msbuild/msbuild-items.md b/docs/msbuild/msbuild-items.md
@@ -39,6 +39,8 @@ MSBuild items are inputs into the build system, and they typically represent fil
 </ItemGroup>
 ```
 
+The `Include` attribute is a path that is interpreted relative to the project file's folder, $(MSBuildProjectPath), even if the item is in an imported file such as a *.targets* file.
+
 ## Create items during execution
 
  Items that are outside [Target](../msbuild/target-element-msbuild.md) elements are assigned values during the evaluation phase of a build. During the subsequent execution phase, items can be created or modified in the following ways:
diff --git a/docs/msbuild/signfile-task.md b/docs/msbuild/signfile-task.md
@@ -45,7 +45,7 @@ Signs the specified file using the specified certificate.
 
 ## Example
 
- The following example uses the `SignFile` task to sign the files specified in the `FilesToSign` item collection with the certificate specified by the `Certificate` property.
+ The following example uses the `SignFile` task to sign the files specified in the `FilesToSign` item collection with the certificate specified by the `CertificateThumbprint` property.
 
 ```xml
 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
diff --git a/docs/msbuild/xmlpeek-task.md b/docs/msbuild/xmlpeek-task.md
@@ -37,6 +37,37 @@ Returns values as specified by XPath Query from an XML file.
 
  In addition to having the parameters that are listed in the table, this task inherits parameters from the <xref:Microsoft.Build.Tasks.TaskExtension> class, which itself inherits from the <xref:Microsoft.Build.Utilities.Task> class. For a list of these additional parameters and their descriptions, see [TaskExtension base class](../msbuild/taskextension-base-class.md).
 
+
+
+## Example
+
+Here is a sample XML file `settings.config` to read:
+
+```xml
+<appSettings>
+  <add key="ProjectFolder" value="S1" />
+</appSettings>
+```
+
+In this example, if you want to read `value`, then use code like the following:
+
+```xml
+<Target Name="BeforeBuild">
+    <XmlPeek XmlInputPath="settings.config" Query="appSettings/add[@key='ProjectFolder']/@value">
+        <Output TaskParameter="Result" ItemName="value" />
+    </XmlPeek>
+    <Message Text="Using project folder @(value)." Importance="high" />
+    <PropertyGroup>
+        <ProjectFolder>@(value)</ProjectFolder>
+    </PropertyGroup>
+    <ItemGroup>
+        <Compile Include="Projects\$(ProjectFolder)\Controls\Control1.ascx.cs">
+            <SubType>ASPXCodeBehind</SubType>
+        </Compile>
+    </ItemGroup>
+</Target>
+```
+
 ## See also
 
 - [Tasks](../msbuild/msbuild-tasks.md)
diff --git a/docs/msbuild/xsltransformation-task.md b/docs/msbuild/xsltransformation-task.md
@@ -28,7 +28,7 @@ Transforms an XML input by using an XSLT or compiled XSLT and outputs to an outp
 |Parameter|Description|
 |---------------|-----------------|
 |`OutputPaths`|Required <xref:Microsoft.Build.Framework.ITaskItem>`[]` parameter.<br /><br /> Specifies the output files for the XML transformation.|
-|`Parameters`|Optional `String` parameter.<br /><br /> Specifies the parameters to the XSLT Input document.|
+|`Parameters`|Optional `String` parameter.<br /><br /> Specifies the parameters to the XSLT Input document.  Provide the raw XML that holds each parameter as `<Parameter Name="" Value="" Namespace="" />`.|
 |`XmlContent`|Optional `String` parameter.<br /><br /> Specifies the XML input as a string.|
 |`XmlInputPaths`|Optional <xref:Microsoft.Build.Framework.ITaskItem>`[]` parameter.<br /><br /> Specifies the XML input files.|
 |`XslCompiledDllPath`|Optional <xref:Microsoft.Build.Framework.ITaskItem> parameter.<br /><br /> Specifies the compiled XSLT.|
@@ -39,7 +39,19 @@ Transforms an XML input by using an XSLT or compiled XSLT and outputs to an outp
 
  In addition to having the parameters that are listed in the table, this task inherits parameters from the <xref:Microsoft.Build.Tasks.TaskExtension> class, which itself inherits from the <xref:Microsoft.Build.Utilities.Task> class. For a list of these additional parameters and their descriptions, see [TaskExtension base class](../msbuild/taskextension-base-class.md).
 
+## Example
+
+In the following example, an XSL transform file *transform.xslt* is used to modify the xml file `$(XmlInputFileName)`. The transformed XML is written to `$(IntermediateOutputPath)output.xml`. The XSL transform takes `$(Parameter1)` as an input parameter.
+
+```xml
+    <XslTransformation XslInputPath="transform.xslt"
+                       XmlInputPaths="$(XmlInputFileName)"
+                       OutputPaths="$(IntermediateOutputPath)output.xml"
+                       Parameters="&lt;Parameter Name='Parameter1' Value='$(Parameter1)'/&gt;"/>
+```
+
 ## See also
 
+- [XSLT Parameters](/dotnet/standard/data/xml/xslt-parameters)
 - [Tasks](../msbuild/msbuild-tasks.md)
 - [Task reference](../msbuild/msbuild-task-reference.md)
diff --git a/docs/msbuild/zipdirectory-task.md b/docs/msbuild/zipdirectory-task.md
@@ -46,7 +46,7 @@ Creates a *.zip* archive from the contents of a directory.
 
 ## Example
 
- The following example creates a *.zip* archive from the output directory after building a project.
+ The following example (if used as an imported *.targets* file) creates a *.zip* archive from the output directory after building a project. The `$(OutputPath)` property would normally be defined in an MSBuild project file, so a project file that imports the following file would produce a zip archive `output.zip`:
 
 ```xml
 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
diff --git a/docs/test/run-a-unit-test-as-a-64-bit-process.md b/docs/test/run-a-unit-test-as-a-64-bit-process.md
@@ -1,6 +1,6 @@
 ---
 title: Run a unit test as a 64-bit process
-ms.date: 11/04/2016
+ms.date: 03/10/2020
 ms.topic: conceptual
 helpviewer_keywords:
 - unit tests, creating
@@ -17,14 +17,25 @@ If you have a 64-bit machine, you can run unit tests and capture code coverage i
 
 ## To run a unit test as a 64-bit process
 
-1. If your code or tests were compiled as 32-bit/x86, but you now want to run them as a 64-bit process, recompile them as **Any CPU**, or optionally as **64-bit**.
+1. If your code or tests were compiled as 32-bit/x86, but you now want to run them as a 64-bit process, recompile them as **Any CPU**.
+
+   ::: moniker range="vs-2017"
+   Alternatively, In Visual Studio 2017, you could also compile your project as **64-bit**.
+   ::: moniker-end
 
     > [!TIP]
     > For maximum flexibility, compile your test projects with the **Any CPU** configuration. Then you can run on both 32-bit and 64-bit agents. There's no advantage to compiling test projects with the **64-bit** configuration.
 
-2. From the Visual Studio menu, choose **Test**, then choose **Settings**, and then choose **Processor Architecture**. Choose **x64** to run the tests as a 64-bit process.
+2. Set the unit tests to run as a 64-bit process.
+
+   ::: moniker range=">=vs-2019"
+   From the Visual Studio menu, choose **Test**, then choose **Processor Architecture for AnyCPU projects**. Choose **x64** to run the tests as a 64-bit process.
+   ::: moniker-end
+   ::: moniker range="vs-2017"
+   From the Visual Studio menu, choose **Test**, then choose **Test Settings**, and then choose **Processor Architecture**. Choose **x64** to run the tests as a 64-bit process.
+   ::: moniker-end
 
-   - or -
+   \- or -
 
    Specify `<TargetPlatform>x64</TargetPlatform>` in a *.runsettings* file. An advantage of this method is that you can specify groups of settings in different files and quickly switch between different settings. You can also copy settings between solutions. For more information, see [Configure unit tests by using a .runsettings file](../test/configure-unit-tests-by-using-a-dot-runsettings-file.md).
 
diff --git a/docs/test/walkthrough-create-and-run-a-load-test.md b/docs/test/walkthrough-create-and-run-a-load-test.md
diff --git a/docs/test/walkthrough-creating-and-running-unit-tests-for-managed-code.md b/docs/test/walkthrough-creating-and-running-unit-tests-for-managed-code.md
diff --git a/subscriptions/assign-license-bulk.md b/subscriptions/assign-license-bulk.md
