Change references from .NET Framework to .NET (where appropriate) (#16629)

* Change references from .NET Framework to .NET (where appropriate)

* Change references from .NET Framework to .NET (where appropriate)

Author: Thraka

docs/desktop-wpf/xaml-services/basic-reading-writing.md

@@ -8,7 +8,7 @@ ms.assetid: 6ac27fad-3687-4d7a-add1-3e90675fdfde
 ---
 # XAMLServices class and basic XAML reading or writing
 
-<xref:System.Xaml.XamlServices> is a class provided by .NET Framework XAML Services that can be used to address XAML scenarios that don't require specific access to the XAML node stream or to XAML type system information obtained from those nodes. <xref:System.Xaml.XamlServices> API can be summarized as follows: `Load` or `Parse` to support a XAML load path, `Save` to support a XAML save path, and `Transform` to provide a technique that joins a load path and save path. `Transform` can be used to change from one XAML schema to another. This topic summarizes each of these API classifications and describes the differences between particular method overloads.  
+<xref:System.Xaml.XamlServices> is a class provided by .NET that can be used to address XAML scenarios that don't require specific access to the XAML node stream or to XAML type system information obtained from those nodes. <xref:System.Xaml.XamlServices> API can be summarized as follows: `Load` or `Parse` to support a XAML load path, `Save` to support a XAML save path, and `Transform` to provide a technique that joins a load path and save path. `Transform` can be used to change from one XAML schema to another. This topic summarizes each of these API classifications and describes the differences between particular method overloads.  
 
 <a name="load"></a>   
 ## Load  
@@ -19,7 +19,7 @@ The simplest overload for most scenarios is <xref:System.Xaml.XamlServices.Load%
 
 <xref:System.Xaml.XamlServices.Load%28System.IO.Stream%29> has similar scenarios. This overload might be useful if you have the user choose files to load, because a <xref:System.IO.Stream> is a frequent output of other <xref:System.IO> APIs that can access a file system. Or you could be accessing XAML sources through asynchronous downloads or other network techniques that also provide a stream. (Loading from a stream or user-selected source may have security implications. For more information, see [XAML Security Considerations](security-considerations.md).)  
 
-<xref:System.Xaml.XamlServices.Load%28System.IO.TextReader%29> and <xref:System.Xaml.XamlServices.Load%28System.Xml.XmlReader%29> are overloads that rely on readers of formats from previous versions of the .NET Framework. To use these overloads, you should have already created a reader instance and used its `Create` API to load the XAML in the relevant form (text or XML). If you have already moved record pointers in the other readers or performed other operations with them, this is not important. The load path logic from <xref:System.Xaml.XamlServices.Load%2A> always processes the entire XAML input from the root down. The following scenarios might warrant the use of these overloads:  
+<xref:System.Xaml.XamlServices.Load%28System.IO.TextReader%29> and <xref:System.Xaml.XamlServices.Load%28System.Xml.XmlReader%29> are overloads that rely on readers of formats from previous versions of .NET. To use these overloads, you should have already created a reader instance and used its `Create` API to load the XAML in the relevant form (text or XML). If you have already moved record pointers in the other readers or performed other operations with them, this is not important. The load path logic from <xref:System.Xaml.XamlServices.Load%2A> always processes the entire XAML input from the root down. The following scenarios might warrant the use of these overloads:  
 
 - Design surfaces where you provide simple XAML editing capability from an existing XML-specific text editor.  
 

docs/desktop-wpf/xaml-services/clr-attributes-with-custom-types-and-libraries.md

@@ -7,10 +7,10 @@ ms.assetid: 5dfb299a-b6e2-41b8-8694-e6ac987547f1
 ---
 # XAML-related CLR attributes for custom types and libraries
 
-This topic describes the common language runtime (CLR) attributes that are defined by .NET Framework XAML Services. It also describes other CLR attributes that are defined in the .NET Framework that have a XAML-related scenario for application to assemblies or types. Attributing assemblies, types, or members with these CLR attributes provides XAML type system information related to your types. Information is provided to any XAML consumer that uses .NET Framework XAML Services for processing the XAML node stream directly or through the dedicated XAML readers and XAML writers.  
+This topic describes the common language runtime (CLR) attributes that are defined by .NET XAML Services. It also describes other CLR attributes that are defined in .NET that have a XAML-related scenario for application to assemblies or types. Attributing assemblies, types, or members with these CLR attributes provides XAML type system information related to your types. Information is provided to any XAML consumer that uses .NET XAML Services for processing the XAML node stream directly or through the dedicated XAML readers and XAML writers.  
 
 ## XAML-Related CLR Attributes for Custom Types and Custom Members  
- Using CLR attributes entails that you are using the overall CLR to define your types, otherwise such attributes are not available. If you use the CLR to define type backing, then the default XAML schema context used by .NET  Framework XAML Services XAML writers can read CLR attribution through reflection against backing assemblies.  
+ Using CLR attributes entails that you are using the overall CLR to define your types, otherwise such attributes are not available. If you use the CLR to define type backing, then the default XAML schema context used by .NET XAML Services XAML writers can read CLR attribution through reflection against backing assemblies.  
 
  The following sections describe the XAML-related attributes that you can apply to custom types or custom members. Each CLR attribute communicates information that is relevant to a XAML type system. In the load path, the attributed information either helps the XAML reader form a valid XAML node stream, or it helps the XAML writer produce a valid object graph. In the save path, the attributed information either helps the XAML reader form a valid XAML node stream that reconstitutes XAML type system information; or it declares serialization hints or requirements for the XAML writer or other XAML consumers.  
 
@@ -128,7 +128,7 @@ This topic describes the common language runtime (CLR) attributes that are defin
 
  A type converter behavior for XAML usage of a custom attachable member can be assigned by applying <xref:System.ComponentModel.TypeConverterAttribute> to the `get` method accessor that supports the XAML usage.  
 
- Similar to <xref:System.ComponentModel.TypeConverter>, <xref:System.ComponentModel.TypeConverterAttribute> existed in the .NET Framework prior to the existence of XAML, and the type converter model served other purposes. In order to reference and use <xref:System.ComponentModel.TypeConverterAttribute>, you must fully qualify it or provide a `using` statement for <xref:System.ComponentModel>. Also include the System assembly in your project.  
+ Similar to <xref:System.ComponentModel.TypeConverter>, <xref:System.ComponentModel.TypeConverterAttribute> existed in .NET prior to the existence of XAML, and the type converter model served other purposes. In order to reference and use <xref:System.ComponentModel.TypeConverterAttribute>, you must fully qualify it or provide a `using` statement for <xref:System.ComponentModel>. Also include the System assembly in your project.  
 
 ### UidPropertyAttribute  
  **Reference Documentation:**  <xref:System.Windows.Markup.UidPropertyAttribute>  
@@ -207,7 +207,7 @@ This topic describes the common language runtime (CLR) attributes that are defin
  The definition inherits to all derived types that are assignable to the defining type. You can override the definition on a specific derived type by applying <xref:System.Windows.Markup.XmlLangPropertyAttribute> on the specific derived type, although that is an uncommon scenario.  
 
 ## XAML-Related CLR Attributes at the Assembly Level  
- The following sections describe the XAML-related attributes that are not applied to types or member definitions, but are instead applied to assemblies. These attributes are pertinent to the overall goal of defining a library that contains custom types to use in XAML. Some of the attributes do not necessarily influence the XAML node stream directly, but are passed on in the node stream for other consumers to use. Consumers for the information include design environments or serialization processes that need XAML namespace information and associated prefix information. A XAML schema context (including the .NET Framework XAML Services default) also uses this information.  
+ The following sections describe the XAML-related attributes that are not applied to types or member definitions, but are instead applied to assemblies. These attributes are pertinent to the overall goal of defining a library that contains custom types to use in XAML. Some of the attributes do not necessarily influence the XAML node stream directly, but are passed on in the node stream for other consumers to use. Consumers for the information include design environments or serialization processes that need XAML namespace information and associated prefix information. A XAML schema context (including the .NET XAML Services default) also uses this information.  
 
 ### XmlnsCompatibleWithAttribute  
  **Reference Documentation:**  <xref:System.Windows.Markup.XmlnsCompatibleWithAttribute>  
@@ -250,7 +250,7 @@ This topic describes the common language runtime (CLR) attributes that are defin
 
 - A string that specifies a recommended prefix.  
 
- <xref:System.Windows.Markup.XmlnsDefinitionAttribute> specifies a recommended prefix to use for a XAML namespace. The prefix is useful when writing elements and attributes in a XAML file that is serialized by the .NET Framework XAML Services <xref:System.Xaml.XamlXmlWriter>, or when a XAML-implementing library interacts with a design environment that has XAML editing features.  
+ <xref:System.Windows.Markup.XmlnsDefinitionAttribute> specifies a recommended prefix to use for a XAML namespace. The prefix is useful when writing elements and attributes in a XAML file that is serialized by .NET XAML Services <xref:System.Xaml.XamlXmlWriter>, or when a XAML-implementing library interacts with a design environment that has XAML editing features.  
 
  More than one <xref:System.Windows.Markup.XmlnsPrefixAttribute> can be applied to an assembly. This might be done for any combination of the following reasons:  
 
@@ -261,9 +261,9 @@ This topic describes the common language runtime (CLR) attributes that are defin
 - You define XAML language support in the assembly and have a <xref:System.Windows.Markup.XmlnsDefinitionAttribute> for `http://schemas.microsoft.com/winfx/2006/xaml`. In this case, you typically should promote the prefix `x`.  
 
 > [!NOTE]
-> .NET Framework XAML Services also defines the XAML-related attribute <xref:System.Windows.Markup.RootNamespaceAttribute>. This attribute is an assembly-level attribute for project system support, and it is not relevant for XAML custom types.  
+> .NET XAML Services also defines the XAML-related attribute <xref:System.Windows.Markup.RootNamespaceAttribute>. This attribute is an assembly-level attribute for project system support, and it is not relevant for XAML custom types.  
   
 ## See also
 
 - <xref:System.Attribute>
-- [Defining Custom Types for Use with .NET Framework XAML Services](define-custom-types.md)
+- [Defining Custom Types for Use with .NET XAML Services](define-custom-types.md)

docs/desktop-wpf/xaml-services/collections-and-types.md

@@ -13,32 +13,32 @@ Conceptually, any relationship in XAML where there are multiple child items with
 
 At the XAML language level, the exact requirements of collection support are not fully defined. The concept that a collection can be either a list or a dictionary(but not both) is defined at the XAML language level, but which backing types represent either lists or dictionaries is not defined by the XAML language.
 
-In .NET Framework XAML Services, the concept of XAML collection support is more clearly defined in terms of .NET Framework backing types. Specifically, the XAML support for collections is based on several .NET Framework concepts and APIs that are used for lists and dictionaries in general .NET Framework programming.
+In .NET XAML Services, the concept of XAML collection support is more clearly defined in terms of .NET backing types. Specifically, the XAML support for collections is based on several .NET concepts and APIs that are used for lists and dictionaries in general .NET programming.
 
 1. The <xref:System.Collections.IList> interface indicates a list collection.
 
 2. The <xref:System.Collections.IDictionary> interface indicates a dictionary collection.
 
 3. <xref:System.Array> represents an array, and an array supports <xref:System.Collections.IList> methods.
 
-In each of these collection concepts, a .NET Framework XAML Services XAML processor expects to call the `Add` method on a specific instance of the collection property's type. Or, in a serialization scenario, a XAML processor produces discrete XAML-type instances for each item found in the list, dictionary, or array based on each collection's specific concept of "Items". These items are: <xref:System.Collections.IList.Item%2A?displayProperty=nameWithType>; <xref:System.Collections.IDictionary.Item%2A?displayProperty=nameWithType>; the explicit <xref:System.Array.System%23Collections%23IList%23Item%2A?displayProperty=nameWithType> for <xref:System.Array>.
+In each of these collection concepts, a .NET XAML Services XAML processor expects to call the `Add` method on a specific instance of the collection property's type. Or, in a serialization scenario, a XAML processor produces discrete XAML-type instances for each item found in the list, dictionary, or array based on each collection's specific concept of "Items". These items are: <xref:System.Collections.IList.Item%2A?displayProperty=nameWithType>; <xref:System.Collections.IDictionary.Item%2A?displayProperty=nameWithType>; the explicit <xref:System.Array.System%23Collections%23IList%23Item%2A?displayProperty=nameWithType> for <xref:System.Array>.
 
 ## Generic Collections
 
-Generic collections can be useful for general .NET Framework programming, and can also be used for XAML collection properties. However, the generic interfaces <xref:System.Collections.Generic.IList%601> and <xref:System.Collections.Generic.IDictionary%602> are not identified by .NET Framework XAML Services XAML processors as being equivalent to the non-generic <xref:System.Collections.IList> or <xref:System.Collections.IDictionary>. Rather than implementing the interfaces, a recommended approach for generic collection property types is to derive from the classes <xref:System.Collections.Generic.List%601> or <xref:System.Collections.Generic.Dictionary%602>. These classes implement the non-generic interfaces and thus include the expected support for XAML collections in the base implementation.
+Generic collections can be useful for general .NET programming, and can also be used for XAML collection properties. However, the generic interfaces <xref:System.Collections.Generic.IList%601> and <xref:System.Collections.Generic.IDictionary%602> are not identified by .NET XAML Services XAML processors as being equivalent to the non-generic <xref:System.Collections.IList> or <xref:System.Collections.IDictionary>. Rather than implementing the interfaces, a recommended approach for generic collection property types is to derive from the classes <xref:System.Collections.Generic.List%601> or <xref:System.Collections.Generic.Dictionary%602>. These classes implement the non-generic interfaces and thus include the expected support for XAML collections in the base implementation.
 
 ## Read-Only Collections and Initialization Logic
 
-In .NET Framework programming, it is a common design pattern to make any property that holds a value of a collection as a read-only collection. This pattern permits the instance that owns the collection property to better control what happens to the collection.. Specifically, the pattern prevents accidental replacement of the entire pre-existing collection by setting the property. In this pattern, any access to the collection by callers should instead be made by calling methods or properties as supported by the collection type and/or the relevant collection interfaces such as <xref:System.Collections.IList>.
+In .NET programming, it is a common design pattern to make any property that holds a value of a collection as a read-only collection. This pattern permits the instance that owns the collection property to better control what happens to the collection.. Specifically, the pattern prevents accidental replacement of the entire pre-existing collection by setting the property. In this pattern, any access to the collection by callers should instead be made by calling methods or properties as supported by the collection type and/or the relevant collection interfaces such as <xref:System.Collections.IList>.
 
 Using this pattern implies that any class that exposes a read-only collection property must first initialize that property to hold an empty collection. Typically the initialization is performed as part of the construction behavior for the class. To be useful for XAML, it is important that such logic is always referenced by the parameterless constructor, because XAML generally calls the parameterless constructor prior to processing the properties (collection properties or otherwise).
 
 ## XAML Type System Support and Collections
 
-Beyond the basic mechanics of parsing XAML and populating or serializing collection properties, the XAML type system as implemented in .NET Framework XAML Services includes several design features that pertain to collections in XAML.
+Beyond the basic mechanics of parsing XAML and populating or serializing collection properties, the XAML type system as implemented in .NET XAML Services includes several design features that pertain to collections in XAML.
 
 1. <xref:System.Xaml.XamlType.IsCollection%2A> returns true if the XAML type is backed by a type that provides XAML collection support.
 
-2. <xref:System.Xaml.XamlType.IsDictionary%2A> and <xref:System.Xaml.XamlType.IsArray%2A> can further identify which collection mode the XAML type supports. For custom XAML processors that are based on .NET Framework XAML Services and the XAML type system but not based on existing <xref:System.Xaml.XamlWriter> implementations, knowing which collection mode is used might be necessary in order to know which method to invoke for collection processing.
+2. <xref:System.Xaml.XamlType.IsDictionary%2A> and <xref:System.Xaml.XamlType.IsArray%2A> can further identify which collection mode the XAML type supports. For custom XAML processors that are based on .NET XAML Services and the XAML type system but not based on existing <xref:System.Xaml.XamlWriter> implementations, knowing which collection mode is used might be necessary in order to know which method to invoke for collection processing.
 
 3. Each of the previous property values is potentially influenced by overrides of <xref:System.Xaml.XamlType.LookupCollectionKind%2A> on a XAML type.