diff --git a/dotnet-desktop-guide/xaml-services/index.md b/dotnet-desktop-guide/xaml-services/index.md index ff81dd998e..58905c6511 100644 --- a/dotnet-desktop-guide/xaml-services/index.md +++ b/dotnet-desktop-guide/xaml-services/index.md @@ -29,7 +29,7 @@ Conceptual documentation for .NET XAML Services assumes that you have previous e - Using the `Lookup` or `Invoker` techniques to influence the XAML type system and how type backings are evaluated. -If you are looking for introductory material on XAML as a language, you might try [XAML Overview (WPF)](../net/wpf/fundamentals/xaml.md). That topic discusses XAML for an audience that is new both to Windows Presentation Foundation (WPF) and also to using XAML markup and XAML language features. Another useful document is the introductory material in the [XAML language specification](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +If you are looking for introductory material on XAML as a language, you might try [XAML Overview (WPF)](../net/wpf/fundamentals/xaml.md). That topic discusses XAML for an audience that is new both to Windows Presentation Foundation (WPF) and also to using XAML markup and XAML language features. Another useful document is the introductory material in the [XAML language specification](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ## .NET XAML Services and `System.Xaml` in the .NET Architecture diff --git a/dotnet-desktop-guide/xaml-services/type-converters-overview.md b/dotnet-desktop-guide/xaml-services/type-converters-overview.md index 40539e94fb..672a07be44 100644 --- a/dotnet-desktop-guide/xaml-services/type-converters-overview.md +++ b/dotnet-desktop-guide/xaml-services/type-converters-overview.md @@ -60,7 +60,7 @@ The second-most important method is implementation can uniquely interpret what is a valid string for a conversion, and it can also use or ignore the type description that is passed as parameters. An important consideration for culture and XAML type conversion is the following: although using localizable strings as attribute values is supported by XAML, you cannot use these localizable strings as type converter input with specific culture requirements. This limitation is because type converters for XAML attribute values involve a necessarily fixed-language XAML-processing behavior that uses `en-US` culture. For more information about the design reasons for this restriction, see the XAML language specification ([\[MS-XAML\]](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10))) or [WPF Globalization and Localization Overview](../framework/wpf/advanced/wpf-globalization-and-localization-overview.md). +Each implementation can uniquely interpret what is a valid string for a conversion, and it can also use or ignore the type description that is passed as parameters. An important consideration for culture and XAML type conversion is the following: although using localizable strings as attribute values is supported by XAML, you cannot use these localizable strings as type converter input with specific culture requirements. This limitation is because type converters for XAML attribute values involve a necessarily fixed-language XAML-processing behavior that uses `en-US` culture. For more information about the design reasons for this restriction, see the XAML language specification ([\[MS-XAML\]](/previous-versions/msp-n-p/ff650760(v=pandp.10))) or [WPF Globalization and Localization Overview](../framework/wpf/advanced/wpf-globalization-and-localization-overview.md). As an example where culture can be an issue, some cultures use a comma instead of a period as the decimal point delimiter for numbers in string form. This use collides with the behavior that many existing type converters have, which is to use a comma as a delimiter. Passing a culture through `xml:lang` in the surrounding XAML does not solve the issue. diff --git a/dotnet-desktop-guide/xaml-services/types-for-primitives.md b/dotnet-desktop-guide/xaml-services/types-for-primitives.md index 6dc692024d..475e2e4c88 100644 --- a/dotnet-desktop-guide/xaml-services/types-for-primitives.md +++ b/dotnet-desktop-guide/xaml-services/types-for-primitives.md @@ -48,19 +48,19 @@ This primitive is not typically used in application markup, but might be useful For CLR backing, the `x:Boolean` primitive corresponds to . -XAML parses values for `x:Boolean` as case insensitive. Note that `x:Bool` is not an accepted alternative. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.17 and 5.4.11](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +XAML parses values for `x:Boolean` as case insensitive. Note that `x:Bool` is not an accepted alternative. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.17 and 5.4.11](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Char For CLR backing, the `x:Char` primitive corresponds to . -String and char types have interaction with the overall encoding of the file at the XML level. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.7 and 5.4.1](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +String and char types have interaction with the overall encoding of the file at the XML level. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.7 and 5.4.1](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:String For CLR backing, the `x:String` primitive corresponds to . -String and char types have interaction with the overall encoding of the file at the XML level. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.6](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +String and char types have interaction with the overall encoding of the file at the XML level. For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.6](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Decimal @@ -68,7 +68,7 @@ For CLR backing, the `x:Decimal` primitive corresponds to . XAML parsing is inherently done under `en-US` culture. Under `en-US` culture, the correct separator for the components of a decimal is always a period (`.`) regardless of culture settings of the development environment, or of the eventual client target where the XAML is loaded at run time. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.14 and 5.4.8](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.14 and 5.4.8](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Single @@ -78,7 +78,7 @@ In addition to the numeric values, text syntax for `x:Single` also permits the t `x:Single` can support values in scientific notation form, if the first character in text syntax is `e` or `E`. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.8 and 5.4.2](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.8 and 5.4.2](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Double @@ -88,25 +88,25 @@ In addition to the numeric values, text syntax for `x:Double` permits the tokens `x:Double` can support values in scientific notation form. Use the character `e` or `E` to introduce the exponent portion. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.9 and 5.4.3](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.9 and 5.4.3](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Int16 For CLR backing, the `x:Int16` primitive corresponds to and `x:Int16` is treated as signed. In XAML, the absence of a plus (`+`) sign in text syntax is implied as a positive signed value. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.11 and 5.4.5](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.11 and 5.4.5](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Int32 For CLR backing, the `x:Int32` primitive corresponds to . `x:Int32` is treated as signed. In XAML, the absence of a plus (`+`) sign in text syntax is implied as a positive signed value. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.12 and 5.4.6](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.12 and 5.4.6](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Int64 For CLR backing, the `x:Int64` primitive corresponds to . `x:Int64` is treated as signed. In XAML, the absence of a plus (`+`) sign in text syntax is implied as a positive signed value. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.13 and 5.4.7](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.13 and 5.4.7](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:TimeSpan @@ -114,7 +114,7 @@ For CLR backing, the `x:TimeSpan` primitive corresponds to . Checking for protocols is not part of the XAML definition for `x:Uri`. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.15 and 5.4.9](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.15 and 5.4.9](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Byte For CLR backing, the `x:Byte` primitive corresponds to . A / `x:Byte` is treated as unsigned. -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.10 and 5.4.4](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.10 and 5.4.4](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ### x:Array @@ -136,7 +136,7 @@ For CLR backing, the `x:Array` primitive corresponds to . You can define an array in XAML 2006 by using a markup extension syntax; however, the XAML 2009 syntax is a language-defined primitive that does not require accessing a markup extension. For more information about XAML 2006 support, see [x:Array Markup Extension](xarray-markup-extension.md). -For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.18](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the XAML language specification definition, see [\[MS-XAML\] Sections 5.2.18](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ## WPF Support diff --git a/dotnet-desktop-guide/xaml-services/xamlname-grammar.md b/dotnet-desktop-guide/xaml-services/xamlname-grammar.md index 611a4ebb5c..d8a6524384 100644 --- a/dotnet-desktop-guide/xaml-services/xamlname-grammar.md +++ b/dotnet-desktop-guide/xaml-services/xamlname-grammar.md @@ -52,4 +52,4 @@ DottedXamlName ::= XamlName '.' XamlName ## Remarks -For the complete specification, see [\[MS-XAML\]](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +For the complete specification, see [\[MS-XAML\]](/previous-versions/msp-n-p/ff650760(v=pandp.10)). diff --git a/dotnet-desktop-guide/xaml-services/xclass-directive.md b/dotnet-desktop-guide/xaml-services/xclass-directive.md index cb63088585..5ff855dc61 100644 --- a/dotnet-desktop-guide/xaml-services/xclass-directive.md +++ b/dotnet-desktop-guide/xaml-services/xclass-directive.md @@ -12,6 +12,7 @@ helpviewer_keywords: ms.assetid: bc4a3d8e-76e2-423e-a5d1-159a023e82ec --- # x:Class Directive + Configures XAML markup compilation to join partial classes between markup and code-behind. The code partial class is defined in a separate code file in a Common Language Specification (CLS) language, whereas the markup partial class is typically created by code generation during XAML compilation. ## XAML Attribute Usage @@ -31,7 +32,7 @@ Configures XAML markup compilation to join partial classes between markup and co ## Dependencies -`x:Class` can only be specified on the root element of a XAML production. `x:Class` is invalid on any object that has a parent in the XAML production. For more information, see [\[MS-XAML\] Section 4.3.1.6](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +`x:Class` can only be specified on the root element of a XAML production. `x:Class` is invalid on any object that has a parent in the XAML production. For more information, see [\[MS-XAML\] Section 4.3.1.6](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ## Remarks @@ -43,7 +44,7 @@ The value of the `x:Class` directive must be a string that specifies the fully q The code-behind file for a page or application definition must be within a code file that is included as part of the project that produces a compiled application and involves markup compilation. You must follow name rules for CLR classes. For more information, see [Framework Design Guidelines](/dotnet/api/). By default, the code-behind class must be `public`; however, you can define it at a different access level by using the [x:ClassModifier Directive](xclassmodifier-directive.md). -This interpretation of the `x:Class` attribute applies only to a CLR-based XAML implementation, in particular to .NET XAML Services. Other XAML implementations that are not based on CLR and that do not use .NET XAML Services might use a different resolution formula for connecting XAML markup and backing run-time code. For more information about more general interpretations of `x:Class`, see [\[MS-XAML\]](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +This interpretation of the `x:Class` attribute applies only to a CLR-based XAML implementation, in particular to .NET XAML Services. Other XAML implementations that are not based on CLR and that do not use .NET XAML Services might use a different resolution formula for connecting XAML markup and backing run-time code. For more information about more general interpretations of `x:Class`, see [\[MS-XAML\]](/previous-versions/msp-n-p/ff650760(v=pandp.10)). At a certain level of architecture, the meaning of `x:Class` is undefined in .NET XAML Services. This is because .NET XAML Services does not specify the programming model by which XAML markup and backing code are connected. Additional uses of the `x:Class` directive might be implemented by specific frameworks that use programming models or application models to define how to connect XAML markup and CLR-based code-behind. Each framework can have its own build actions that enable some of the behavior or specific components that must be included in the build environment. Within a framework, build actions can also vary depending on the specific CLR language that is used for the code-behind. @@ -52,11 +53,12 @@ At a certain level of architecture, the meaning of `x:Class` is undefined in .NE In WPF applications and the WPF application model, `x:Class` can be declared as an attribute for any element that is the root of a XAML file and is being compiled (where the XAML is included in a WPF application project with `Page` build action), or for the root in the application definition of a compiled WPF application. Declaring `x:Class` on an element other than a page root or application root, or on a WPF XAML file that is not compiled, causes a compile-time error under the .NET Framework 3.0 and .NET Framework 3.5 WPF XAML compiler. For information about other aspects of `x:Class` handling in WPF, see [Code-Behind and XAML in WPF](../framework/wpf/advanced/code-behind-and-xaml-in-wpf.md). ## x:Class for Windows Workflow Foundation + For Windows Workflow Foundation, `x:Class` names the class of a custom activity composed entirely in XAML, or names the partial class of the XAML page for an activity designer with code-behind. ## Silverlight Usage Notes -`x:Class` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](https://docs.microsoft.com/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). +`x:Class` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). ## See also diff --git a/dotnet-desktop-guide/xaml-services/xclassmodifier-directive.md b/dotnet-desktop-guide/xaml-services/xclassmodifier-directive.md index c5b7ab4732..32f1318f15 100644 --- a/dotnet-desktop-guide/xaml-services/xclassmodifier-directive.md +++ b/dotnet-desktop-guide/xaml-services/xclassmodifier-directive.md @@ -12,6 +12,7 @@ helpviewer_keywords: ms.assetid: ef30ab78-d334-4668-917d-c9f66c3b6aea --- # x:ClassModifier Directive + Modifies XAML compilation behavior when `x:Class` is also provided. Specifically, instead of creating a partial `class` that has a `Public` access level (the default), the provided `x:Class` is created with a `NotPublic` access level. This behavior affects the access level for the class in the generated assemblies. ## XAML Attribute Usage @@ -30,7 +31,7 @@ Modifies XAML compilation behavior when `x:Class` is also provided. Specifically ## Dependencies -[x:Class](xclass-directive.md) must also be provided on the same element, and that element must be the root element in a page. For more information, see [\[MS-XAML\] Section 4.3.1.8](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +[x:Class](xclass-directive.md) must also be provided on the same element, and that element must be the root element in a page. For more information, see [\[MS-XAML\] Section 4.3.1.8](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ## Remarks diff --git a/dotnet-desktop-guide/xaml-services/xkey-directive.md b/dotnet-desktop-guide/xaml-services/xkey-directive.md index e257c31643..8c4d726e53 100644 --- a/dotnet-desktop-guide/xaml-services/xkey-directive.md +++ b/dotnet-desktop-guide/xaml-services/xkey-directive.md @@ -12,6 +12,7 @@ helpviewer_keywords: ms.assetid: 1985cd45-f197-42d5-b75e-886add64b248 --- # x:Key Directive + Uniquely identifies elements that are created and referenced in a XAML-defined dictionary. Adding an `x:Key` value to a XAML object element is the most common way to identify a resource in a resource dictionary, for example in a WPF . ## XAML Attribute Usage @@ -42,6 +43,7 @@ Uniquely identifies elements that are created and referenced in a XAML-defined d |`markupExtensionUsage`|Within the markup extension delimiters {}, a markup extension usage that provides an object to use as a key. See Remarks.| ## Remarks + `x:Key` supports the XAML resource dictionary concept. XAML as a language doesn't define a resource dictionary implementation, that is left to specific UI frameworks. To learn more about how XAML resource dictionaries are implemented in WPF, see [XAML Resources](../net/wpf/fundamentals/xaml-resources-define.md). In XAML 2006 and WPF, `x:Key` must be provided as an attribute. You can still use nonstring keys, but this requires a markup extension usage in order to provide the nonstring value in attribute form. If you are using XAML 2009, `x:Key` can be specified as an element, to explicitly support dictionaries keyed by object types other than strings without requiring a markup extension intermediate. See the "XAML 2009" section in this topic. The remainder of the Remarks section applies specifically to the XAML 2006 implementation. @@ -53,6 +55,7 @@ Uniquely identifies elements that are created and referenced in a XAML-defined d The code equivalent of specifying `x:Key` is the key that is used for the underlying . For example, an `x:Key` that is applied in markup for a resource in WPF is equivalent to the value of the `key` parameter of when you add the resource to a WPF in code. ## WPF Usage Notes + Child objects of a parent object that is an implementation, such as the WPF , must typically include an `x:Key` attribute, and the key value must be unique within that dictionary. There are two notable exceptions: - Some WPF types declare an implicit key for dictionary usage. For example, a with a , or a with a , can be in a and use the implicit key. @@ -72,6 +75,7 @@ Uniquely identifies elements that are created and referenced in a XAML-defined d The WPF merged dictionary feature introduces additional considerations for key uniqueness and key lookup behavior. For more information, see [Merged Resource Dictionaries](../framework/wpf/advanced/merged-resource-dictionaries.md). ## XAML 2009 + XAML 2009 relaxes the restriction that `x:Key` always be provided in attribute form. In WPF, you can use XAML 2009 features, but only for XAML that is not markup-compiled. Markup-compiled XAML for WPF and the BAML form of XAML do not currently support the XAML 2009 keywords and features. @@ -102,7 +106,8 @@ keyObject - `keyObject` could also be a markup extension usage in object element form, rather than a direct object instance. ## Silverlight Usage Notes - `x:Key` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](https://docs.microsoft.com/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). + + `x:Key` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). ## See also diff --git a/dotnet-desktop-guide/xaml-services/xmember-directive.md b/dotnet-desktop-guide/xaml-services/xmember-directive.md index 6c395f6e4b..5aa78955f0 100644 --- a/dotnet-desktop-guide/xaml-services/xmember-directive.md +++ b/dotnet-desktop-guide/xaml-services/xmember-directive.md @@ -4,6 +4,7 @@ ms.date: "03/30/2017" ms.assetid: 4d8394ef-644c-4331-b6c5-be855d392980 --- # x:Member Directive + Declares a XAML member in markup. ## XAML Object Element Usage @@ -34,4 +35,4 @@ To support a practical usage of `x:Members` as a means to specify member definit ## x:Property for Windows Workflow Foundation -For Windows Workflow Foundation, `x:Property` defines the members of a custom activity composed entirely in XAML, or XAML –defined dynamic members for an activity designer with code-behind. `x:Class` must also be specified on the root element of the XAML production. This is not a requirement at .NET XAML Services level, but becomes a requirement when the XAML production is loaded by the MSBUILD build actions that support custom activities and Windows Workflow Foundation XAML in general. Windows Workflow Foundation does not use the pure XAML type name as its intended value for the `x:Property` `Type` attribute, and instead uses a convention that is not documented here. For more information, see [DynamicActivity Creation](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/dd807392(v=vs.100)). +For Windows Workflow Foundation, `x:Property` defines the members of a custom activity composed entirely in XAML, or XAML –defined dynamic members for an activity designer with code-behind. `x:Class` must also be specified on the root element of the XAML production. This is not a requirement at .NET XAML Services level, but becomes a requirement when the XAML production is loaded by the MSBUILD build actions that support custom activities and Windows Workflow Foundation XAML in general. Windows Workflow Foundation does not use the pure XAML type name as its intended value for the `x:Property` `Type` attribute, and instead uses a convention that is not documented here. For more information, see [DynamicActivity Creation](/previous-versions/dotnet/netframework-4.0/dd807392(v=vs.100)). diff --git a/dotnet-desktop-guide/xaml-services/xname-directive.md b/dotnet-desktop-guide/xaml-services/xname-directive.md index cc0c975ee9..7d52f4f071 100644 --- a/dotnet-desktop-guide/xaml-services/xname-directive.md +++ b/dotnet-desktop-guide/xaml-services/xname-directive.md @@ -63,7 +63,7 @@ If is available as a property on ## Silverlight Usage Notes -`x:Name` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](https://docs.microsoft.com/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). +`x:Name` for Silverlight is documented separately. For more information, see [XAML Namespace (x:) Language Features (Silverlight)](/previous-versions/windows/silverlight/dotnet-windows-silverlight/cc188995(v=vs.95)). ## See also diff --git a/dotnet-desktop-guide/xaml-services/xproperty-directive.md b/dotnet-desktop-guide/xaml-services/xproperty-directive.md index ad1e90fae9..126b63f50c 100644 --- a/dotnet-desktop-guide/xaml-services/xproperty-directive.md +++ b/dotnet-desktop-guide/xaml-services/xproperty-directive.md @@ -36,4 +36,4 @@ To support a practical usage of `x:Members` as a means to specify member definit ## x:Property for Windows Workflow Foundation -For Windows Workflow Foundation, `x:Property` defines the members of a custom activity composed entirely in XAML, or XAML –defined dynamic members for an activity designer with code-behind. `x:Class` must also be specified on the root element of the XAML production. This is not a requirement at .NET XAML Services level, but becomes a requirement when the XAML production is loaded by the MSBUILD build actions that support custom activities and Windows Workflow Foundation XAML in general. Windows Workflow Foundation does not use the pure XAML type name as its intended value for the `x:Property` `Type` attribute, and instead uses a convention that is not documented here. For more information, see [DynamicActivity Creation](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/dd807392(v=vs.100)). +For Windows Workflow Foundation, `x:Property` defines the members of a custom activity composed entirely in XAML, or XAML –defined dynamic members for an activity designer with code-behind. `x:Class` must also be specified on the root element of the XAML production. This is not a requirement at .NET XAML Services level, but becomes a requirement when the XAML production is loaded by the MSBUILD build actions that support custom activities and Windows Workflow Foundation XAML in general. Windows Workflow Foundation does not use the pure XAML type name as its intended value for the `x:Property` `Type` attribute, and instead uses a convention that is not documented here. For more information, see [DynamicActivity Creation](/previous-versions/dotnet/netframework-4.0/dd807392(v=vs.100)). diff --git a/dotnet-desktop-guide/xaml-services/xtypearguments-directive.md b/dotnet-desktop-guide/xaml-services/xtypearguments-directive.md index cfc09f374a..876007dd69 100644 --- a/dotnet-desktop-guide/xaml-services/xtypearguments-directive.md +++ b/dotnet-desktop-guide/xaml-services/xtypearguments-directive.md @@ -36,7 +36,7 @@ You can specify more than one XAML type name by using a comma delimiter. If the generic constraints themselves use generic types, the nested constraint type arguments can be contained by parentheses (). -Note that this definition of `x:TypeArguments` is specific to .NET XAML Services and using CLR backing. A language-level definition can be found in [\[MS-XAML\] Section 5.3.11](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +Note that this definition of `x:TypeArguments` is specific to .NET XAML Services and using CLR backing. A language-level definition can be found in [\[MS-XAML\] Section 5.3.11](/previous-versions/msp-n-p/ff650760(v=pandp.10)). ## Usage Examples diff --git a/dotnet-desktop-guide/xaml-services/xuid-directive.md b/dotnet-desktop-guide/xaml-services/xuid-directive.md index d46b66afe7..c74d9916a7 100644 --- a/dotnet-desktop-guide/xaml-services/xuid-directive.md +++ b/dotnet-desktop-guide/xaml-services/xuid-directive.md @@ -26,7 +26,7 @@ Provides a unique identifier for markup elements. In many scenarios, this unique ## Remarks -In [MS-XAML], `x:Uid` is defined as a directive. For more information, see [\[MS-XAML\] Section 5.3.6](https://docs.microsoft.com/previous-versions/msp-n-p/ff650760(v=pandp.10)). +In [MS-XAML], `x:Uid` is defined as a directive. For more information, see [\[MS-XAML\] Section 5.3.6](/previous-versions/msp-n-p/ff650760(v=pandp.10)). `x:Uid` is discrete from `x:Name` both because of the stated XAML localization scenario and so that identifiers that are used for localization have no dependencies on the programming model implications of `x:Name`. Also, `x:Name` is governed by the XAML namescope; however, `x:Uid` is not governed by any XAML language defined concept of uniqueness enforcement. XAML processors in a broad sense (processors that are not part of the localization process) are not expected to enforce uniqueness of `x:Uid` values. That responsibility is conceptually on the originator of the values. The expectation of uniqueness of `x:Uid` values within a single XAML source is reasonable for consumers of the values, such as dedicated globalization processes or tools. The typical uniqueness model is that `x:Uid` values are unique within an XML-encoded file that represents XAML.