Fix typo (#2041)

.Net --> .NET

Author: Potapy4

xml/Microsoft.Build.Evaluation/ProjectCollection.xml

@@ -355,7 +355,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject() before the ProjectCollection goes out of scope."  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject() before the ProjectCollection goes out of scope."  
   
  ]]></format>
         </remarks>
@@ -680,7 +680,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -717,7 +717,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -755,7 +755,7 @@
 ## Remarks  
  The project is added to this project collection when either this project or the given project root is given the full path to a project file.  
   
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -794,7 +794,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -834,7 +834,7 @@
 ## Remarks  
  The project is added to this project collection when either this project or the given project root is given the full path to a project file.  
   
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -870,7 +870,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>
@@ -907,7 +907,7 @@
 ## Remarks  
  The project is added to this project collection when either this project or the given project root is given the full path to a project file.  
   
- In the MSBuild versions that were delivered with .Net 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
+ In the MSBuild versions that were delivered with .NET Framework 4.5 and Visual Studio 12.0, you must call UnloadProject before the ProjectCollection goes out of scope.  
   
  ]]></format>
         </remarks>

xml/System.Data.Common/DbProviderFactories.xml

@@ -138,7 +138,7 @@
 ## Remarks  
  The `providerInvariantName` parameter corresponds to the **InvariantName** column of a table returned by <xref:System.Data.Common.DbProviderFactories.GetFactoryClasses%2A>.
 
- If you pass a value for `providerInvariantName` that's not valid, an exception is raised with the message, "Unable to find the requested .Net Framework Data Provider.  It may not be installed."
+ If you pass a value for `providerInvariantName` that's not valid, an exception is raised with the message, "Unable to find the requested .NET Framework Data Provider.  It may not be installed."
   
  ]]></format>
         </remarks>

xml/System.Data.SqlClient/SqlException.xml

@@ -53,9 +53,9 @@
   
  The following is general information on handling exceptions. Your code should catch exceptions to prevent the application from crashing and to allow displaying a relevant error message to the user.  You can use database transactions to ensure that the data is consistent regardless of what happens in the client application (including a crash). Features like System.Transaction.TransactionScope or the BeginTransaction method (in System.Data.OleDb.OleDbConnection, System.Data.ODBC.ODBCConnection, and System.Data.SqlClient.SqlConnection) ensure consistent data regardless of exceptions raised by a provider. Transactions can fail, so catch failures and retry the transaction.  
   
- Note that beginning with  .NET Framework 4.5, <xref:System.Data.SqlClient.SqlException> can return an inner <xref:System.ComponentModel.Win32Exception>.  
+ Note that beginning with .NET Framework 4.5, <xref:System.Data.SqlClient.SqlException> can return an inner <xref:System.ComponentModel.Win32Exception>.  
   
- The exception class of a .Net Framework data provider reports provider-specific errors. For example System.Data.Odbc has OdbcException, System.Data.OleDb has OleDbException, and System.Data.SqlClient has SqlException. For the best level of error detail, catch these exceptions and use the members of these exception classes to get details of the error.  
+ The exception class of a .NET Framework data provider reports provider-specific errors. For example System.Data.Odbc has OdbcException, System.Data.OleDb has OleDbException, and System.Data.SqlClient has SqlException. For the best level of error detail, catch these exceptions and use the members of these exception classes to get details of the error.  
   
  In addition to the provider-specific errors, .NET Framework data provider types can raise .NET Framework exceptions such as System.OutOfMemoryException and System.Threading.ThreadAbortException. Recovery from these exceptions may not be possible.  
   

xml/System.Globalization/CalendarWeekRule.xml

@@ -88,7 +88,7 @@
  [!code-vb[System.Globalization.CalendarWeekRule#1](~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.globalization.calendarweekrule/vb/calendarweekruleex.vb#1)]  
   
 > [!NOTE]
->  This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .Net](https://go.microsoft.com/fwlink/?LinkId=160851).  
+>  This does not map exactly to ISO 8601. The differences are discussed in the blog entry [ISO 8601 Week of Year format in Microsoft .NET](https://go.microsoft.com/fwlink/?LinkId=160851).  
   
  Each <xref:System.Globalization.CultureInfo> object supports a set of calendars. The <xref:System.Globalization.CultureInfo.Calendar%2A> property returns the default calendar for the culture, and the <xref:System.Globalization.CultureInfo.OptionalCalendars%2A> property returns an array containing all the calendars supported by the culture. To change the calendar used by a <xref:System.Globalization.CultureInfo>, the application should set the <xref:System.Globalization.DateTimeFormatInfo.Calendar%2A> property of <xref:System.Globalization.CultureInfo.DateTimeFormat%2A?displayProperty=nameWithType> to a new <xref:System.Globalization.CalendarWeekRule.FirstFourDayWeek?displayProperty=nameWithType>.  
   

xml/System.ServiceModel.Channels/ConnectionOrientedTransportBindingElement.xml

@@ -181,7 +181,7 @@
           <format type="text/markdown"><![CDATA[  
   
 ## Remarks  
- This property determines how long a TCP connection can take to authenticate itself using the .Net Framing protocol. A client needs to send some initial data before the server has enough information to perform authentication. This timeout is intentionally made smaller than the ReceiveTimeout (10 min) so that malicious unauthenticated clients do not keep the connections tied up to the server for long. The default value is 30 seconds.  
+ This property determines how long a TCP connection can take to authenticate itself using the .NET Framing protocol. A client needs to send some initial data before the server has enough information to perform authentication. This timeout is intentionally made smaller than the ReceiveTimeout (10 min) so that malicious unauthenticated clients do not keep the connections tied up to the server for long. The default value is 30 seconds.  
   
  ]]></format>
         </remarks>

xml/System.ServiceModel.Channels/CustomBinding.xml

@@ -105,7 +105,7 @@
  For a discussion on how to use a custom binding to modify a system-provided binding, see [How to: Customize a System-Provided Binding](~/docs/framework/wcf/extending/how-to-customize-a-system-provided-binding.md).  
   
 > [!NOTE]
->  When calling a WCF service built with .Net Framework 4.0 or later from a WCF client application built with [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] or earlier, the configuration file generated by svcutil.exe or adding a service reference from Visual Studio will contain the validity attribute in the binding configuration. This attribute is not recognized by the [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] runtime and the application will thrown an <xref:System.Configuration.ConfigurationErrorsException> with the message "Unrecognized attribute validity". To workaround this problem, remove the validity attribute from the binding configuration.  
+>  When calling a WCF service built with .NET Framework 4.0 or later from a WCF client application built with [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] or earlier, the configuration file generated by svcutil.exe or adding a service reference from Visual Studio will contain the validity attribute in the binding configuration. This attribute is not recognized by the [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] runtime and the application will thrown an <xref:System.Configuration.ConfigurationErrorsException> with the message "Unrecognized attribute validity". To workaround this problem, remove the validity attribute from the binding configuration.  
   
    
   

xml/System.ServiceModel/NetTcpContextBinding.xml

@@ -30,7 +30,7 @@
 ## Remarks  
   
 > [!NOTE]
->  When calling a WCF service built with .Net Framework 4.0 or later from a WCF client application built with .NET Framework 3.5 or earlier, the configuration file generated by svcutil.exe or adding a service reference from Visual Studio will contain the contextManagementEnabled attribute in the binding configuration. This attribute is not recognized by the [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] runtime and the application will thrown an <xref:System.Configuration.ConfigurationErrorsException> with the message "Unrecognized attribute 'contextManagementEnabled". To workaround this problem, remove the contextManagementEnabled attribute from the binding configuration.  
+>  When calling a WCF service built with .NET Framework 4.0 or later from a WCF client application built with .NET Framework 3.5 or earlier, the configuration file generated by svcutil.exe or adding a service reference from Visual Studio will contain the contextManagementEnabled attribute in the binding configuration. This attribute is not recognized by the [!INCLUDE[netfx35_short](~/includes/netfx35-short-md.md)] runtime and the application will thrown an <xref:System.Configuration.ConfigurationErrorsException> with the message "Unrecognized attribute 'contextManagementEnabled". To workaround this problem, remove the contextManagementEnabled attribute from the binding configuration.  
   
  ]]></format>
     </remarks>

xml/System.Xml.Serialization.Configuration/DateTimeSerializationSection+DateTimeSerializationMode.xml

@@ -21,7 +21,7 @@
 ## Remarks  
  This enumeration is used by the serialization infrastructure only, and is not intended for public use. To actually set the serialization mode, create an application configuration file, and set the [<dateTimeSerialization> Element](~/docs/standard/serialization/datetimeserialization-element.md) to an appropriate setting. For more information about configuration files, see [Configuration File Schema](~/docs/framework/configure-apps/file-schema/index.md).  
   
- In versions 1.0 and 1.1 of .NET Framework, as well as in versions 2.0 and later when this property is set to `Local`, <xref:System.DateTime> objects are always formatted as the local time. That is, local time zone information is always included with the serialized data. Set this property to `Local` to ensure compatibility with older versions of the .Net Framework.  
+ In versions 1.0 and 1.1 of .NET Framework, as well as in versions 2.0 and later when this property is set to `Local`, <xref:System.DateTime> objects are always formatted as the local time. That is, local time zone information is always included with the serialized data. Set this property to `Local` to ensure compatibility with older versions of the .NET Framework.  
   
  In versions 2.0 and later of the .NET Framework, with this property set to `Roundtrip`<xref:System.DateTime> objects are examined to determine whether they are in the local, UTC or an unspecified time zone, and are serialized in such a way that this information is preserved. This is the default behavior and is recommended for all new applications that do not communicate with older versions of the framework.  
   

xml/System.Xml.Serialization.Configuration/SchemaImporterExtensionElement.xml

@@ -22,7 +22,7 @@
 ## Remarks  
  This class is used by the serialization infrastructure to handle the configuration elements and cannot be used directly. For more information about configuration files, see [Configuration File Schema](~/docs/framework/configure-apps/file-schema/index.md).  
   
- Instead, to configure the <xref:System.Xml.Serialization.XmlSchemaImporter>, create an application configuration file and use the following XML elements to specify types used by the class when mapping XSD types to .Net Framework types:  
+ Instead, to configure the <xref:System.Xml.Serialization.XmlSchemaImporter>, create an application configuration file and use the following XML elements to specify types used by the class when mapping XSD types to .NET Framework types:  
   
 -   [&lt;system.xml.serialization&gt; Element](~/docs/standard/serialization/system-xml-serialization-element.md)  
   

xml/System.Xml.Serialization.Configuration/SchemaImporterExtensionsSection.xml

@@ -22,7 +22,7 @@
 ## Remarks  
  This class is used by the serialization infrastructure to handle the configuration elements and cannot be used directly.  
   
- Instead, to configure the <xref:System.Xml.Serialization.XmlSchemaImporter>, create an application configuration file and use the following XML elements to specify types used by the class when mapping XSD types to .Net Framework types:  
+ Instead, to configure the <xref:System.Xml.Serialization.XmlSchemaImporter>, create an application configuration file and use the following XML elements to specify types used by the class when mapping XSD types to .NET Framework types:  
   
 -   [&lt;system.xml.serialization&gt; Element](~/docs/standard/serialization/system-xml-serialization-element.md)