Module Security

If you've decided to dynamically load your WPF modules in a "plug-in" style application then you may have wondered how safe is it or how easy is it for someone to DLL inject your modules.

If you have not wondered this, then you should. Module deployment that relies on module discovery by your bootstrapper requires that you need to take into consideration of digitally signing your modules so that you know someone else is not messing around with your application.

Digitally signing your DLL can be a bit of a pain if you have not planned for it early in your development process. Strong Name Signing is the simplest way to verify your DLL but beware that strong named libraries cannot reference weak named libraries, but vice versa is possible. So plan your dependency well, keep to the PRISM pattern of de-coupling your modules via interfaces and common infrastructure libraries and you will be fine.

Commands and Command Parameters

Have you ever tried to use DelegateCommand<T> with enums being your payload?

The quick answer is that you can't. DelegateCommand<T> requires that T being a struct or class type (that is everything except enum!). So how do you get around this (god knows we hate "work-arounds").

I found that the best way to use enum-like functionality is to convert the enum into a class of constant strings. A very good example is a menu with enum type locations (eg. "Home", "Settings", "Update", etc.). By converting this enum into a class, we have:


public class LocationNames
{
    public const string Home = "Home";
    public const string Update = "Update";
    public const string Setting = "Setting";
}

So now our enum DelegateCommand<T> can be DelegateCommand<string> instead.

DataTemplate Vs. View Injection

PRISM tells us that each view needs a contracted interface, eg. IMyView which your view needs to implement.

This approach is to let us inject the views into the appropriate region (this injection usually happens in the controller). Given this guideline, what has happened to the classic MVVM approach of using DataTemplate?

Traditionally, we would have some ItemsControl to present the View-Models and define the custom DataTemplate that will define the associated view. For some, you may have noticed that when the DataContext of this ItemsControl changes, a new view is created for the new View-Model (this is sometimes an undesirable side effect).

The View Injection approach to my knowledge was derived from the Model-View-Presenter (MVP) pattern, this means that for those that has gone from MVVM to PRISM will want to keep the traditional DataTemplate to concrete view types. This is fine but as long as you are consistent in your approach.

Personally, I find that there is no need for an interface for each view because realistically you are not going to unit test the views and produce meaningful Asserts or replace any of the views through IoC any time soon.