Posts tagged with: griffin.mvccontrib

Updated the localization administration area

I’ve updated the administration area for the localization features in an attempt to make it easier to handle the localization.

I’ve replaced the link texts with icons so that they take less space. I’ve also added filtering options (so that you can translate one area/controller at a time) and a filtering option which allows you to only show texts that hasn’t been translated yet.

Update the nuget package (“griffin.mvccontrib.admin”) to get it.

Griffin.MvcContrib – The plugin system


Griffin.MvcContrib is a contribution project for ASP.NET MVC3 which contains different features like extendable HTML Helpers (you can modify the HTML that the existing helpers generate), easy localization support and a quite fresh support for plugin development. The purpose of this article is to provide a step-by-step instruction on how you can develop plugins using Griffin.MvcContrib.

Using the code

The plugin support are based on the Area support which MVC3 got. If you haven’t used areas before, I suggest that you start by reading the following article.

Most basic approach.

This first sample is not really a plugin system but only showing how you can move your code to class libraries. The example will only contain one class library to avoid confusion.
Start by creating a new ASP.NET MVC3 project (of any kind) and a class library project. For convenience we would like to have support for Razor and all MVC3 wizards in our class library. It helps us add some basic files which are required to get everything working.
To get that support we need to modify the project file for the class library. Here is how:

1. Right-click on the class library project and choose unload project:

2. Right-click on the project file and select Edit project file

3. Add the following XML element on a new line below <ProjectGuid>


4. Save and close the project file.

5. Right-click and reload the project.

6. Add reference to “System.Web” and “System.Web.Mvc” (project settings)

You have now told Visual Studio that it should active the tooling and Razor 3 views. We can now add an area by just right-clicking on the project and select “Add Area”.

Do so and create an area with a name of your choosing. Create a controller (with an Index action) and a view for the index action. You now got your first external DLL for the MVC project.

Add a reference to the class library from the MVC3 project:

Congratulations. You now got your first “plugin” based solution. Hit F5 to run the project. I named my area “Ohh” and my controller “My” so I surf to “http://theHostNameAndPort/ohh/my” to visit my plugin controller.

Uh oh. We can visit the page alright. But the view cannot be found. It can be solved thanks to Griffin.MvcContrib. Let’s install the project in the MVC3 project:

Then open up global.asax and create a new method which maps the views:

protected void Application_Start()
protected void RegisterViews()
    var embeddedProvider = new EmbeddedViewFileProvider(HostingEnvironment.MapPath("~/"), new ExternalViewFixer());
    embeddedProvider.Add(new NamespaceMapping(typeof(Lib.Areas.Some.Controllers.MyController).Assembly, "BasicPlugins.Lib"));

The first line creates a new file provider which loads files from embedded resources. We tell it which path it should try to provide files for. The next line simply adds our class library assembly and tell which root namespace it has. To make this work, we also have to change our view to an embedded resource:

Everything should be set now. Hit F5 and visit the area controller again. You should see the view now.

You can also try to have a break point in the class library. Debugging should work just like it used to. There is still one “problem”. We can’t modify the views at runtime, we need to recompile the project each time we adjust a view. Fortunually for us, Griffin.MvcContrib can solve that too. Open the RegisterViews method in global.asax again. Let’s add a disk file provider. It should be added before the embedded provider since the first found file will be used.

var diskLocator = new DiskFileLocator();
diskLocator.Add("~/", Path.GetFullPath(Server.MapPath("~/") + @"..BasicPlugins.Lib"));
var viewProvider = new ViewFileProvider(diskLocator);

You can now edit the views at runtime.

Building a plugin system

The last part showed you how you can put Controllers, Models and Views in class libraries. It’s quite useful as long as you don’t want to develop features in a more loosely coupled and dynamic way. This section will suggest a structure which you can use when building plugins.

The following part expects you to have used inversion of control containers in the past. The container is used to provide the application extension points to all plugins. I prefer using a container which has a module system so that each plugin can take care of all it’s registrations itself. I’m using Autofac in this article and it’s Module extension.

Let’s place all code which is shared between the plugins and the MVC3 project in a seperate class library. You could also follow follow the Separated interface pattern and only define all interfaces in that project. Thus removing all direct dependencies between the plugins and the main application.

The last thing to remember is that the default route configuration doesn’t work very well if you have controllers with the same name in different areas. To overcome that you have to manually change all route mappings to include the namespace. Also remove the “_default” from the route name.

Modified registration:

public override void RegisterArea(AreaRegistrationContext context)
		new { action = "Index", id = UrlParameter.Optional },
		new[] { GetType().Namespace + ".Controllers" }

Create a new class library named something like “YourApp.PluginBase” and add our basic extension points:

public interface IRouteRegistrar
	void Register(RouteTable routes);

Used to register any custom routes.

public interface IMenuRegistrar
	void Register(IMenuWithChildren mainMenu);

Allows the plugins to register themselves in the main application menu.

We’ll just use those two extensions in this example. Feel free to add as many extensions as you like in your own project πŸ˜‰

The structure

We’ll need to have some structure for the plugins so that the can easily be managed, both during development and in production. All plugins will therefore be placed in a sub directory called “Plugins”. Something like:


Add a new solution folder by right-clicking on the solution folder in the Solution Explorer. Do note that solution folders doesn’t exist on the disk and you’ll therefore have to manually append the folder to the location text box each time you add a new project in it.

Right-click on the Plugins folder in Solution Explorer and add a new project named “PluginName”. Don’t forget to append PluginsPlugin.Name to the location text box.

Since we this time don’t want to have any references to the plugins from the main application we have to manually copy them to the main application plugin folder. We use a post build event for that. Don’t forget to copy in all dependencies that your project has, since nothing handles that for you (the price of having no direct references from the MVC3 project to the plugins).

Complete structure:

Menu items

Keep in mind that you can not unload plugins and that they are available for all users. The easiest way to come around that is to display menu items only if the user has a role, which means that you should create one (or more) role(s) per plugin (if the plugin should not be available for all users). Griffin.MvcContrib contains a basic menu implementation which allows you to control if menu items are visible or not.

Sample code:

var item = new RouteMenuItem("mnuMyPluginIndex", "List messages", new { 
        controller = "Home", 
        action = "Index", 
        area = "Messages"});
item.Role = "MessageViewer";

You can later use menuItem.IsVisible when you generate the menu to determine if the item should be included or not.

Hello container

For this exercise we’ll use Autofac as the container. It contains a nifty module system which aids us in keeping the projects loosely coupled. Each plugin need to create a class which inherits from Autofac.Module and use that class to register all services which the plugin provides. Thanks to that we’ll just have to scan all plugin assemblies after any container modules and invoke them with our container.

public class ContainerModule : Module
	protected override void Load(ContainerBuilder builder)

The plugins are loaded from the main application using the following snippet:

var moduleType = typeof (IModule);
var modules = plugin.GetTypes().Where(moduleType.IsAssignableFrom);
foreach (var module in modules)
	var mod = (IModule) Activator.CreateInstance(module);

Views during development

Since we want to be able to modify views at runtime during development we have to tell ASP.NET MVC3 where it can find our plugin views. We do this by using GriffinVirtualPathProvider and a custom file locator which looks like this:

public class PluginFileLocator : IViewFileLocator
    public PluginFileLocator()
        _basePath = Path.GetFullPath(HostingEnvironment.MapPath("~") + @"..Plugins");

    public string GetFullPath(string uri)
        var fixedUri = uri;
        if (fixedUri.StartsWith("~"))
            fixedUri = VirtualPathUtility.ToAbsolute(uri);
        if (!fixedUri.StartsWith("/Areas", StringComparison.OrdinalIgnoreCase))
            return null;

        // extract area name:
        var pos = fixedUri.IndexOf('/', 7);
        if (pos == -1)
            return null;
        var areaName = fixedUri.Substring(7, pos - 7);

        var path = string.Format("{0}{1}Plugin.{1}{2}", _basePath, areaName, fixedUri.Replace('/', ''));
        return File.Exists(path) ? path : null;

It simply takes the requested uri and converts it using the naming standard I described above. Everything else is taken care of by Griffin.MvcContrib.

And interesting part is that the provider is only loaded during development thanks to nifty helper class in Griffin.MvcContrib:

if (VisualStudioHelper.IsInVisualStudio)

Loading the plugins

Ok. We’ve created some plugins (and their dependencies) which are copied to the bin folder with a post build event. We’ll therefore have to load them in some way. To do this we create a new class looking like this:

public class PluginService
    private static PluginFinder _finder;
    private readonly DiskFileLocator _diskFileLocator = new DiskFileLocator();
    private readonly EmbeddedViewFileProvider _embededProvider =
        new EmbeddedViewFileProvider(new ExternalViewFixer());
    private readonly PluginFileLocator _fileLocator = new PluginFileLocator();
    private readonly ViewFileProvider _diskFileProvider;

    public PluginService()
        _diskFileProvider = new ViewFileProvider(_fileLocator, new ExternalViewFixer());

        if (VisualStudioHelper.IsInVisualStudio)


    public static void PreScan()
        _finder = new PluginFinder("~/bin/");

    public void Startup(ContainerBuilder builder)
        foreach (var assembly in _finder.Assemblies)
            // Views handling
            _embededProvider.Add(new NamespaceMapping(assembly, Path.GetFileNameWithoutExtension(assembly.Location)));
                                 Path.GetFullPath(HostingEnvironment.MapPath("~/") + @"...." +

            //Autofac integration
            var moduleType = typeof (IModule);
            var modules = assembly.GetTypes().Where(moduleType.IsAssignableFrom);
            foreach (var module in modules)
                var mod = (IModule) Activator.CreateInstance(module);

    // invoke extension points
    public void Integrate(IContainer container)
        foreach (var registrar in container.Resolve<IEnumerable<IMenuRegistrar>>())

        foreach (var registrar in container.Resolve<IEnumerable<IRouteRegistrar>>())

The plugins are now loaded and the extension points have been passed to them.

Final touch

The last thing to change is global.asax:

protected void Application_Start()


    _pluginServicee = new PluginService();

private void RegisterContainer()
    var builder = new ContainerBuilder();
    _container = builder.Build();
    DependencyResolver.SetResolver(new AutofacDependencyResolver(_container));


The code for the samples are located in github and so is Griffin.MvcContrib. Griffin.MvcContrib can also be install from nuget.

A more structured MembershipProvider.

If you take a look at the official documentation that tells you how to create your own custom MembershipProvider you’ll notice that the documentation is mostly about describing:

  • how you should throw exceptions and when
  • Which events you should invoke and when
  • How the logic in each method should work.

Let’s stop here for a moment. What are the most typical reason for creating a custom membership provider? Is it to change the behaviour(/contract) of the provider? Or maybe change the password handling? No. The most common reason is to add support for a custom data source.

Back to the MembershipProvider class. As I see it, it has four responsibilites:

  1. Be able to handle all members (login, register etc)
  2. Load/Store information from/in a data source
  3. Keep track of account/password policies and handle those.
  4. Handle passwords (encrypt/hash/compare)

And that’s why it’s such a tedious task to create a custom MembershipProvider: You need to implement all of those responsibilities.

Griffin.MvcContrib to the rescue!

With the MembershipProvider in Griffin.MvcContrib you do not need to know all of those details. Our MembershipProvider uses DependencyResolver (a built in
Service Locator in MVC3) to lookup the dependencies that it needs. You need to register the following services in your inversion of control container:


Used to retrieve/store membership accounts from/to a data source. It’s the only thing you need to implement to get support for a custom data source (like a database or a web service).

Source code


Used to handle passwords (comparing them, encrypting, decrypting). There are three strategies available in the framework:

  • ClearTextStrategy – Store passwords as clear text in the database
  • HashedPasswordStrategy – Hash passwords before they are stored.
  • TripleDesPasswordStrategy – Use TripleDes to encrypt/decrypt passwords.

Source code


Defines how passwords should be treated. For instance the minimum length, number of attempts before locking the account etc.

Two policy implementations exist. One who loads the policies from web.config and one “normal” class which you can create and assign the properties in.

Source code

How to use it

Disclaimer: You should know that Account Administration Tools won’t work since the provider has a dependency on DependencyResolver. Other than that, the provider works like any other provider.

Start by modifying your web.config to specify the new provider:

    <membership defaultProvider="GriffinMembershipProvider">
        <clear />
        <add name="GriffinMembershipProvider" type="Griffin.MvcContrib.Providers.Membership.MembershipProvider" applicationName="/" />

Then you need to register the dependencies in your inversion of control container. Here is a sample for Autofac:

protected void Application_Start()
	ContainerBuilder builder = new ContainerBuilder();
	builder.RegisterInstance(new PasswordPolicy
			 IsPasswordQuestionRequired = false,
			 IsPasswordResetEnabled = true,
			 IsPasswordRetrievalEnabled = false,
			 MaxInvalidPasswordAttempts = 5,
			 MinRequiredNonAlphanumericCharacters = 0,
			 PasswordAttemptWindow = 10,
			 PasswordMinimumLength = 6,
			 PasswordStrengthRegularExpression = null
	// the rest of the initialization

If you like to switch from hashed passwords to encrypted passwords you just need to register TripleDesStrategy in the container instead. Or implement your own strategy.


The code is available at github and can be installed using nuget install-package griffin.mvccontrib.

Easy model and validation localization in ASP.NET MVC3

Update I’ve written a more complete article about the framework at

If you have googled a bit you’ll read that you should use DescriptionAttribute and DisplayNameAttribute to get localization which will result in a view model that looks something like this:

    public class UserViewModel
        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserId", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserIdDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public int Id { get; set; }

        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserFirstName", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserFirstNameDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public string FirstName { get; set; }

        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserLastName", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserLastNameDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public string LastName { get; set; }

Don’t do that.

The solution to get cleaner DataAnnotation localization is to derive the attributes and do some magic in the derived classes. The problem with that solution is that client-side validation stops working unless you create new adapters for your derived attributes.

Don’t do that.

The easy solution

I found an excellent post by Brad Wilson that goes through most of the new stuff in MVC3. It’s a must read. When reading it I came up with the idea to use the new Meta Data providers to do the localization. The solution works quite well and you’re models become clean again:

    public class UserViewModel
        public int Id { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }

You need to specify the new providers (created by me) in your global.asax:

        protected void Application_Start()
            var stringProvider = new ResourceStringProvider(Resources.LocalizedStrings.ResourceManager);
            ModelMetadataProviders.Current = new LocalizedModelMetadataProvider(stringProvider);
            ModelValidatorProviders.Providers.Add(new LocalizedModelValidatorProvider(stringProvider));

That’s it. No more messy attributes.

Defining the localization resources

I created an interface called ILocalizedStringProvider which is used by both providers. This means that you do not have to use String Tables. Just create a new class and implement that interface to get support for your database, XML file or whatever you choose.

In my example I used a string table and the strings in it looks like this:

As you see, you should name your strings as “ModelName_PropertyName” and “ModelName_PropertyName_MetadataName” to include meta data like Watermark and NullDisplayText. Refer to MSDN to see which kind of meta data there is.

As for validation attributes, the string table names should simply be the attribute name without the “Attribute” suffix.

Code and documentation

The code is available at github.
Documentation is available here.


Comments are now closed. Either open tickets at github or ask questions at with the tag “griffin.mvccontrib”. Write a comment starting with “@jgauffin” if I don’t answer within reasonable time πŸ˜‰