title: Without having the ability to change them, how can you avoid this XAML-caused namespace collision?
body: <p>Unfortunately, due to issues that are frustratingly out of my control, I'm forced to use components with namespaces which I cannot change.  Because of the way they have structured them, it's causing collisions in the generated code-behind.</p>
  
  <p><strong><em>Again, unfortunately, I do not have access to the code which defines these namespaces so they cannot be changed.</strong> Down-voting this does not help anyone, especially without a reason/explanation.  Also, I've also tried demonstrating the issue to the owners explaining why this is a <strong>very bad design</strong>, but I've been told for other reasons, changing them is <strong>not an option</strong>, so I'm forced to find a work-around.</em></p>
  
  <p>Here's a simplified example to illustrate the issue. Consider a solution with two projects, a 'Core' library, and the consuming application:</p>
  
  <p><strong>Items in 'Core' Library</strong></p>
  
  <ul>
  <li><code>ModelA</code> (Namespace: <code>SomeFeature.Core.Models</code>)</li>
  <li><code>ModelB</code> (Namespace: <code>SomeFeature.Core.Models</code>)</li>
  </ul>
  
  <p>**Items in 'ConsumingApp' (References 'Core') **</p>
  
  <ul>
  <li><code>MainWindow</code> (Namespace: <code>ConsumingApp.SomeFeature</code>)</li>
  <li><code>TestControl</code> (Namespace: <code>SomeFeature.Controls</code>)</li>
  </ul>
  
  <p>The cause of the collision can be explained in three steps:</p>
  
  <ol>
  <li><code>SomeFeature</code> is both the root of one namespace, and a child of another</li>
  <li><code>TestControl</code> is defined as being in the rooted version of the namespace (same as the library), not the one <code>MainWindow</code> is in.</li>
  <li>Code-generation ends up placing the generated variables for those XAML elements in the namespace scope of <code>MainWindow</code>, not that matching what's actually in the XAML.</li>
  </ol>
  
  <p>Now if these were manually-defined variables in non-generated code-behind, dealing with this is easy. By simply adding the prefix <code>global::</code> it 'roots' the namespace you're typing, thus removing all ambiguity.</p>
  
  <pre><code>namespace ConsumingApp.SomeFeature{
  
      public partial class MainWindow{
  
          // Note the 'global::' prefix
          global::SomeFeature.Controls.TestControl MainTestControl { get; set; }
      }
  }
  </code></pre>
  
  <p>The above will ensure that it always resolves relative to the global <code>SomeFeature</code> namespace and never the nested <code>ConsumerApp.SomeFeature</code> namespace.  Pretty straight forward.</p>
  
  <p>However, the auto-generated code-behind from the XAML parser doesn't include that <code>global::</code> prefix, so in the generated code, you actually get this:</p>
  
  <pre><code>namespace ConsumingApp.SomeFeature{
  
      public partial class MainWindow{
  
          // Note: without the 'global::' prefix, this resolves to
          // 'ConsumingApp.SomeFeature.Controls.TestControl'
          // which doesn't actually exist, causing the mentioned issue.
          SomeFeature.Controls.TestControl MainTestControl { get; set; }
      }
  }
  </code></pre>
  
  <p>Which results in this error:</p>
  
  <blockquote>
    <p>Error  CS0234  The type or namespace name 'Controls' does not exist in the namespace 'ConsumingApp.SomeFeature' (are you missing an assembly reference?)</p>
  </blockquote>
  
  <p>As noted in the code comments, this is because it's not looking for this class path...</p>
  
  <pre><code>SomeFeature.Controls.TestControl
  </code></pre>
  
  <p>but rather this one:</p>
  
  <pre><code>ConsumingApp.SomeFeature.Controls.TestControl
  </code></pre>
  
  <p>which doesn't exist, ergo the error.</p>
  
  <p>The fix would be to somehow get the auto-generated code to explicitly output the <code>global::</code> but I don't know how to do that, or even if it can be done.</p>
  
  <p>Things I've tried:</p>
  
  <ol>
  <li><strong>Arguing for them to change their namespaces!</strong> <em>(I lost!)</em></li>
  <li>Explicitly referencing the assembly in the XAML import:</li>
  <li>Defining aliases in the non-generated code-behind</li>
  <li>Searching for aliases in the XAML world (not found)</li>
  <li>Avoiding naming the element, and instead manually searching for the control via other properties. <em>(Horrible, but this does work!)</em></li>
  </ol>
  
  <p>So is there anything that can be done here to get the code-generator to include the 'global::' prefix, or is there another way to do this?</p>