I’ve come across this strange issue and decided to blog about it since I can’t figure out exactly why this is happening it is clearly something to do with the DLR and interfaces.

First, if you are getting the exception: 'object' does not contain a definition for 'xxxx' it is related to either an object you have being marked internal or you are are using an anonymous object type for your model (which .Net will always mark as internal).

Here’s a really easy way to replicate this:

1. Create an internal model

internal class MyModel
{
    public string Name {get;set;}
}

2. Return this model in your MVC action

public ActionResult Index()
{            
    return View(new InternalTestModel("Shannon"));
}

3. Make your view have a dynamic model and then try to render the model’s property

@model dynamic
<h1>@Model.Name</h1>

You’ll get the exception:

Server Error in '/' Application.

'object' does not contain a definition for 'Name'

So even though the error is not very informative, it makes sense since Razor is trying to access an internal class.

Try using a public interface

Ok so if we want to keep our class internal, we could expose it via a public interface. Our code might then look like this:

public interface IModel 
{    
    string Name {get;}
}
internal class MyModel : IModel 
{        
    public string Name {get;set;}
}

Then we can change our view to be strongly typed like:

@model IModel
<h1>@Model.Name</h1>

And it will work, however if you change your view back to be @model dynamic you will still get the exception. Pretty sure it’s because the DLR is just binding to the instance object and doesn’t really care about the interface… this makes sense.

Try using an abstract public class

For some reason if you make your internal class inherit from a public abstract class that implements the same interface you will not get this exception even though the object instance you are passing to razor is internal. For example with this structure:

public interface IModel 
{        
    string Name {get;}
}
public abstract class ModelBase : IModel 
{
    public abstract Name {get;}
}
internal class MyModel : IModel 
{            
    public override string Name {get;set;}
}

You will not get this error if your view is @model dynamic.

Strange!

I’m sure there’s something written in the DLR spec about this but still seems strange to me! If you are getting this error and you aren’t using anonymous objects for your model, hopefully this might help you figure out what is going on.

Disclaimer

This post is about developing for Umbraco v5 (Jupiter) which at the time of this post is still under development. The technical details described below may change by the time Umbraco Jupiter is released. If you have feedback on the technical implementation details, please comment below.

Macro Types

In Umbraco v5, there are currently 3 types of Macros:

• Xslt
• Partial View
• Surface Action

The Xslt macro will remain very similar to the v4 Xslt macro, but the 2 other types are brand new. This post will cover the new Partial View Macro.

A Partial View in MVC is sort of synonymous with a User Control in WebForms. Its simply just a Razor view as a cshtml file. If you like Umbraco v4’s Razor macros, then you’ll be pleased to know that Razor is absolutely native to v5 and the Partial View Macro will be one of your best tools for working with v5.

Creating a Partial View macro

The first thing you’ll have to do is create the partial view, which you will need to save in the ~/Views/Umbraco/Partial folder. Next, a partial view macro needs to inherit from a custom view type, so the declaration at the top of your view will need to be:

@inherits PartialViewMacro

Then, just like in v4, you’ll need to create a new macro in the Developer section of the Umbraco back office. The Macro Property interface looks very similar in v5:

You’ll notice its slightly simplified as compared to v4. The 2nd drop down list dynamically changes based on the Macro Type drop down list value.

Once you’ve saved the macro, that’s it, your Macro is now created!

Using a Partial View macro

The razor syntax for rendering a macro in v5 is:

@Html.UmbracoMacro("blah")

As noted before, a Partial View Macro inherits from the view type: PartialViewMacro . This view object contains a Model property of type: Umbraco.Cms.Model.PartialViewMacroModel which has a couple of properties you can use to render data to the page:

public Content CurrentNode { get; }
public dynamic MacroParameters { get; }

The CurrentNode property is very similar to v4’s currentPage parameter in Xslt. It will allow you to traverse the tree and render any content you like. Here’s one way that you could list the child names from the current node:

<h2>Names of child nodes</h2>
@foreach (var child in Model.CurrentNode.ChildContent().AsDynamic())
{
    <p>
        Child node name: <b>@child.Name</b>
    </p>
}

Dynamic parameters

As you can see above, there’s a MacroParameters property on the PartialViewMacroModel which is a dynamic property just like MVC’s ViewBag. Passing data into the MacroParameters property can be done in your Macro declaration like so:

@Html.UmbracoMacro("blah", new { IsCool = true, MyParameterName = new MyObject() })

This means that you can pass any type of object that you’d like into your macro with any parameter name. Then to use the parameters that you’ve passed in, you can reference them directly by name inside your macro:

<ul>
    <li>@Model.MacroParameters.IsCool</li>
    <li>@Model.MacroParameters.MyParameterName.ToString()</li>
</ul>

Macro parameters via the Macro Editor

A cool new feature in v5 is the new Macro parameter editor. It can now pre-populate all macro parameters found in Xslt, Partial Views and Surface controllers. Better still, is that the parameter editor has been completely rebuilt with Knockout JS so you can add/remove as many parameters as you like at once and then finally post your changes back when hitting save.

Oh, and another great feature in v5 is that the editors for macro parameters are actually just v5 Property Editors that are attributed as Macro Parameter Editors.

Strongly typed parameters

You may be wondering how the Macro Editor populates parameters from a Partial View Macro since we’ve seen that Partial View Macro model only supports dynamic (non stongly typed) properties… The answer is in Razor. Razor views allow you to define public properties, methods, etc… inside of the Razor markup. So if we want to have strongly typed parameters for our Partial View Macros which can be set based on Macro parameters in the rich text editor, all we have to do is declare them like:

@inherits PartialViewMacro

@functions {

    public bool IsCool { get; set; }
    
}

Now, the Partial View has a discoverable property which our Macro Editor will be able to see and automatically populate the parameter list. This property will also be set with any value that is selected in the Macro Parameter Editor when inserting one into the rich text box. Another thing to note is that if you are simply injecting parameter values using the Html.Macro helper, then this property will be set so long as a dynamic property of the same name exists in the macro’s MacroParameter model properties.

I was hoping that these were built already but couldn’t see any descent results with a quick Google search so figured I’d just write my own… these are now part of the Umbraco v5 codebase. Here’s 2 HtmlHelper methods that allow you to very quickly create an Html table output based on an IEnumerable data structure. Luckily for us, Phil Haack showed us what Templated Razor Delegates are which makes stuff like this very elegant.

There are 2 types of tables: a table that expands vertically (you set a maximum number of columns), or a table that expands horizontally (you set a maximum amount of rows). So I’ve created 2 HtmlHelper extensions for this:

Html.TableHorizontal
Html.TableVertical

Say you have a partial view with a declaration of something like:

@model IEnumerable<MyDataObject>

To render a table is just one call and you can customize exactly how each cell is rendered and styled using Razor delegates, in the following example the MyDataObject class contains 3 properties: Name, Enabled and Icon and each cell is going to render a check box with a CSS image as it’s label and there will be a maximum of 8 columns:

@Html.TableVertical(Model, 8, 
    @<text>
    @Html.CheckBox(@item.Name, @item.Enabled)
    <label for="@Html.Id(@item.Name)" class="@item.Icon">
        <span>@item.Name</span>
    </label>
    </text>)

Nice! that’s it, far too easy. One thing to note is the @<text> </text> syntax as this is special Razor parser syntax that declares a Razor delegate without having to render additional html structures. Generally Razor delegates will require some Html tags such as this: @<div> </div> but if you don’t require surrounding Html structures, you can use the special @<text> </text> tags.

Lastly here’s all the HtmlHelper code… I’ve created these extensions as HtmlHelper extensions only for consistency but as you’ll be able to see, the HtmlHelper is never actually used and these extensions could simply be extensions of IEnumerable<T>.

/// <summary>
/// Creates an Html table based on the collection 
/// which has a maximum numer of rows (expands horizontally)
/// </summary>
public static HelperResult TableHorizontal<T>(this HtmlHelper html,
    IEnumerable<T> collection,
    int maxRows,
    Func<T, HelperResult> template) where T : class
{
    return new HelperResult(writer =>
    {
        var items = collection.ToArray();
        var itemCount = items.Count();
        var maxCols = Convert.ToInt32(Math.Ceiling(items.Count() / Convert.ToDecimal(maxRows)));
        //construct a grid first
        var grid = new T[maxCols, maxRows];
        var current = 0;
        for (var x = 0; x < maxCols; x++)
            for (var y = 0; y < maxRows; y++)
                if (current < itemCount)
                    grid[x, y] = items[current++];
        WriteTable(grid, writer, maxRows, maxCols, template);
    });
}

/// <summary>
/// Creates an Html table based on the collection 
/// which has a maximum number of cols (expands vertically)
/// </summary>
public static HelperResult TableVertical<T>(this HtmlHelper html,
    IEnumerable<T> collection,
    int maxCols,
    Func<T, HelperResult> template) where T : class
{
    return new HelperResult(writer =>
    {
        var items = collection.ToArray();
        var itemCount = items.Count();
        var maxRows = Convert.ToInt32(Math.Ceiling(items.Count() / Convert.ToDecimal(maxCols)));
        //construct a grid first
        var grid = new T[maxCols, maxRows];
        var current = 0;
        for (var y = 0; y < maxRows; y++)
            for (var x = 0; x < maxCols; x++)                    
                if (current < itemCount)
                    grid[x, y] = items[current++];
        WriteTable(grid, writer, maxRows, maxCols, template);
    });
}

/// <summary>
/// Writes the table markup to the writer based on the item
/// input and the pre-determined grid of items
/// </summary>
private static void WriteTable<T>(T[,] grid, 
    TextWriter writer, 
    int maxRows, 
    int maxCols, 
    Func<T, HelperResult> template) where T : class
{            
    //create a table based on the grid
    writer.Write("<table>");
    for (var y = 0; y < maxRows; y++)
    {
        writer.Write("<tr>");
        for (var x = 0; x < maxCols; x++)
        {
            writer.Write("<td>");
            var item = grid[x, y];
            if (item != null)
            {
                //if there's an item at that grid location, call its template
                template(item).WriteTo(writer);
            }
            writer.Write("</td>");
        }
        writer.Write("</tr>");
    }
    writer.Write("</table>");
}

@using Examine;

@* Get the search term from query string *@
@{var searchTerm = Request.QueryString["search"];}

<ul class="search-results">
@foreach (var result in 
    ExamineManager.Instance.Search(searchTerm, true)) {    
    
    <li>
        <span>@result.Score</span>
        <a href="@umbraco.library.NiceUrl(result.Id)">
            @result.Fields["nodeName"]
        </a>        
    </li>    
    
}
</ul>

That’s it! Pretty darn easy.

And for all you sceptics who think there’s too much configuration involved to setup Examine, configuring Examine requires 3 lines of code. Yes its true, 3 lines, that’s it. Here’s the bare minimum setup:

1. Create an indexer under the ExamineIndexProviders section:

<add name="MyIndexer"
      type="UmbracoExamine.UmbracoContentIndexer, UmbracoExamine"/>

2. Create a searcher under the ExamineSearchProviders section:

<add name="MySearcher"
      type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"/>

3. Create an index set under the ExamineLuceneIndexSets config section:

<IndexSet SetName="MyIndexSet" 
    IndexPath="~/App_Data/TEMP/MyIndex" />

This will index all of your data in Umbraco and allow you to search against all of it. If you want to search on specific subsets, you can use the FluentAPI to search and of course if you want to modify your index, there’s much more you can do with the config if you like.

With Examine the sky is the limit, you can have an incredibly simple index and search mechanism up to an incredibly complex index with event handlers, etc… and a very complex search with fuzzy logic, proximity searches, etc…  And no matter what flavour you choose it is guaranteed to be VERY fast and doesn’t matter how much data you’re searching against.

I also STRONGLY advise you to use the latest release on CodePlex: http://examine.codeplex.com/releases/view/50781 . There will also be version 1.1 coming out very soon.

Enjoy!

I’ve recently spent quite a lot of time researching and prototyping different ways to create a plugin engine in ASP.NET MVC3 and primarily finding a nice way to load plugins (DLLs) in from outside of the ‘bin’ folder. Although this post focuses on MVC3, I am sure that the same principles will apply for other MVC versions.

The Issues

Loading DLLs from outside of the ‘bin’ folder isn’t really anything new or cutting edge, however when working with MVC this becomes more difficult. This is primarily due to how MVC loads/finds types that it needs to process including controllers, view models (more precisely the generic argument passed to a ViewPage or used with the @model declaration in Razor), model binders, etc… MVC is very tied to the BuildManager which is the mechanism for compiling views, and locating other services such as controllers. By default the BuildManager is only familiar with assembies in the ‘bin’ folder and in the GAC, so if you start putting DLLs in folders outside of the ‘bin’ then it won’t be able to locate the MVC services and objects that you might want it to be referencing.

Another issue that needs to be dealt with is DLL file locking. When a plugin DLL is loaded and is in use the CLR will lock the file. This becomes an an issue if developers want to update the plugin DLL while the website is running since they won’t be able to unless they bump the web.config or take the site down. This holds true for MEF and how it loads DLLs as well.

.Net 4 to the rescue… almost

One of the new features in .Net 4 is the ability to execute code before the app initializes which compliments another new feature of the BuildManager that lets you add assembly references to it at runtime (which must be done on application pre-init). Here’s a nice little reference to these new features from Phil Haack: http://haacked.com/archive/2010/05/16/three-hidden-extensibility-gems-in-asp-net-4.aspx.  This is essential to making a plugin framework work with MVC so that the BuildManager knows where to reference your plugin DLLs outside of the ‘bin’. However, this isn’t the end of the story.

Strongly typed Views with model Types located in plugin DLLs

Unfortunately if you have a view that is strongly typed to a model that exists outside of the ‘bin’, then you’ll find out very quickly that it doesn’t work and it won’t actually tell you why. This is because the RazorViewEngine  uses the BuildManager to compile the view into a dynamic assembly but then uses Activator.CreateInstance to instantiate the newly compiled object. This is where the problem lies, the current AppDomain doesn’t know how to resolve the model Type for the strongly typed view since it doesn’t exist in the ‘bin’ or GAC.  An even worse part about this scenario is that you don’t get any error message telling you why this isn’t working, or where the problem is. Instead you get the nice MVC view not found error: “…or its master was not found or no view engine supports the searched locations. The following locations were searched: ….” telling you that it has searched for views in all of the ViewEngine locations and couldn’t find it… which is actually not the error at all.  Deep in the MVC3 source, it tries to instantiate the view object from the dynamic assembly and it fails so it just keeps looking for that view in the rest of the ViewEngine paths.

NOTE: Even though in MVC3 there’s a new IViewPageActivator which should be responsible for instantiating the views that have been compiled with the BuildManager, implementing a custom IViewPageActivator to handle this still does not work because somewhere in the MVC3 codebase fails before the call to the IViewPageActivator which has to do with resolving an Assembly that is not in the ‘bin’.

Full trust

When working in Full Trust we have a few options for dealing with the above scenario:

• Use the AppDomain’s ResolveAssembly event
  • By subscribing to this event, you are able to instruct the AppDomain where to look when it can’t find a reference to a Type.
  • This is easily done by checking if your plugin assemblies match the assembly being searched for, and then returning the Assembly object if found:

static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    var pluginsFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/Plugins"));
    return (from f in pluginsFolder.GetFiles("*.dll", SearchOption.AllDirectories)
            let assemblyName = AssemblyName.GetAssemblyName(f.FullName)
            where assemblyName.FullName == args.Name || assemblyName.FullName.Split(',')[0] == args.Name
            select Assembly.LoadFile(f.FullName)).FirstOrDefault();
}

• Shadow copy your plugin DLLs into the AppDomain’s DynamicDirectory.
  • This is the directory that the BuildManager compiles it’s dynamic assemblies into and is also a directory that the AppDomain looks to when resolving Type’s from Assemblies.
  • You can shadow copy your plugin DLLs to this folder on app pre-init and everything ‘should just work’
• Replace the RazorViewEngine with a custom razor view engine that compiles views manually but makes references to the appropriate plugin DLLs
  • I actually had this working in an Umbraco v5 prototype but it is hugely overkill and unnecessary plus you actually would have to replace the RazorViewEngine which is pretty absurd.

The burden of Medium Trust

In the MVC world there’s only a couple hurdles to jump when loading in plugins from outside of the ‘bin’ folder in Full Trust. In Medium Trust however, things get interesting. Unfortunately in Medium Trust it is not possible to handle the AssemblyResolve event and it’s also not possible to access the DynamicDirectory of the AppDomain so the above two solutions get thrown out the window. Further to this it seems as though you can’t use CodeDom in Medium Trust to custom compile views.

Previous attempts

For a while I began to think that this wasn’t possible and I thought I tried everything:

• Shadow copying DLLs from the plugins folder into the ‘bin’ folder on application pre-init
  • This fails because even during app pre-init, the application pool will still recycle. Well, it doesn’t actually ‘fail’ unless you keep re-copying the DLL into the bin. If you check if it already exists and don’t copy into the bin than this solution will work for you but it’s hardly a ‘solution’ since you might as well just put all your DLLs into the ‘bin’ in the first place.
• Trying to use sub folders of the ‘bin’ folder to load plugins.
  • Turns out that ASP.Net doesn’t by default load in DLLs that exist in sub folders of the bin, though from research it looks like standard .Net apps actually do.
  • Another interesting point was that if you try to copy a DLL into a sub folder of the bin during application pre-init you get a funky error:  “Storage scopes cannot be created when _AppStart is executing”. It seems that ASP.Net is monitoring all changes in the bin folder regardless of whether or not they are in sub folders but still doesn’t load or reference those assemblies.

An easy solution

So, the easy solution is to just set a ‘privatePath’ on the ‘probing’ element in your web.config to tell the AppDomain to also look for Assemblies/Types in the specified folders. I did try this before when trying to load plugins from sub folders in the bin and couldn’t get it to work. I’m not sure if I was ‘doing it wrong’ but it definitely wasn’t working then, either that or attempting to set this in sub folders of the bin just doesn’t work.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">       
    <probing privatePath="Plugins/temp" />

DLL file locking

Since plugin DLLs get locked by the CLR when they are loaded, we need to work around this. The solution is to shadow copy the DLLs to another folder on application pre-init. As mentioned previously, this is one of the ways to get plugins loaded in Full Trust and in my opinion is the nicest way to do it since it kills 2 birds with one stone. In Medium Trust however, we’ll have to jump through some hoops and shadow copy the DLLs to a temp folder that exists within the web application. IMPORTANT: When you’re copying DLLs you might be tempted to modify the name of the DLL by adding a version number or similar, but this will NOT work and you’ll get a “The located assembly's manifest definition … does not match the assembly reference.” exception.

Solution

UPDATE: The latest version of this code can be found in the Umbraco v5 source code. The following code does work but there’s been a lot of enhancements to it in the Umbraco core. Here’s the latest changeset as of 16/16/2012 Umbraco v5 PluginManager.cs

Working in Full Trust, the simplest solution is to shadow copy your plugin DLLs into your AppDomain DynamicDirectory. Working in Medium Trust you’ll need to do the following:

• On application pre-init:
  • Shadow copy all of your plugin DLLs to a temporary folder in your web application (not in the ‘bin’)
  • Add all of the copied DLLs to be referenced by the BuildManager
• Add all folder paths to the privatePath attribute of the probing element in your web.config to point to where you will be copying your DLLs
  • If you have more than one, you need to semi-colon separate them

Thanks to Glenn Block @ Microsoft who gave me a few suggestions regarding DLL file locking with MEF, Assembly load contexts and probing paths! You put me back on track after I had pretty much given up.

Here’s the code to do the shadow copying and providing the Assemblies to the BuildManager on application pre-init (make sure you set the privatePath on the probing element in your web.config first!!)

using System.Linq;
using System.Web;
using System.IO;
using System.Web.Hosting;
using System.Web.Compilation;
using System.Reflection;

[assembly: PreApplicationStartMethod(typeof(PluginFramework.Plugins.PreApplicationInit), "Initialize")]

namespace PluginFramework.Plugins
{
    public class PreApplicationInit
    {

        static PreApplicationInit()
        {
            PluginFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins"));
            ShadowCopyFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins/temp"));
        }

        /// <summary>
        /// The source plugin folder from which to shadow copy from
        /// </summary>
        /// <remarks>
        /// This folder can contain sub folderst to organize plugin types
        /// </remarks>
        private static readonly DirectoryInfo PluginFolder;

        /// <summary>
        /// The folder to shadow copy the plugin DLLs to use for running the app
        /// </summary>
        private static readonly DirectoryInfo ShadowCopyFolder;

        public static void Initialize()
        {            
            Directory.CreateDirectory(ShadowCopyFolder.FullName);

            //clear out plugins)
            foreach (var f in ShadowCopyFolder.GetFiles("*.dll", SearchOption.AllDirectories))
            {
                f.Delete();
            }            

            //shadow copy files
            foreach (var plug in PluginFolder.GetFiles("*.dll", SearchOption.AllDirectories))
            {
                var di = Directory.CreateDirectory(Path.Combine(ShadowCopyFolder.FullName, plug.Directory.Name));
                // NOTE: You cannot rename the plugin DLL to a different name, it will fail because the assembly name is part if it's manifest
                // (a reference to how assemblies are loaded: http://msdn.microsoft.com/en-us/library/yx7xezcf )
                File.Copy(plug.FullName, Path.Combine(di.FullName, plug.Name), true);
            }
            
            // Now, we need to tell the BuildManager that our plugin DLLs exists and to reference them.
            // There are different Assembly Load Contexts that we need to take into account which 
            // are defined in this article here:
            // http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx

            // * This will put the plugin assemblies in the 'Load' context
            // This works but requires a 'probing' folder be defined in the web.config
            foreach (var a in
                ShadowCopyFolder
                .GetFiles("*.dll", SearchOption.AllDirectories)
                .Select(x =>  AssemblyName.GetAssemblyName(x.FullName))
                .Select(x => Assembly.Load(x.FullName)))
            {
                BuildManager.AddReferencedAssembly(a);
            }

            // * This will put the plugin assemblies in the 'LoadFrom' context
            // This works but requires a 'probing' folder be defined in the web.config
            // This is the slowest and most error prone version of the Load contexts.            
            //foreach (var a in
            //    ShadowCopyFolder
            //    .GetFiles("*.dll", SearchOption.AllDirectories)
            //    .Select(plug => Assembly.LoadFrom(plug.FullName)))
            //{
            //    BuildManager.AddReferencedAssembly(a);
            //}

            // * This will put the plugin assemblies in the 'Neither' context ( i think )
            // This nearly works but fails during view compilation.
            // This DOES work for resolving controllers but during view compilation which is done with the RazorViewEngine, 
            // the CodeDom building doesn't reference the plugin assemblies directly.
            //foreach (var a in
            //    ShadowCopyFolder
            //    .GetFiles("*.dll", SearchOption.AllDirectories)
            //    .Select(plug => Assembly.Load(File.ReadAllBytes(plug.FullName))))
            //{
            //    BuildManager.AddReferencedAssembly(a);
            //}

        }
    }
}