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.