9

We have a custom control called FixedToolBar defined in a class library which is referenced by a second assembly which uses it via XAML. However, VS2015 is showing the error:

A value of type FixedToolBar cannot be added to a collection or dictionary of type 'UIElementCollection'

Here's the class itself

public class FixedToolBar : Control // <-- Control is a subclass of UIElement
{
    // Bla bla
}

...and here's the XAML snippet...

<DockPanel>

    <c:FixedToolBar x:Name="MainToolBar" DockPanel.Dock="Top">
        <Button Header="Test 1" />
        <Button Header="Test 2" />
    </c:FixedToolBar>

    <ListBox x:Name="MainListBox" />

</DockPanel>

More odd is it only shows the error when the XAML editor is open, but otherwise compiles and runs just fine!

Any ideas why? It's really annoying to have VS report all these errors at design time. All those red squigglies makes the XAML da@n near unreadable!

Mark A. Donohoe
  • 28,442
  • 25
  • 137
  • 286
  • 2
    To the person who down-voted this... care to explain why? – Mark A. Donohoe Sep 14 '15 at 22:50
  • 1
    Same issue here with various controls. Any update on the problem yet? It seems to cause runtime problems with BAML parsing with our client. – JanW Oct 16 '15 at 10:43
  • 2
    @MarqueIV I ran into that issue today. All I had to do was unload my project and reload it again. Evidently this happened when I added an external reference into my project. By doing the aforementioned steps caused Visual Studio to fully accept the new .dll into my project. Cheers! – mmangual83 Aug 18 '17 at 19:12

1 Answers1

0

It is rumored that these phantom error squiggles often appear under the following scenario:

  • Your xaml is in project A.
  • Project A includes project B in its references.
  • The type of the elements that you are adding to the collection is defined in project B.
  • The type of the elements depends on some type found in project C.
  • Project A does not explicitly include project C in its references. (As it does not have to.)

As far as the build system is concerned, this is not a problem at all, because the dependencies of project A are computed recursively, so they include dependencies of dependencies, so project C will of course be included.

But apparently the xaml subsystem has, for some unfathomable reason, the need to resolve project dependencies by itself, and it is not smart enough to resolve them recursively.

The solution is to make project A explicitly reference project C, despite the fact that it does not use it.

Also be aware of the fact that in trying to do so, you may come across further complications, for example if you edit A.csproj to add a PackageReference to project B, and reload project A, that reference might not appear under "References", in which case the phantom squiggles will not go away. A proper full clean rebuild tends to fix that.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142