10

I find this issue very strange, possibly a XAML/Visual Studio bug. I am hoping someone else finds it less strange and has an explanation for why what I'm doing is wrong, and/or a better work-around than just declaring the resources in a different order.

I have this simple XAML:

<Window x:Class="TestSOAskArrayXaml.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:system="clr-namespace:System;assembly=mscorlib"
        xmlns:local="clr-namespace:TestSOAskArrayXaml"
        Title="MainWindow" Height="350" Width="525">
  <Window.Resources>
    <local:A x:Key="a1"/>
    <x:Array x:Key="listBoxItems" Type="{x:Type system:Double}">
      <system:Double>0.25</system:Double>
    </x:Array>
  </Window.Resources>

  <Grid/>
</Window>

When I attempt to compile the project, I get the following error:

1>...MainWindow.xaml.cs(25,13,25,32): error CS0103: The name 'InitializeComponent' does not exist in the current context

I understand the error's meaning, but not why it happens. The XAML seems fine, there are no errors compiling it, but for some reason the auto-generated .g.i.cs file where InitializeComponent() would normally be put is not being created or used (i.e. even if the file is there from a previous successful compilation, it's still not compiled into the assembly).

If I simply reverse the order of the resources, it works fine:

  <Window.Resources>
    <x:Array x:Key="listBoxItems" Type="{x:Type system:Double}">
      <system:Double>0.25</system:Double>
    </x:Array>
    <local:A x:Key="a1"/>
  </Window.Resources>

Additional information:

  • A is any class in my project. For the purposes of this test, it was declared as class A { }, i.e. an empty class, but I first ran into this problem putting converter instances into the resources.
  • If I use a built-in type instead of A, e.g. <system:String x:Key="a1">Some string</system:String>, the error does not happen.
  • If I place an object of a built-in type as a resource in between the user-defined type A object and my array resource object, it also works fine!

In other words, it seems as though having one or more user-defined typed objects as the first resource elements, followed immediately by an array object, causes compilation to fail. Other combinations seem to work just fine.


Can someone please explain either why this is expected behavior (and what should I be doing to avoid it besides just rearranging my resources), or confirm that I'm not entirely crazy in thinking this is a bug in the XAML build process?


Edit:

Given the likelihood of this being an actual bug, I went ahead and opened a Connect bug report here: https://connect.microsoft.com/VisualStudio/feedback/details/1441123/xaml-fails-to-compile-without-error-if-user-defined-object-is-first-resource-and-followed-immediately-by-x-array-resource

See also related/similar Stack Overflow question: The name 'InitializeComponent' does not exist in the current context : strange behaviour

Peter Duniho
  • 68,759
  • 7
  • 102
  • 136
  • 2
    this is really interesting, and a similar question was asked before, with the typical answer that doesnt apply in this scenario. http://stackoverflow.com/questions/16080680/the-name-initializecomponent-does-not-exist-in-the-current-context-strange-b probably the only option is "don't do that" but it doesnt really explain why. – Kevin Nacios Jun 17 '15 at 02:24
  • @KevinNacios: thanks! I did what I thought was a thorough search on the particulars, but didn't notice that question (guess I missed it because it didn't have [tag:c#]). I agree it's pretty much the exact same scenario, but the one answer doesn't seem to address either question (why the answer got upvoted at all is unclear...I guess it must have helped someone else who came across the question). I've added a comment to the other question in the hopes that if someone does eventually provide a real answer, they'll drop by here and put a note about it. :) – Peter Duniho Jun 17 '15 at 03:51

1 Answers1

2

The WPF team has updated the Connect report (see link in question), stating that the fix for the bug will be released in the next version of .NET:

Posted by Sachin [MSFT] on 3/9/2016 at 3:53 PM

The WPF team has reviewed this issue and fixed in next version of .NET. We thank you for the feedback and consider this issue resolved – WPF team

Unfortunately, Microsoft has retired the Connect site, so the actual report is no longer available. But the problem I've asked about in this question should no longer occur.

Peter Duniho
  • 68,759
  • 7
  • 102
  • 136