1

This is a simple problem that someone surely knows how to solve.

I have a WPF application that compiles perfectly fine.

I decided to add functionality to the ListView, so I extended the ListView class as ListViewEx.

I went into my XAML code and changed all the ListView tags to ListViewEx.

Now the application will not compile, claiming ListViewEx does not exist. But it doesn't exist, because it hasn't been compiled yet, and it won't compile because the XAML doesn't think it exists yet!

The only way I can get it to compile is to completely remove all tags referencing the new class from the XAML, compile the project so the new class exists whereever the XAML is looking for it, and then I can add the tags back and it will compile fine.

Is this behavior by design?

Circular Dependency

Notice four things.

  1. ListViewEx does in fact exist in the FilePublisher namespace. (contradicts error message)
  2. The MainForm's XAML declare the FilePublisher namespace as "p"
  3. "p:ListViewEx" is referenced in the XAML
  4. lstFile does exist in MainForm (see XAML tag Name="lstFiles") (contradicts error message)

The problem is that the XAML designer is referencing the DLL it's trying to compile. It's expecting ListViewEx to already exist, and because it hasn't been compiled yet, it does not exist in the DLL. As a result, the designer is not automatically generating the lstFiles property on the main form's partial class like it should, and as a result, the project will not compile because the code references lstFiles. So it won't compile, because something doesn't already exist in the very thing it's trying to compile! That is a circular dependency, and it's reproducible 100% of the time.

Triynko
  • 18,766
  • 21
  • 107
  • 173
  • no, it should compile, show some code, do you include clr-namespace of your ListViewEx? – Arsen Mkrtchyan Feb 12 '14 at 21:11
  • Can you post a little bit of code so that we can help you. For instance, can I see how you declare `ListViewEx` in XAML? – deloreyk Feb 12 '14 at 21:13
  • The problem is exactly as I described. The class exists, the namespace is declared on the Window element `xmlns:p="clr-namespace:FilePublisher"` and the class ListViewEx exists as a public class in the namespace FilePublisher. If something else is wrong, then why is is that if I change the tag back to listview, compile and change the tags immediately back to listviewex, it compiles fine, and subsequently. This only happens when XAML is trying to reference a brand new class that hasn't been compiled. Merely referencing it in the XAML prevents it from being compiled initially. – Triynko Feb 12 '14 at 21:20
  • 2
    Show some code and you will get some help. There is definitly no circular dependency problem. – Mare Infinitus Feb 12 '14 at 21:23
  • hmm, that is really strange, never meet that problem... – Arsen Mkrtchyan Feb 12 '14 at 21:24
  • There is absolutely a circular dependency problem and I've proven it, and explained exactly what the problem is and the circumstances under which it occurs. I'm adding a screenshot of the Visual Studio IDE. – Triynko Feb 12 '14 at 21:43
  • Am I doing something wrong with the lstFiles tag? It seems like the designer is not generating the property on the class when I use "p:ListViewEx" even though it does when I just use "ListView". Will it not generate properties for custom namespaces? It's ultimately the absence of "lstFiles" in the designer-generated partial class (which Visual Studio doesn't give me access to like it used to with winforms) which is causing the problem. – Triynko Feb 12 '14 at 22:06
  • Ha, it WAS a known problem. Since the lstFiles was not being generated by the designer, I manually added the property to my class, and I got a much more helpful error message: "Because 'ListViewEx' is implemented in the same assembly, you must set the x:Name attribute rather than the Name attribute." – Triynko Feb 12 '14 at 22:14
  • Which means this answer is incorrect: http://stackoverflow.com/a/1718826/88409 and someone commented on it stating as much. – Triynko Feb 12 '14 at 22:21

3 Answers3

1

I found the problem.

Since Visual Studio was not automatically creating the lstFiles property in the auto-generated code behind as it should have been doing (and was doing when the tag was just ListView instead of p:ListViewEx), I tried to manually add the lstFiles property to my class, and then it gave me a much more helpful error message:

Because 'ListViewEx' is implemented in the same assembly, you must set the x:Name attribute rather than the Name attribute.

So the solution is to ensure that when you use a control in a custom namespace in the same assembly, you must declare it using the "x:Name" instead of just the "Name" property. Nice.

Triynko
  • 18,766
  • 21
  • 107
  • 173
0

I used that logic a lot of times, and it works.. I have a guess that issu, come from namespace. make sure you don't have assembly name in clr-namespace, since the type is in the same assembly

<Window... 
        xmlns:custom="clr-namespace:MyCustomListViewNamespace" >
...
     <custom:ListViewEx ... />
</Window>
Arsen Mkrtchyan
  • 49,896
  • 32
  • 148
  • 184
  • The namespace is declared, that's not the problem. The problem is that ListViewEx has never been compiled. Its a new class and it exists and its in the proper namespace, but I cannot compile the class, because the XAML seems to be looking for it in the project DLL. Well, it's not in the project DLL, because it hasn't been compiled into it yet, and the only reason it hasn't been compiled into it yet, is because the XAML is throwing an error saying it can't find it in the DLL! – Triynko Feb 12 '14 at 21:19
  • 1
    @Triynko, as I said, i am using dll which contains extended class and xaml using same control together each day, and never meet that kind of issue, so I think that is not the main reason of problem – Arsen Mkrtchyan Feb 12 '14 at 21:22
  • 1
    This works perfectly and I have done it many times. There is no circular dependency problem that you figured out. – Mare Infinitus Feb 12 '14 at 21:22
  • But it only occurs if the class has never been compiled. If you compile the class at least once and THEN reference it in the XAML, it works. But if you write a new class, reference it in the XAML before compiling it, and then try to compile your code, the XAML error will prevent the initial compilation of the class, because it can't find the class in the project's DLL. – Triynko Feb 12 '14 at 21:24
  • Explain this behavior if you don't think there's a circular dependency. 1. The project does not compile. 2. I simply remove the "p:" and the "Ex" from around the "ListView" tags. 3. The project compiles now since the XAML is not referencing the new ListViewEx class. 4. I add the "p:" and "Ex" back to the tags, and now it compiles. This always occurs for any new classes that haven't been compiled at least once and are referenced in the XAML. – Triynko Feb 12 '14 at 21:26
0

I had many times the same problem you describe: a circular dependency where a class in C# is not-yet-compiled, but is already-referenced in xaml, giving an error and preventing compilation.

Unfortunately the only solution I found is this:

  • Save and close all documents (optionally perform a dummy commit);
  • Find every occurrence of the new class in XAML;
  • Comment out that XAML until you are abble to compile;
  • Roll-back the comments:
    • Go to every open XAML file and press CTRL+Z multiple to reset it, then save.
    • Optionally, perform some version-control reset/revert, like git reset --hard.

Now you should be able to build the solution with the references present in XAML.

heltonbiker
  • 26,657
  • 28
  • 137
  • 252