Final steps in using MVVM to decouple GUI from business logic?

Question

Just recently, I learned about using MVVM to decouple GUIs from the underlying model. I ended up learning as much as I could to convert my current application over to MVVM, and was largely successful. Now I need to figure out how to actually take a GUI generated in Blend and use it in place of my current GUI, which was designed in Visual Studio. I can't find any resources on the web for making this as seamless as possible. I'd like to know what you all have done and have had work for you.

My ultimate solution would be something that would allow me to, at runtime, select a skin from a menu and immediately have the GUI change from the current one to another that the user selects. Can anyone point me to posts that explain how to do this?

My current goal is less ambitious -- I'd like to be able to add my new Blend GUI into my Visual Studio project and when I compile, have the new Blend GUI appear. If I want to go back to the old GUI, I would have to recompile. For now, that is okay.

I've got my Blend project added to my VS2008 solution, and have set it to be the startup application. That works fine -- if I run the app, my new GUI appears instead of the old one. The problem now is that it needs DLLs that are actually in a different folder -- the bin\Debug folder of the original startup application. Am I supposed to leave my original GUI as the startup application, and then have its App codebehind load the other GUI?

Also, each of the respective GUIs needs a reference to the ViewModel. In my case, I was just instantiating it in my current GUI class. For the Blend GUI, I instantiated one there as well, since only one of the GUIs will be active. Is this where something like the Unity framework should be used?

Sorry about all of the possibly-incoherent questions, but I'm not quite sure how I should proceed from here. I feel like I'm so close to proving to myself that MVVM is the way to go from a GUI standpoint (I'm already sold on the testability bit).

Answer 1

I found a mistake, where in one part of my code I was using the wrong property to get at the currently-running assembly's path. I am now using

System.Reflection.Assembly.GetExecutingAssembly().Location

Although this does work, it only works if I copy the exe from the Blend project's bin\Debug folder into my main application's bin\Debug folder. I will have to live with this by using a post-build event, I guess. I was so spoiled for the past several months working with .NET, where I didn't have to do this (like before in C++) because all of the referenced assemblies get automatically copied over. If I want to debug any code-behind, I also have to set the starting executable in the Blend project's settings, which is inconvenient as well, especially when working on different computers where the paths aren't set up the same. Any suggestions here would also be appreciated!

Answer 2

All the examples I've seen dynamically switch GUI appearance by using some form of ResourceDictionary swapping. A few links:

Load XAML Resource Dictionaries at Runtime

WPF change theme/style at runtime

Hope that helps.