Instead of having to use inheritance to get properties onto pages I now mostly use interfaces, especially for “side-features” like stuff that is supposed to go into the sidebar of a site it doesn’t always make sense to specify this using inheritance, sooner or later you end up with a page which needs the side-feature, but have nothing else in common with the other pages, and inheritance trees based on side-feature is an antipattern only until you add side-feature number two, then it becomes impossible.

Now for years I have preferred to use PTB *only* for defining the pages at startup-time, and not for extracting the data from them during run-time. (I have found that the convenience of specifying prop names as strings to EPiServer:Property far outweighs the potential for harm during refactoring) And if this is all you are doing then both 1.3.0 and 1.3.1 will work fine for you.

It wasn’t until some collegues of mine started using the new interface features that I became aware that I had introduced a bug into PTB: Whenever you declare page type properties using interfaces you cannot get those properties back using the same interface. As I said I never used PTB for this purpose, that’s my excuse and I’m sticking to it.

10 minutes after being made aware of this defect I had created a fix for it and shipped it to Joel.

That’s where it stopped. Joel never did release a fixed version of PTB 1.3.0, and when 1.3.1 came out it had the same bug in it.

I asked Joel why during NDC2011 and he claimed that he had found some problem with the fix but couldn’t remember what that was exactly.

This means that whenever I start up a new project I always have to use my special-build PTB and not the official one.

Anyhoo, I thought more people might be interested in the fix, so here goes, all you need to change the implementation of one method in PageTypeBuilder/Reflection/MethodInfoExtensions.cs:

...
public static bool IsGetterOrSetterForPropertyWithAttribute(this MethodInfo propertyGetterOrSetter, Type attributeType)
        {
            if (!propertyGetterOrSetter.IsGetterOrSetter())
                return false;

            string propertyName = propertyGetterOrSetter.GetPropertyName();
            PropertyInfo property = propertyGetterOrSetter.DeclaringType.GetAllValidPageTypePropertiesFromClassAndImplementedInterfaces().FirstOrDefault(p=>p.Name.Equals(propertyName));

            if (property == null)
                return false;

            return property.HasAttribute(attributeType);
        }
...

In the time since I have been playing around with ways to empower administrators of EPiServer sites to change the globalization texts themselves without having to involve developers directly. I don’t have know how many times the customer has come to me and requested that this string should be that and required me to circumvent our standard deployment routine so that “we can get the new string out immediately”

What I have come up with is basically a framework that allows each text used to be persistently overridden in runtime by an administrator. Combined with the T4-goodness from my previous post I believe I have made something that could turn out to be useful for some other sites. I Have decided to call it EPiLang (yes, I am inspired by the awesome EPiImage framework)

Under normal conditions you can access globalized strings in three different ways in EPiServer:

1. <%= LanguageManager.Instance.Translate(“/xpath/to/string”) %>
2. <EPiServer:Translate runat=”server”  Text=”/xpath/to/string” />
3. <%$ Resources: EPiServer, xpath.to.string%>

• <%= LanguageService.Translate(“/xpath/to/string”) %>
• <EPiLang:Translate runat=”server”  Text=”/xpath/to/string” />
• <%$ Resources: EPiServer, xpath.to.string%>
• <%= EPiLang.xpath.to.string.Text %>

If you add a new custom property type and make use of it all in one go then PTB will *sometimes* throw an UnmappablePropertyTypeException. The reason is that EPiServer does not yet know of a given property, (the reflection magic which makes EPi startup times such a nightmare has not yet been executed on the assembly containing the prop and thus registered the prop to the EPi DB)

(this is not a problem on later PTB versions, but they don’t support EPiServer CMS 5)

the reason this only crops up *sometimes* is that the order in which EPi CMS 5 does its thing is important. If it finds the DLL with the prop first then you are ok, if it finds the PTB page type definitions first then you get the exception. This wouldn’t be such a huge problem if EPi continued wth dll registration after PTB throws up, so that the property in question would get into the DB and thus be ready for the next time PTB starts up, but then I wouldn’t be writing this blogpost if it did.

Even if you are really careful with always adding the custom property first, starting the site, adding the use of the property to a PTB page type, starting the site again, you are vulnerable when deploying to a new system (test / stage / prod) or when rolling back to a previous version of the EPiServer DB.

PageTypeBuilder comes with a funnily named config setting you can enable: “disablePageTypeUpdation”, but setting this to true does not stop the exception from cropping up, as the thing you are disabling is the “updation” of already known page types, it still goes through and adds new pagetypes, and more importantly: it validates the entire PTB setup, which fails as there is an unknown property type.

So I made my own version of PTB 1.1 which actually lets you disable it completely so that it doesn’t throw a spanner in the works when registering new custom properties, the new property is called disablePageTypeBuilder, and its implementation is thusly:

\Configuration\PageTypeBuilderConfiguration.cs

...
        [ConfigurationProperty("disablePageTypeBuilder", IsRequired = false)]
        public virtual bool DisablePageTypeBuilder
        {
            get
            {
                return (bool)this["disablePageTypeBuilder"];
            }
        }
...

\Initializer.cs :

...
  public static void Start()
        {
            lock (_lockObject)
            {
                if (_started)
                    return;

                PageTypeBuilderConfiguration configuration = PageTypeBuilderConfiguration.GetConfiguration();
                if (!configuration.DisablePageTypeBuilder)
                {
                    PageTypeSynchronizer synchronizer = new PageTypeSynchronizer(new PageTypeDefinitionLocator(),
                                                                                 configuration);

                    synchronizer.SynchronizePageTypes();

                    DataFactory.Instance.LoadedPage += DataFactory_LoadedPage;
                    DataFactory.Instance.LoadedChildren += DataFactory_LoadedChildren;
                    DataFactory.Instance.LoadedDefaultPageData += DataFactory_LoadedPage;
                }

                _started = true;
            }
        }
...

\Synchronization\Validation\UnmappablePropertyTypeException.cs

    public class UnmappablePropertyTypeException : PageTypeBuilderException
    {
        private const string NewMappingsHint =
            @"
You may try to disable PageTypeBuilder using the pagetypebuilder config section
( <section name=""pageTypeBuilder"" type=""PageTypeBuilder.Configuration.PageTypeBuilderConfiguration, PageTypeBuilder""/> )
with attribute <pageTypeBuilder disablePageTypeBuilder=""True"" />
and run the site once without PTB to register any new custom properties first,
then reactivate PTB to make use of new properties";

        public UnmappablePropertyTypeException()
        {
        }

        public UnmappablePropertyTypeException(string message) : base(message + NewMappingsHint)
        {

        }

        public UnmappablePropertyTypeException(string message, Exception innerException)
            : base(message + NewMappingsHint, innerException)
        {
        }
    }

This means that when you get the exception you can just turn off PTB, restart, then turn on PTB and restart and you’re set

You disable PageTypeBuilder like this in web.config:

...
    <section name="pageTypeBuilder" type="PageTypeBuilder.Configuration.PageTypeBuilderConfiguration, PageTypeBuilder"/>
...
    <pageTypeBuilder disablePageTypeBuilder="true" />
...

If you’re too lazy to compile it yourself you can download this file: PTB_With_Shutoff_switch.zip, and change from .doc to .zip, (thanks a lot wordpress….) unzip it and use it instead of the regular PTB1.1

New default ClientID generation scheme in .net 4 disrupts EPiServer’s javascripts

If you find youself getting the following javascript exception when creating pages or expanding nodes in the edit tree in episerver:

error: the target Fullregion$explorertreeview$treeview for the callback could not be found or dit not implement icallbackeventhandler

The solution is to add the following attribute to web.config: under configuration > system.web > pages :  clientIDMode=”AutoID”

You can scope this to only be applied on the util and UI locations if you don’t want the old school ID generation scheme applied globally

Validation is more strict in .net 4.0

When editing pages and submitting rich text content containing tags you might get Asp.net complaining to you that you need to turn off eventvalidation, but in addition you also need to instruct asp.net 4.0 to use <httpRuntime requestValidationMode=”2.0″ /> under configuration > system.web

<!-- START T4 Hack -->
<dependentAssembly> 
  <assemblyIdentity name="Microsoft.VisualStudio.TextTemplating" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
  <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" /> 
</dependentAssembly> 
<dependentAssembly> 
  <assemblyIdentity name="Microsoft.VisualStudio.TextTemplating.VSHost" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
  <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" /> 
</dependentAssembly>
<!-- END T4 Hack -->

You also need to explicitly declare that you want to use C# 3.5 in the top of the .tt file like this:

<#@ template debug="true" language="C#v3.5" #>

Let me explain: WebActivator is something you will probably see more and more of the more you start to use modules from NuGet. It is a neat little dll which allows you to specify anywhere in your code that a certain method is to be called on application startup. See this example from Ninject, this class gets added to your solution when installing the ninject package with nuget:

[assembly: WebActivator.PreApplicationStartMethod(typeof(SinsenWeb.Web.AppStart_NinjectMVC3), "Start")]
namespace YourNameSpace {
    public static class AppStart_NinjectMVC3 {
        public static void RegisterServices(IKernel kernel) {
            //kernel.Bind<IThingRepository>().To<SqlThingRepository>();
        }

        public static void Start() {
            // Create Ninject DI Kernel
            IKernel kernel = new StandardKernel();

            // Register services with our Ninject DI Container
            RegisterServices(kernel);

            // Tell ASP.NET MVC 3 to use our Ninject DI Container
            DependencyResolver.SetResolver(new NinjectServiceLocator(kernel));
        }
    }

Ignore the ninject specific stuff. The goodness that webactivator brings to the table is the first line where a usage of the webactivator attribute will result in a certain method will be called on startup.

Interested in knowing just *how* WebActivator manages to do this I looked up the sourcecode. Latest version of  which is available here

as it only consists of two classes, the attribute which you can include (like ninject did) and the implementation of the logic I thought it would be easy to get a handle on this.

I’ll include the two sources here so you can see if you’re smarter than me in figuring out how this works.
Attribute:

using System;
using System.Reflection;

namespace WebActivator {
    // This attribute is similar to its System.Web namesake, except that
    // it can be used multiple times on an assembly.
    [AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
    public sealed class PreApplicationStartMethodAttribute : Attribute {
        private Type _type;
        private string _methodName;

        public PreApplicationStartMethodAttribute(Type type, string methodName) {
            _type = type;
            _methodName = methodName;
        }

        public Type Type {
            get {
                return _type;
            }
        }

        public string MethodName {
            get {
                return _methodName;
            }
        }

        public void InvokeMethod() {
            // Get the method
            MethodInfo method = Type.GetMethod(
                MethodName,
                BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.Public);

            if (method == null) {
                throw new ArgumentException(
                    String.Format("The type {0} doesn't have a static method named {1}",
                        Type, MethodName));
            }

            // Invoke it
            method.Invoke(null, null);
        }
    }
}

Implementation:

using System;
using System.IO;
using System.Reflection;
using System.Web;

namespace WebActivator {
    public class PreApplicationStartCode {
        public static void Start() {
            // Go through all the bin assemblies
            foreach (var assemblyFile in Directory.GetFiles(HttpRuntime.BinDirectory, "*.dll")) {
                var assembly = Assembly.LoadFrom(assemblyFile);

                // Go through all the PreApplicationStartMethodAttribute attributes
                // Note that this is *our* attribute, not the System.Web namesake
                foreach (PreApplicationStartMethodAttribute preStartAttrib in assembly.GetCustomAttributes(
                    typeof(PreApplicationStartMethodAttribute),
                    inherit: false)) {

                    // Invoke the method that the attribute points to
                    preStartAttrib.InvokeMethod();
                }
            }
        }
    }
}

Hmm, so basically, we declare an attribute and we have a static method which when run will track down all instances of this attribute in all dlls in the bin folder and fire the method as specified in each of those instances.

But *who* calls the static method?

I had a look in the Properties\AssemblyInfo.cs file which looks like this:

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Web;

// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("WebActivator")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Microsoft")]
[assembly: AssemblyProduct("WebActivator")]
[assembly: AssemblyCopyright("Copyright © Microsoft 2010")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("3bc078bd-ade4-4271-964f-1d041508c419")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

[assembly: PreApplicationStartMethod(typeof(WebActivator.PreApplicationStartCode), "Start")]

and in the bottom of that file I finally started to believe that magic little elves live within the jit-compiler and make everything fine and dandy even though it seems like the feature is using itself to start itself.

Maybe there really *are* turtles all the way down?

Have you spotted how it works yet?

I’ll give you some whitespace to think of the solution before I blurt it out and ruin your fun

WebActivator.PreApplicationStartMethod != System.Web.PreApplicationStartMethod

WebActivator doesn’t use itself but rather a feature of the Asp.Net 4.0 runtime to start itself off. The whole motivation for WebActivator is that the feature built into Asp.Net 4.0 has a design flaw in that it only allows a single instance of the attribute within each dll, making it hard to use for NuGet scenarios where you would want to use multiple different packages each with their own startup logic independent of eachother, you would have to manually merge the logic into one place if you wanted to use the Asp.Net 4.0 implementation.

However, since WebActivator.dll is a tiny separate dll it can make use of the asp.net feature to kickstart the other dlls.

I think that I would prefer if the AssemblyInfo.cs file was a little more specific in its usage of the asp.net feature, seeing that it’s basically reimplementing it itself. Instead of relying on a using statement for System.Web, I would prefer if the attribute was declared as

[assembly: System.Web.PreApplicationStartMethod(typeof(WebActivator.PreApplicationStartCode), "Start")]

In my simplistic world-view the hourly report forms you have to fill out are a necessary evil, but they’re still evil

So, when I got subcontracted through a firm with this input process: (snip: http://screencast.com/t/mZ51HlB8B )
First I threw a fit and then I started to think: “is there any way for me to automate this”.

as it turns out, yes there is. I won’t bore you with all the juicy details on how to create a chrome plugin that modifies a webpage on your behalf,
but in essence all you do is to have a manifest file declare on which urls this plugin should kick in, and what javascript files it should inject at the end of the loading process for that page.

For me in this case the file (which must be called manifest.json by the way) looks like this:

{
  "name" : "ElanIt Timereg decrapifier",
  "version" : "0.1",
  "description" : "Makes timereg useable",

  "content_scripts": [
    {
      "matches": ["https://timereg.elanit.no/Default.aspx*"],
      "js": ["jquery.js", "timeregmod.js"]
    }
  ]
}

which as you can see loads a bundled version of a minified jquery 1.4.2 and also a custom js file which contains the logic I needed to inject onto the page.
here is the timeregmod.js file:

$.fn.getNonColSpanIndex = function () {
    if (!$(this).is('td') && !$(this).is('th'))
        return -1;

    var allCells = this.parent('tr').children();
    var normalIndex = allCells.index(this);
    var nonColSpanIndex = 0;

    allCells.each(
        function (i, item) {
            if (i == normalIndex)
                return false;

            var colspan = $(this).attr('colspan');
            colspan = colspan ? parseInt(colspan) : 1;
            nonColSpanIndex += colspan;
        }
    );

    return nonColSpanIndex;
};

$(document).ready(function () {
    findAllWorkDays($('.ITMTimesheetDetail')).not(':last').each(function () {
        var tr = $(this);
        tr.append($('<td></td>').append($('<input type="button"></input>)').val('>>').css('font-size','9px').click(function () {
            var input = $(this);
            var thisRow = input.parents('tr').first();

            var nextRow = findNextWorkDay(thisRow);

            $('input[type=text]', thisRow).each(function () {
                var textbox = $(this);
                var index = textbox.parent().getNonColSpanIndex();

                $('td:eq(' + index + ') input', nextRow).val(textbox.val());
            });
        })));
    });
    $('.ITMTimesheetDetail tr:eq(2)').each(function () {
        var tr = $(this);
        tr.append($('<td></td>').append($('<input type="button"></input>)').val('Kopier til alle').css('font-size', '9px').click(function () {
            $('input[type=text]', tr).each(function () {
                var textbox = $(this);
                var value = textbox.val();
                var index = textbox.parent().getNonColSpanIndex();
                var workdays = findAllWorkDays('.ITMTimesheetDetail');
                $('td:eq(' + index + ') input', workdays).val(value);
            });
        })));
    });
});

function findAllWorkDays(table) {
    return $('tr:gt(1)', table).filter(function (index) {
        var tr = $(this);
        return isWorkDayRow(tr);
    });
}

function isWorkDayRow(tr){
    if(tr.children().first().hasClass('ITMTimesheetDetailDayOfMonthHoliday') || tr.children().first().hasClass('ITMTimesheetDetailDayOfMonthSaturday')){
        return false;
    }
    return true;
}

function findNextWorkDay(currentRow) {
   var nextRow = currentRow.next();

   while (!isWorkDayRow(nextRow)) {
       nextRow = nextRow.next();
   }
   return nextRow;
}

I won’t pretend that I’m overly happy with the javascript, it should be shorter and better, but it gets the job done, so I’m stopping working on it.

The timesheet application (which is called Manpower Timereg apparently) now looks like this for me (when browsing using google chrome with the plugin loaded):
http://screencast.com/t/cpBtfwBe7t7

(yes, the buttons on the right hand side was added by this plugin).

SO: if you have to deal with this (dare I say somewhat challenging) system and would like to improve your own experience, feel free to take the sourcecode in this blogpost and create your own chrome plugin. You probably want to change the url in manifest.json (unless you happen to be subcontracting for ElanIt in norway)

creating a chrome plugin based on this is as simple as:
- create a new folder and call it MySpecialPlugin or something like that
- download the latest version of jquery into that folder and rename the file to jquery.js
- put the two files as described in this blogpost into the folder.
- in chrome: navigate to the url chrome://extensions and click the “load unpacked extension”
- select the folder you created a few bullets ago

and voila: Bob’s your uncle

My basic premise was this:
- End users will connect to the site I’m making use IE7 under “local intranet” thereby magically getting access without logging in. (WindowsRoleProvider)
- developers / support personnel / admins will use EPiServer logins (SqlRoleProvider)
- in order to get this to work I need to use the MultiplexingRoleProvider.

There are numerous writeups on how to use the multiplexingroleprovider, but none actually say out loud *you cannot use MultiplexingRoleProvider and ALSO get automatic NTLM windows authentication* So now I’ve said it.

The first hint I got was this image from IIS when I tried to set it up: http://screencast.com/t/NjJiNzE0MDE where IIS7 complained that you cannot have your cake and eat it too (you can’t use both challenge-based (NTLM) and redirect-based (Forms) auth in the same app.

I talked to a few guys I trust and they convinced me that “it should be possible, I think I have done it at some point but I can’t remember how”. Time would convince me otherwise, though.

Setting up Multiplexer is easy, just look here: http://sdk.episerver.com/library/CMS5/Developers%20Guide/Membership%20and%20Role%20Providers.htm?id=24871
I always wondered what the “BUILTIN\” signifies in WindowsMembershipProvider, for the record it is there to nullify the prefix of the local groups on the machine (Administrators and Everyone) which are actually called BUILTIN\Administratos and BUILTIN\Everyone when under UAC

I was able to set up the MPRP easily enough, but the IE auto-login didn’t work.

I was able to get IE auto-login to work, but only using windows authentication only.
Also I wasn’t able to log in to localhost for some reason. but when I accessed the server from a different machine I could authenticate.

So then I got carried away on a wild goose chase (maybe?) with there might be problems using windows auth on localhost: http://support.microsoft.com/kb/896861/en-us So I regedited the server a few times and reset it a few times, cursed the sky a few times, fetal-cried a few brave tears, then I pulled myself together and went for one final google-push.

And lo and behold: http://www.andornot.com/blog/post/How-to-solve-4012-errors-related-to-Windows-Authentication-and-the-BUILTIN5cAdministrators-role-in-IIS-7.aspx

Turns out that when UAC is turned on on a Windows Server 2008, the BUILTIN\Administrators group is banned from authenticating, but only when the request is made from the local machine. (how weird is that? probably some security scenario I’m too tired to consider) So the final solution was to greate a new local group and assign appropriate God-like priviliges to that group, (I considered calling it Developersdevelopersdevelopers) and put all the devs into that group and configure the site to accept users belonging to devdevdev. So that we can deploy the site (admins only.. UAC is your friend here to help you) and also test that the deploy went well, all on the same machine.

PROGRESS!

]]>