Hey, I've tried what you suggested and I feel like I'm getting closer to having this working, instead of throwing the same error though, now it's throwing another exception which I will attach to my post. This is the code I have in my LoginView.xaml.cs now:

-Joshmond

That normally means you have two resources with conflicting identities. In this case it looks like you have two DataTemplates that share the same DataType. You can remove the one inside LoginView.xaml since it's not needed.

When I take out my data-template in the LoginView, I still get the same error, even if I remove the ContentControl, I still have the same error message. Here is a screenshot of my UserControl xaml.




-Joshmond

After some messing around with the xaml, I think that the problem may lie in my heirarchy and how I've set the project up. Blow I've posted a link to my entire project, I was wondering if anyone could take a look and provide some feedback. I feel like I'm very close to solving this problem and getting everything set up. All help is greatly appreciated.

Link to project: https://drive.google.com/open?id=1HD-zy ... 4ZdNwKUJUE

Thanks

-Joshmond

Aha, I can see that you're using the System.Windows.Controls namespace. That's needed for your WPF project if you have one, but it won't work with Noesis - you need to use the control proxies instead. Here's what you need to get MonoGame working:

1) Remove project references to PresentationCore and PresentationFramework.
2) Exclude LoginView.xaml from your project, but keep the cs file in there.
3) Whenever you need to reference a control in the code behind, you need to include the Noesis namespace instead of System.Windows.Controls.

If your source is shared between a WPF project and a Noesis project, you can make sure the proper control types are referenced between them like so:

For this to work do I also have to modify the xaml file or does that stay the same? Ffter adding the noesis stuff that seems to break my xaml. Below are some screenshots of the various exceptions being thrown. How would I go about excluding the xaml but keeping the xaml.cs file as for me they show as linked/nested (as shown in the screenshots ) also, do I have to move the .xaml file to a different folder since it would be exluded from the project?

Thanks

-Joshmond

The xaml files shouldn't be built by your game project because Visual Studio only interprets them in the context of WPF. They really do need to be worked on separately in Blend. There's all sorts of approaches you can take to this, for sure you could go into the project file, remove the DependentUpon attribute to unlink it, then manually exclude it. If you really want those files in your project, you might be able to prevent building all together by fiddling with the file's properties and turning off Build Action/Custom Tool. You could, for the sake of ease, break .NET convention and have the .xaml.cs file simply use .cs as the extension. Conceivably you might be able to change the xmlns namespace to point to Noesis in an attempt to get the xaml parser to look at the Noesis types, but I doubt that would work

Awesome, thanks so much for all your help dude. Where are the xaml files usually stored in these types of projects, would you recommend creating a folder outside the project altogether and just referencing that. You mentioned that the xaml files should be worked on in Blend, does Blend store the xaml files in a default location? Would I also need the noesis namespace referenced in my xaml or can I just keep that as it is as long as I have the noesis namespace in the code behind?

One thing which I'm very curisous about is the code-behind (the xaml.cs file), according to MVVM no code should be in the code-behind but when I look at the Unity samples, there is code in the code-behind. Does this violate MVVM?


Thanks


-Joshmond

No need for Noesis in Blend, it's completely WPF at that point. Just figure out a good overall logical structure for your project in the grand scheme of things, and ensure your project files play nice with it. You'd have your various project files living in Root, and then you'd either pick and choose which files go in which projects from the relevant sub folders, or you'd have a tool as part of your pipeline to do that for you. Depending on how much you care to automate that, it can be a bit of work.

Conventionally, the AAA games I've worked on that used XAML frameworks would have paths that looked something like this:

Root/Source/Ui/Scenes
Root/Source/Ui/Controls
Root/Source/Ui/Resources

etc etc. The relevant xaml and cs files are just mixed together where they need to be, and then as part of the build process, the xaml files get packaged up into the bin directory. Then the game specific code would live under something like

Root/Source/Game/*

In the purest sense of MVVM, code behind is minimal to non existent. WPF provides a ton of default functionality, but sometimes it just isn't there, and we need to implement our own. So in reality, there always comes a time when we need to need to use it. It's perfectly normal in MVVM, as long as you keep in mind what it should be used for - ui control code only. New visual states, new input behaviors, interaction, etc. In general, the rule of thumb for MVVM is your code behind shouldn't know anything about your view model data.

Personally, I try to follow MVVM as tightly as I can, however I won't be afraid to break that rule of thumb if it makes sense to, and as long as the project's overall architecture is kept in tact. Occam's Razor and all.

If my xaml is outside of my project and my xaml.cs file is within my project, how would the paths look in the xaml because I would still need to let my xaml files know about my views and viewmodels, will they have the same namespace still, if not is is possible to reference a class in a different namespace/project?


Thanks


-Joshmond