Create magic with APE

I would like to present to you, “APE”. APE stands for “Awesome Property Extractor” and is simply a framework for extracting properties and their values from arbitrary data and turn them into strongly typed C# properties and values.

To begin with, we have created a package for Umbraco called APE.Umbraco.

What is APE.Umbraco

APE.Umbraco is a nuget package for extracting Umbraco properties and dictionary items and transform them into strongly typed C# properties that can be accessed using “dot-notation”.

APE accesses the database and retrieves all dictionary items, doctypes and their properties and data types, and builds a bunch of strongly typed classes.

These classes give you access to all the values without ever opening the Umbraco back office, just to look what a given alias or dictionary key was called. All you need to know is what doctype the property is on, and you can access all the properties, said doctype has, even those that has been inherited. You can even “dot” your way to all the doctypes, using a common static class called DocTypes, we even have a class called Dictionary!

We have created two releases of this package:

  • APE.Umbraco v1.0, this release is built for Umbraco 6 and does not support Umbraco 7, for that we have,
  • APE.Umbraco v2.0, this release is built for Umbraco 7, and does not work with Umbraco 6!

1.0 is released to support “old” sites and will not be updated unless a bug is reported. 2.0+ is the one we will build upon and add features to.

What’s in the package

The package contains the following:

APE.Umbraco.dll, this is the “magic box”. This assembly is merely an implementation of the method described in my earlier post.

This folder tree:

  • Classes
    • APE
    • Cms

The APE folder contains a FileManager.ttinclude file. This file allows us to split the generated classes into multiple files, improving readability. It will be released with each APE.* release.

The Cms folder contains two T4 templates: This template, extracts all dictionary items from the database using the umbracoDbDSN connection string and generates a class containing all dictionary keys and a class for getting dictionary values using said keys. The other file is It uses the same connection string to extract all document types and their properties, maps the Umbraco data into C# classes and properties into a class pattern like the one I described in my previous post, “Umbraco and .NET magic”.

The future

In the future we will have an APE.UCommerce package and many other APE packages. You can help us making APE the best alternative to Code First on platforms not build to support Code first, like Umbraco and uCommerce. A long with the release of APE.Umbraco, we are making the whole deal open source on GitHub: This is also the place to find documentation and code examples, post bug reports and make pull requests.

It’s awesome! Where can I get it?!

As this package is intended for developers it is only released through NuGet. There will not be an Umbraco Package. It just makes no sense to create an Umbraco package for something that needs Visual Studio to work, (I don’t know if it works in WebMatrix).

To get the package, look no further.

To see examples on what APE can do, take a look at the wiki:

Hope you like the package and will help making this the goto package for any Umbraco project.

  • This package has a great potential thanks 🙂
    Where can I submit comments and bugs?

  • Dan

    Sorry in advance for the newb question, but how is APE different from

    Do they all accomplish the same thing in different ways? Or am I just daft and they do completely different things?

    I’m just looking for a good approach to strongly typed view models. Thanks!

  • Hi, sorry for the late reply, your post was flagged as spam, and I wasn’t noticed as I was supposed to be.

    The thing that makes APE stand out, is that it doesn’t force you to work differently. It’s in essence just an auto generated list of aliases that you can use as you like. We don’t map IPublishedContent to a view model, we map properties only.

    Most developers out there are using CurrentPage.GetPropertyValue(“someRandomString”);
    What we do, is simply taking away the type parameter and the magic string. You can now code as you have always done, but get strongly typed values when calling GetPropertyValue, without needing to know the property type or the exact alias.

    If you are looking for strongly typed view models and best practices, I would recommend looking at my article:

    Hope this clarifies a bit.