Static resources in WPF in pluggable application

问题:

I am currently working on an enterprise WPF application and I am experiencing some issues with static resources: globally defined styles and converters.

The application works this way:

• There is a shared host WPF application that is used as host for components developed by different teams (it's a PRISM application and MEF is used for importing plugins)
• Each team can add plugins by creating new dlls, but cannot modify other teams' dlls
• No changes can be made to the host application

My team is in charge of few plugins and we need to add more functionalities but we are wondering what is the best way to solve our problem.

In a simple (standard?) WPF application, we would have styles defined in the App.xaml file and all the xaml UserControls or Windows would be able to link to them at design time easily and of course at runtime.

But now, while I managed to get the styles to work during runtime, I cannot have them working at design time and it is causing two major issues:

1. I cannot see how things would look like in the IDE
2. When I reference a converter the IDE complains but I have no way to know how wether it will work at runtime or not.

How do I get StaticResources to be imported and, at the same time, work in my IDE?

If not possible, what other strategies can I adopt to overcome these issues?

回答1:

If I understand you correctly you want to use your "Design" tab in Visual Studio to see style changes and check the look and feel of your WPF application.

If that is the case, I will disappoint you but I haven't met any WPF developer yet using the 'Design' instead of 'XAML' view to make changes etc. in more advanced applications. Unfortunately the "Design" view has many flaws, doesn't display the Views properly, has problem with static resources converter and what is more it is always resource hungry.

The way we are working with WPF applications is building them and inspecting the problems and changes using a Snoop utility to investigate the application, binding errors, style problems, etc. I have never seen a way to use the build in "Design" view without many flaws, hacks and performance issues.

What is more, you should write a fake host application so that you will be able to run your plugins without the need of running the main app (if that is a problem for you)