Merge branch 'master' into vcraic0718a

Author: gewarren

.openpublishing.redirection.json

@@ -5730,6 +5730,11 @@
             "source_path": "mac/benefits-vsmac-over-xs.md",
             "redirect_url": "/visualstudio/mac/",
             "redirect_document_id": false
+        },
+        {
+            "source_path": "docs/cross-platform/overview-of-visual-studio-tools-for-unity.md",
+            "redirect_url": "/visualstudio/cross-platform/visual-studio-tools-for-unity",
+            "redirect_document_id": false
         }
 
     ]

docs/code-quality/ca1020-avoid-namespaces-with-few-types.md

@@ -18,6 +18,7 @@ ms.workload:
   - "multiple"
 ---
 # CA1020: Avoid namespaces with few types
+
 |||
 |-|-|
 |TypeName|AvoidNamespacesWithFewTypes|
@@ -26,16 +27,20 @@ ms.workload:
 |Breaking Change|Breaking|
 
 ## Cause
- A namespace other than the global namespace contains fewer than five types.
+
+A namespace other than the global namespace contains fewer than five types.
 
 ## Rule Description
- Make sure that each of your namespaces has a logical organization, and that a valid reason exists to put types in a sparsely populated namespace. Namespaces should contain types that are used together in most scenarios. When their applications are mutually exclusive, types should be located in separate namespaces. For example, the <xref:System.Web.UI> namespace contains types that are used in Web applications, and the <xref:System.Windows.Forms> namespace contains types that are used in [!INCLUDE[TLA#tla_mswin](../code-quality/includes/tlasharptla_mswin_md.md)]-based applications. Even though both namespaces have types that control aspects of the user interface, these types are not designed for use in the same application. Therefore, they are located in separate namespaces. Careful namespace organization can also be helpful because it increases the discoverability of a feature. By examining the namespace hierarchy, library consumers should be able to locate the types that implement a feature.
+
+Make sure that each of your namespaces has a logical organization, and that a valid reason exists to put types in a sparsely populated namespace. Namespaces should contain types that are used together in most scenarios. When their applications are mutually exclusive, types should be located in separate namespaces. For example, the <xref:System.Web.UI> namespace contains types that are used in web applications, and the <xref:System.Windows.Forms> namespace contains types that are used in [!INCLUDE[TLA#tla_mswin](../code-quality/includes/tlasharptla_mswin_md.md)]-based applications. Even though both namespaces have types that control aspects of the user interface, these types are not designed for use in the same application. Therefore, they are located in separate namespaces. Careful namespace organization can also be helpful because it increases the discoverability of a feature. By examining the namespace hierarchy, library consumers should be able to locate the types that implement a feature.
 
 > [!NOTE]
->  Design-time types and permissions should not be merged into other namespaces to comply with this guideline. These types belong in their own namespaces below your main namespace, and the namespaces should end in `.Design` and `.Permissions`, respectively.
+> Design-time types and permissions should not be merged into other namespaces to comply with this guideline. These types belong in their own namespaces below your main namespace, and the namespaces should end in `.Design` and `.Permissions`, respectively.
 
 ## How to Fix Violations
- To fix a violation of this rule, try to combine namespaces that contain just a few types into a single namespace.
+
+To fix a violation of this rule, try to combine namespaces that contain just a few types into a single namespace.
 
 ## When to Suppress Warnings
- It is safe to suppress a warning from this rule when the namespace does not contain types that are used with the types in your other namespaces.
+
+It is safe to suppress a warning from this rule when the namespace does not contain types that are used with the types in your other namespaces.

docs/code-quality/ca2001-avoid-calling-problematic-methods.md

@@ -39,7 +39,7 @@ Avoid making unnecessary and potentially dangerous method calls. A violation of
 |<xref:System.GC.Collect%2A?displayProperty=fullName>|Calling GC.Collect can significantly affect application performance and is rarely necessary. For more information, see [Rico Mariani's Performance Tidbits](http://go.microsoft.com/fwlink/?LinkId=169256) blog entry on MSDN.|
 |<xref:System.Threading.Thread.Resume%2A?displayProperty=fullName><br /><br /> <xref:System.Threading.Thread.Suspend%2A?displayProperty=fullName>|Thread.Suspend and Thread.Resume have been deprecated because of their unpredictable behavior.  Use other classes in the <xref:System.Threading> namespace, such as <xref:System.Threading.Monitor>, <xref:System.Threading.Mutex>, and <xref:System.Threading.Semaphore>, to synchronize threads or protect resources.|
 |<xref:System.Runtime.InteropServices.SafeHandle.DangerousGetHandle%2A?displayProperty=fullName>|The DangerousGetHandle method poses a security risk because it can return a handle that is not valid. See the <xref:System.Runtime.InteropServices.SafeHandle.DangerousAddRef%2A> and the <xref:System.Runtime.InteropServices.SafeHandle.DangerousRelease%2A> methods for more information about how to use the DangerousGetHandle method safely.|
-|<xref:System.Reflection.Assembly.LoadFrom%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadFile%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadWithPartialName%2A?displayProperty=fullName>|These methods can load assemblies from unexpected locations. For example, see Suzanne Cook's .NET CLR Notes blog posts [LoadFile vs. LoadFrom](http://go.microsoft.com/fwlink/?LinkId=164450) and [Choosing a Binding Context](http://go.microsoft.com/fwlink/?LinkId=164451) on the MSDN Web site for information about methods that load assemblies.|
+|<xref:System.Reflection.Assembly.LoadFrom%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadFile%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadWithPartialName%2A?displayProperty=fullName>|These methods can load assemblies from unexpected locations. For example, see Suzanne Cook's .NET CLR Notes blog posts [LoadFile vs. LoadFrom](http://go.microsoft.com/fwlink/?LinkId=164450) and [Choosing a Binding Context](http://go.microsoft.com/fwlink/?LinkId=164451) for information about methods that load assemblies.|
 |[CoSetProxyBlanket](http://go.microsoft.com/fwlink/?LinkID=169250) (Ole32)<br /><br /> [CoInitializeSecurity](http://go.microsoft.com/fwlink/?LinkId=169255) (Ole32)|By the time the user code starts executing in a managed process, it is too late to reliably call CoSetProxyBlanket. The common language runtime (CLR) takes initialization actions that may prevent the users P/Invoke from succeeding.<br /><br /> If you do have to call CoSetProxyBlanket for a managed application, we recommend that you start the process by using a native code (C++) executable, call CoSetProxyBlanket in the native code, and then start your managed code application in process. (Be sure to specify a runtime version number.)|
 
 ## How to fix violations

docs/code-quality/ca2132-default-constructors-must-be-at-least-as-critical-as-base-type-default-constructors.md

@@ -14,6 +14,7 @@ ms.workload:
   - "multiple"
 ---
 # CA2132: Default constructors must be at least as critical as base type default constructors
+
 |||
 |-|-|
 |TypeName|DefaultConstructorsMustHaveConsistentTransparency|
@@ -22,23 +23,26 @@ ms.workload:
 |Breaking Change|Breaking|
 
 > [!NOTE]
->  This warning is only applied to code that is running the CoreCLR (the version of the CLR that is specific to Silverlight Web applications).
+> This warning is only applied to code that is running the CoreCLR (the version of the CLR that is specific to Silverlight web applications).
 
 ## Cause
- The transparency attribute of the default constructor of a derived class is not as critical as the transparency of the base class.
+
+The transparency attribute of the default constructor of a derived class is not as critical as the transparency of the base class.
 
 ## Rule Description
- Types and members that have the <xref:System.Security.SecurityCriticalAttribute> cannot be used by Silverlight application code. Security-critical types and members can be used only by trusted code in the .NET Framework for Silverlight class library. Because a public or protected construction in a derived class must have the same or greater transparency than its base class, a class in an application cannot be derived from a class marked SecurityCritical.
 
- For CoreCLR platform code, if a base type has a public or protected non-transparent default constructor then the derived type must obey the default constructor inheritance rules. The derived type must also have a default constructor and that constructor must be at least as critical default constructor of the base type.
+Types and members that have the <xref:System.Security.SecurityCriticalAttribute> cannot be used by Silverlight application code. Security-critical types and members can be used only by trusted code in the .NET Framework for Silverlight class library. Because a public or protected construction in a derived class must have the same or greater transparency than its base class, a class in an application cannot be derived from a class marked SecurityCritical.
+
+For CoreCLR platform code, if a base type has a public or protected non-transparent default constructor then the derived type must obey the default constructor inheritance rules. The derived type must also have a default constructor and that constructor must be at least as critical default constructor of the base type.
 
 ## How to Fix Violations
- To fix the violation, remove the type or do not derive from security non-transparent type.
+
+To fix the violation, remove the type or do not derive from security non-transparent type.
 
 ## When to Suppress Warnings
- Do not suppress warnings from this rule. Violations of this rule by application code will result in the CoreCLR refusing to load the type with a <xref:System.TypeLoadException>.
+
+Do not suppress warnings from this rule. Violations of this rule by application code will result in the CoreCLR refusing to load the type with a <xref:System.TypeLoadException>.
 
 ### Code
- [!code-csharp[FxCop.Security.CA2132.DefaultConstructorsMustHaveConsistentTransparency#1](../code-quality/codesnippet/CSharp/ca2132-default-constructors-must-be-at-least-as-critical-as-base-type-default-constructors_1.cs)]
 
-### Comments
+[!code-csharp[FxCop.Security.CA2132.DefaultConstructorsMustHaveConsistentTransparency#1](../code-quality/codesnippet/CSharp/ca2132-default-constructors-must-be-at-least-as-critical-as-base-type-default-constructors_1.cs)]

docs/code-quality/ca2133-delegates-must-bind-to-methods-with-consistent-transparency.md

@@ -14,6 +14,7 @@ ms.workload:
   - "multiple"
 ---
 # CA2133: Delegates must bind to methods with consistent transparency
+
 |||
 |-|-|
 |TypeName|DelegatesMustBindWithConsistentTransparency|
@@ -22,19 +23,24 @@ ms.workload:
 |Breaking Change|Breaking|
 
 > [!NOTE]
->  This warning is only applied to code that is running the CoreCLR (the version of the CLR that is specific to Silverlight Web applications).
+> This warning is only applied to code that is running the CoreCLR (the version of the CLR that is specific to Silverlight web applications).
 
 ## Cause
- This warning fires on a method that binds a delegate that is marked with the <xref:System.Security.SecurityCriticalAttribute> to a method that is transparent or that is marked with the <xref:System.Security.SecuritySafeCriticalAttribute>. The warning also fires a method that binds a delegate that is transparent or safe-critical to a critical method.
+
+This warning fires on a method that binds a delegate that is marked with the <xref:System.Security.SecurityCriticalAttribute> to a method that is transparent or that is marked with the <xref:System.Security.SecuritySafeCriticalAttribute>. The warning also fires a method that binds a delegate that is transparent or safe-critical to a critical method.
 
 ## Rule Description
- Delegate types and the methods that they bind to must have consistent transparency. Transparent and safe-critical delegates may only bind to other transparent or safe-critical methods. Similarly, critical delegates may only bind to critical methods. These binding rules ensure that the only code that can invoke a method via a delegate could have also invoked the same method directly. For example, binding rules prevent transparent code from calling critical code directly via a transparent delegate.
+
+Delegate types and the methods that they bind to must have consistent transparency. Transparent and safe-critical delegates may only bind to other transparent or safe-critical methods. Similarly, critical delegates may only bind to critical methods. These binding rules ensure that the only code that can invoke a method via a delegate could have also invoked the same method directly. For example, binding rules prevent transparent code from calling critical code directly via a transparent delegate.
 
 ## How to Fix Violations
- To fix a violation of this warning, change the transparency of the delegate or of the method that it binds so that the transparency of the two are equivalent.
+
+To fix a violation of this warning, change the transparency of the delegate or of the method that it binds so that the transparency of the two are equivalent.
 
 ## When to Suppress Warnings
- Do not suppress a warning from this rule.
+
+Do not suppress a warning from this rule.
 
 ### Code
- [!code-csharp[FxCop.Security.CA2133.DelegatesMustBindWithConsistentTransparency#1](../code-quality/codesnippet/CSharp/ca2133-delegates-must-bind-to-methods-with-consistent-transparency_1.cs)]
+
+[!code-csharp[FxCop.Security.CA2133.DelegatesMustBindWithConsistentTransparency#1](../code-quality/codesnippet/CSharp/ca2133-delegates-must-bind-to-methods-with-consistent-transparency_1.cs)]

docs/code-quality/ca2212-do-not-mark-serviced-components-with-webmethod.md

@@ -18,6 +18,7 @@ ms.workload:
   - "multiple"
 ---
 # CA2212: Do not mark serviced components with WebMethod
+
 |||
 |-|-|
 |TypeName|DoNotMarkServicedComponentsWithWebMethod|
@@ -26,17 +27,22 @@ ms.workload:
 |Breaking Change|Breaking|
 
 ## Cause
- A method in a type that inherits from <xref:System.EnterpriseServices.ServicedComponent?displayProperty=fullName> is marked with <xref:System.Web.Services.WebMethodAttribute?displayProperty=fullName>.
+
+A method in a type that inherits from <xref:System.EnterpriseServices.ServicedComponent?displayProperty=fullName> is marked with <xref:System.Web.Services.WebMethodAttribute?displayProperty=fullName>.
 
 ## Rule Description
- <xref:System.Web.Services.WebMethodAttribute> applies to methods within an XML Web service that were created by using ASP.NET; it makes the method callable from remote Web clients. The method and class must be public and executing in an ASP.NET Web application. <xref:System.EnterpriseServices.ServicedComponent> types are hosted by COM+ applications and can use COM+ services. <xref:System.Web.Services.WebMethodAttribute> is not applied to <xref:System.EnterpriseServices.ServicedComponent> types because they are not intended for the same scenarios. Specifically, adding the attribute to the <xref:System.EnterpriseServices.ServicedComponent> method does not make the method callable from remote Web clients. Because <xref:System.Web.Services.WebMethodAttribute> and a <xref:System.EnterpriseServices.ServicedComponent> method have conflicting behaviors and requirements for context and transaction flow, the behavior of the method will be incorrect in some scenarios.
+
+<xref:System.Web.Services.WebMethodAttribute> applies to methods within an XML web service that were created by using ASP.NET; it makes the method callable from remote web clients. The method and class must be public and executing in an ASP.NET web application. <xref:System.EnterpriseServices.ServicedComponent> types are hosted by COM+ applications and can use COM+ services. <xref:System.Web.Services.WebMethodAttribute> is not applied to <xref:System.EnterpriseServices.ServicedComponent> types because they are not intended for the same scenarios. Specifically, adding the attribute to the <xref:System.EnterpriseServices.ServicedComponent> method does not make the method callable from remote web clients. Because <xref:System.Web.Services.WebMethodAttribute> and a <xref:System.EnterpriseServices.ServicedComponent> method have conflicting behaviors and requirements for context and transaction flow, the behavior of the method will be incorrect in some scenarios.
 
 ## How to Fix Violations
- To fix a violation of this rule, remove the attribute from the <xref:System.EnterpriseServices.ServicedComponent> method.
+
+To fix a violation of this rule, remove the attribute from the <xref:System.EnterpriseServices.ServicedComponent> method.
 
 ## When to Suppress Warnings
- Do not suppress a warning from this rule. There are no scenarios where combining these elements is correct.
+
+Do not suppress a warning from this rule. There are no scenarios where combining these elements is correct.
 
 ## See Also
- <xref:System.EnterpriseServices.ServicedComponent?displayProperty=fullName>
- <xref:System.Web.Services.WebMethodAttribute?displayProperty=fullName>
+
+- <xref:System.EnterpriseServices.ServicedComponent?displayProperty=fullName>
+- <xref:System.Web.Services.WebMethodAttribute?displayProperty=fullName>

docs/code-quality/code-analysis-policy-errors.md

@@ -62,7 +62,7 @@ The following errors occur if the code analysis policy is not satisfied at check
 
  **You must enable Code Analysis in project {0} properties and build before checking in.**
 
- This error applied to [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)] projects and Web projects. The policy requires managed code analysis to be performed, but it is not enabled in the current project on the client.
+ This error applied to [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)] projects and web projects. The policy requires managed code analysis to be performed, but it is not enabled in the current project on the client.
 
  **You must enable C/C++ Code Analysis in project {0} properties and build before checking in.**
 

docs/code-quality/how-to-configure-code-analysis-for-a-managed-code-project.md

@@ -21,7 +21,7 @@ ms.workload:
 In Visual Studio, you can choose from a list of code analysis *rule sets* to apply to a managed code project. The default rule set is *Microsoft Minimum Recommended Rules*. You can apply another rule set to a project or to all projects in a solution.
 
 > [!TIP]
-> For information about how to configure a rule set for ASP.NET Web applications, see [How to: Configure Code Analysis for an ASP.NET Web Application](../code-quality/how-to-configure-code-analysis-for-an-aspnet-web-application.md).
+> For information about how to configure a rule set for ASP.NET web applications, see [How to: Configure Code Analysis for an ASP.NET web Application](../code-quality/how-to-configure-code-analysis-for-an-aspnet-web-application.md).
 
 ## To configure a rule set for a .NET Framework project
 
@@ -70,4 +70,4 @@ By default, all the managed projects of a solution are assigned the *Microsoft M
 
 ## See also
 
-- [How to: Configure Code Analysis for an ASP.NET Web Application](../code-quality/how-to-configure-code-analysis-for-an-aspnet-web-application.md)
+- [How to: Configure Code Analysis for an ASP.NET web Application](../code-quality/how-to-configure-code-analysis-for-an-aspnet-web-application.md)