Importing the correct Namespace into XAML: How hard could it be? :)

Question

The documentation for How to: Import a Namespace into XAML, XAML Namespaces and Namespace Mapping and XmlnsDefinitionAttribute is anemic.

• It doesn't cover a known issue with namespaces in .NET versions <= 4. Please see Microsoft Connect Issue: Reference aliases are ignored on some xaml files.
• Nowhere does the documentation explain how to specify in the Xmlns value which assembly to load if two assemblies share the same name.

I want to break down the expected behavior for XAML under the following namespace shadowing scenarios:

1. Two assemblies with the same name, with the same namespaces, loaded in the same AppDomain, with the same XmlnsDefinitionAttribute mappings.
2. Two assemblies with the same name, with the same namespaces, loaded in the same AppDomain, with different XmlnsDefinitionAttribute mappings.
3. Two assemblies with different names, with the same namespaces, loaded in the same AppDomain, with the same XmlnsDefinitionAttribute mappings.
4. Two assemblies with different names, with the same namespaces, loaded in the same AppDomain, with different XmlnsDefinitionAttribute mappings.

What's the expected behavior in all of these shadowing scenarios?

In addition, I want to call out one scenario specifically that the above 4 cases are intended to address: What is the XAML equivalent to the extern alias C# keyword?  Currently, the only approach I can think of is to extend FooBar in a separate C# class as FooBarExt and use C# to handle the details.  However, this doesn't address the following problem:

• Two assemblies with different names, with the same namespaces, loaded in the same AppDomain, with the same XmlnsDefinitionAttribute mappings.

Under the following scenario:

• FooBar has a ControlTemplate and references an embedded resource ResourceDictionary in its assembly as the default Look & Feel for the control (generic.xaml), and that ResourceDictionary uses XmlnsDefinitionAttributes that are identical across assembly versions, regardless of how the assemblies are named.

Finally, is there some hook somewhere to override a vendor's XmlnsDefinitionAttribute if they do something non-deterministic like Test Cases 1 or 3 above?

The valid business scenario we are addressing is loading two versions of a GridControl in the same composite application.  Since it is a composite application, different groups within an organization migrate to the latest version at different times, as they all have different release schedules in-line with management objectives.  The control is (silently) failing when it tries to load the ControlTemplate, because it is loading the XAML resource from the "older" version of the assembly.  In this scenario, the assemblies are named differently (e.g. Grid.v1.0.dll and Grid.v2.0.dll).

In addition, to be exhaustive, I would like to cover some further test cases:

• The same as above, except find and replace "with the same namespaces" with "with disjoint namespaces".
• The same as above, except find and replace "with the same namespaces" with "with namepaces that have a non-empty intersection and a non-empty symmetric difference".
• Using different AppDomains
• Typical namespace shadowing tests, such as accessibility modifiers (x:ClassModifier and x:FieldModifier), which can change the public interface of a module. e.g. What happens if a private interface becomes protected?  If a protected interface becomes internal?  If internal becomes public?  And the opposite direction.  Will XAML then bind to the namespace that is visible?
• Applying every test involving XmlnsDefinitionAttribute to XmlnsPrefixAttribute as well, to ensure namespace collisions don't happen when serializing to XAML.
• Using assembly aliases to specify which assembly to load when two or more assemblies share the same name

Other real world examples:

• StackOverflow c# - External alias in XAML
• StackOverflow .net - Assembly Alias in XAML
• MSDN WPF Forum: XAML namespace clashes: is there a global:: qualifier in XAML?

Answer 1

I read the MS-XAML v1 and MS-XAML 2009 specifications tonight.  The following areas of the spec deserve more attention.

• Nowhere is "Pack URI Scheme" described.
• Nowhere is Open Packaging Conventions mentioned.
• Nowhere is clr-namespace:Foo;assembly=Bar URI format described.
• Nowhere is clr-namespace:Foo URI format described.
• Nowhere does it mention XmlnsDefinitionAttribute!
• Nowhere does it mention XmlnsPrefixAttribute!
• Nowhere doe it explain what the purpose of XML Namespaces is for in XAML, and its semantics of grouping together a bunch of related CLR namespaces.
• Microsoft is changing the behavior of XAML with regards to assembly aliases in .NET 4.5, but there is no updated language specification to reflect this change.
• Nowhere is the "read-only collection" trick described in John Gossman's blog post "The Attached Behavior Pattern".
• Nowhere does the specification explain the handling of whitespace, such as how to preserve whitespace inside Element.Property notation.
• Nowhere does it explain that System.InvalidOperationException can be thrown with the following error message: "Cannot modify the logical children for this node at this time because a tree walk is in progress."  (Granted, this is perhaps specific to WPF, rather than XAML, but the run-time behavior is mystifying and how to fix it is even more so mystifying: move the visual tree's XAML definition to an external resource dictionary.)

I will try to post some example applications here in succeeding posts, to demonstrate which of the scenarios above are allowed (e.g., compilable) and what the observable behavior is.  What is the best way to write tests for these?  Coded UI Automation Tests?

Answer 2

Please forgive my impatient. That is a so long long post. Could you please tell us what is your question in one sentence, since I find many many "?" in your two posts. 

Thanks. :)

---

Best day, Best life

Answer 3

One sentence: Does XAML have a way to do deterministic namespace resolution, such as the C# namespace resolution rules?