WorkflowDesigner.aspx with your custom system masterpage – a better way

If you customised your system Master page and you work with Nintext workflows, I am pretty sure you came across the problem and description featured in this page:

3-step fix Nintex WorkflowDesigner.aspx with your custom system masterpage

Basically due to the customisations of the system masterpage the layout of the Nintext workflow designer might not render properly, sometimes making it impossible to create/edit workflows (my case).

Big kudos to the author for investigating this problem and coming up with solutions for it, but although they do work they are either hard or not supported by Nintex, in the author words:

Nintex has given me a stern wagging of their fingers and I need to tell you that Nintex does not support this modification. That’s why you need to keep the old Nintex file around and throw it back in if you need to talk to Nintex support.

Both solution revolve around on ways to replace the masterpage with the standard v4 masterpage just for the workflow designer.

The solutions suggested pointed me in the right direction, what I propose to solve this problem is to implement a module deployed as a webapplication feature that intercepts the request, checks if the page requested is WorkflowDesigner.aspx and replaces with the standard v4 Masterpage.

Here is the implementation:

public class MasterReplaceModule : IHttpModule
        public void Init(HttpApplication context)
            context.PreRequestHandlerExecute += context_PreRequestHandlerExecute;

        void context_PreRequestHandlerExecute(object sender, EventArgs e)
            Page page = HttpContext.Current.CurrentHandler as Page;
            if (page != null)
                page.PreInit += page_PreInit;

        void page_PreInit(object sender, EventArgs e)
            Page page = sender as Page;
            if (page != null && System.IO.Path.GetFileName(page.Request.PhysicalPath) == "WorkflowDesigner.aspx")
                page.MasterPageFile = "../v4.master";

        public void Dispose()


If you are not familiar on what is the best way to implement a module in a sharepoint solution, you can either manually edit the webconfig by hand to include the module (very big no no!!!), or you can use SPWebConfigModification to do it.

You can call SPWebConfigModifications from a feature event receiver FeatureActivated event, which will inject the necessary xml in the web.config for you. Dont forget to remove it on FeatureDeactivating.

here is an example of a SPWebConfigModifications object wich injects a module declaration (IIS7):

var moduleModification = new SPWebConfigModification()
                Owner = "ApplicationName",
                Name = "add[@name='MyAwesomeModule']",
                Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode,
                Path = "configuration/system.webServer/modules",
                Sequence = 1,
                // The XML to insert as child node, make sure that used names match the Name selector
                Value ="<add name='MyAwesomeModule' type='FullNameSpace.MasterReplaceModule , AssemblyName, Version=, Culture=neutral, PublicKeyToken=7be6bd052a28e02f' />"

If you need help on how to apply the above in a feature receiver check this article:

Using SPWebConfigModification within a Feature Receiver

SPMetal fields retuning null, internal field name exceeds 32 chars

SPMetal is a great tool, of you don’t know SPMetal it’s an ORM tool that maps SharePoint objects to entity classes, it abstracts all of that CAML ugliness with a nice linq provider and it sort of works nicely. But as with almost everything in SharePoint it has its glitches.

I just come across a pretty nasty one. I have this entity that for some reason one of the fields was always returning null, no custom mappings completely auto-generated like the rest of my entities.

I have checked the generated CAML and the field is part of the viewfields parameter as expected. After a bit of debugging i realised that the internal field name didn’t match the one SPMetal was using to build the CAML. The reason is that apparently SharePoint truncates the internal field name if its length exceeds 32 characters. Now this should be fine but apparently SPMetal developers decided to hardcode the logic of conversion from display to internal, instead of querying the internal name when generating the entities. So a field named “Tools and Websites Link”, will be named internally as “Tools_x0020_and_x0020_Websites_x1”, and SPMetal will generate it as “Tools_x0020_and_x0020_Websites_x0020_Link”. Yep nasty.

There is a couple of solutions here, the most obvious one is to make your field name smaller, bear in mind that if you have spaces in your field name SharePoint replaces them with _x0020_ so if you have a lot of spaces you are guaranteed to hit this limit.

Another workaround is to manually set the internal field name as show in this post.

SharePoint Continuous Integration – The type or namespace name ‘xxx’ does not exist in the namespace ‘Microsoft.SharePoint’

There are multiple posts about setting up a SharePoint project building in a continuous integration server. One of the challenges assuming that SharePoint is not installed on the build server (as it shouldn’t) is to provide the necessary SharePoint assemblies for the build to happen. This is where out problems begun.

We decided to copy the libraries from 14ISAPI and keep them under source control for better portability. We could have installed them in the GAC witch would allow us to run multiple SharePoint project builds without having to provide all the necessary dlls all the time.

After getting all the assemblies and changing the references in the project to point our local versions we got several compilation errors building the project:

The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?

The type or namespace name 'Publishing' does not exist in the namespace 'Microsoft.SharePoint' (are you missing an assembly reference?)

The type or namespace name 'Taxonomy' does not exist in the namespace 'Microsoft.SharePoint' (are you missing an assembly reference?)

What stumped us is that we are including all those references. After spending an entire day trying different things we came across the problem. Publishing has a dependency on


Nothing on the error messages refer to this namespace. So After including the following library:

C:Program Files (x86)Microsoft Chart ControlsAssembliesSystem.Web.DataVisualization.dll

The project compiled as expected.

Change Credentials for SPSearch4

SPSearch4 is the service name for the SharePoint Foundation Search service. It is considered a best practice to run this service with an account other than the farm account. But where do you change it?

Usually you would change it in Central Administration > Security > Configure service accounts. But if you are reading this you probably have figured that SharePoint Foundation Search is not part of the available services you can pick on the list.

To configure the credentials you need to do it from here:

System Settings > Manage services on server > SharePoint Foundation Help Search