2

I'm working on a XAML-based app for Windows 10. I'm running into issues when trying to implement a binding in Setters, as per this answer. Here is my code:

namespace Sirloin.Helpers
{
    internal class Binding
    {
        public static readonly DependencyProperty ContentProperty = // ...

        public static string GetContent(DependencyObject o) => // ...
        public static void SetContent(DependencyObject o, string value) => // ...
    }
}

And here is my XAML:

<Page
    x:Class="Sirloin.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Sirloin"
    xmlns:h="using:Sirloin.Helpers"> <!--Some designer stuff omitted for clarity-->

    <Page.Resources>
        <ResourceDictionary>
            <Style x:Key="MenuButtonStyle" TargetType="Button">
                <Setter Property="Background" Value="Transparent"/>
                <Setter Property="h:Binding.Content" Value="Symbol"/> <!--The XAML parser chokes on this line-->
                <Setter Property="FontFamily" Value="Segoe MDL2 Assets"/>
            </Style>
        </ResourceDictionary>
    </Page.Resources>
</Page>

For some reason, the VS designer seems to be throwing an error when it reaches the lines with the special binding syntax; namely, the one that sets h:Binding.Content to Symbol. Here is a screenshot of the message:

Strangely enough, though, the code seems to be compiling fine. When I hit Ctrl + B in Visual Studio, it builds with no errors and successfully outputs the binary. Of course, the drawback to this is I can't use the designer, which claims the XAML to be 'Invalid Markup' every time I build the project.

Can someone recommend me a solution to this problem? I tried the suggestion here of restarting Visual Studio and deleting the cached binaries, but it doesn't seem to be working.

Thanks!

Community
  • 1
  • 1
James Ko
  • 32,215
  • 30
  • 128
  • 239
  • @Ryios The code-behind being referenced by the XAML is in the same project though, so I don't see how that could be the case. – James Ko Jan 30 '16 at 03:13
  • I suspect your code compiles because the designer could not determine the Binding object in the Sirloin.Helpers namespace, therefore it did not generate code in the code behind for that object. So the conflicting code was not generated, thus the code that was generated builds. – Ryan Mann Jan 30 '16 at 03:23
  • 1
    Why is your `Binding` class marked as `internal`? Have you tried making it `public`? – Uchendu Nwachuku Jan 30 '16 at 03:24
  • I totally missed your binding class, sorry I'm blind. Yeah it's probably because it's internal as Uchendu suggested. The WPF editor is running in the Visual Studio process, as such it cannot see your Binding class because it's internal to your Assembly. – Ryan Mann Jan 30 '16 at 03:27
  • You might be able to use the InternalsVisibleToAttribute to expose your internal object to Visual Studio if you figure out which .Net Assembly the WPF Editor is compiled in. – Ryan Mann Jan 30 '16 at 03:33
  • Found an article on WPF bindings that states Things WPF is binding to have to be public, they cannot be internal even with InternalsVisibleTo. https://msdn.microsoft.com/en-us/library/ms743643(v=vs.100).aspx – Ryan Mann Jan 30 '16 at 03:39
  • @UchenduNwachuku Whoops, forgot to mention that. Yep, I have tried making it public but unfortunately that didn't work either. I'd prefer to keep it internal if possible though, since this is a helper class in a library. – James Ko Jan 30 '16 at 04:09
  • I've tried similar code and obtained similar error, but it seemed to disappear once I've build and deployed the project, even with classed marked as *internal* (everything works). Also note that *Binding* may be an unfortunate name for a class. You can [download my sample here](https://onedrive.live.com/redir?resid=87995A9E6AADB641!59459&authkey=!AGnzFk7913MLPV8&ithint=file%2czip). – Romasz Jan 30 '16 at 07:47

2 Answers2

3

Turns out Uchendu was right: one of my problems was that the class was marked as internal rather than public. I also had to mark it as sealed, and change the dependency properties from fields to properties. For example, this:

public static readonly DependencyProperty BlahProperty = /* ... */;

had to be refactored to this:

public static DependencyProperty BlahProperty { get; } = /* ... */;

since WinRT components don't allow exposing public fields.

After those modifications I was able to get the library to build successfully.

Community
  • 1
  • 1
James Ko
  • 32,215
  • 30
  • 128
  • 239
1

Clear the Visual Studio Editing panel before you begin a compile, and you will not see these nagging error messages. That is, "X" off all your current editing sessions and of course answer yes to all "Save changes to the following items" messages.

pollaris
  • 1,281
  • 17
  • 20