I believe an issue we're running into might be related to the lambda cache in Glass - I'm also concerned about the performance ramifications if we were to disable it. Has anyone done this and experienced any performance issues?

Edit - this was the original issue:

Exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
Source: Anonymously Hosted DynamicMethods Assembly
    at lambda_method(Closure , ContentBlurbViewModel )
    at Glass.Mapper.Sc.GlassHtml.MakeEditable[T](Expression`1 field, Expression`1 standardOutput, T model, Object parameters, Context context, Database database, TextWriter writer) in c:\TeamCity\buildAgent\work\8567e2ba106d3992\Source\Glass.Mapper.Sc\GlassHtml.cs:line 616

Lambda(s) that this fails on:

@Html.Glass().Editable(a => a.Heading)
@Html.Glass().Editable(a => a.Subtitle)
@Html.Glass().Editable(a => a.RichText1)

All of these lambdas are in the same cshtml view and share a view model. It looks like somehow or another the proxy object is returning nulls for the properties and Editable starts failing and it gets cached.

  • What is the original issue? Oct 6, 2016 at 14:18
  • Can you post the original lambda? Oct 6, 2016 at 14:22
  • 1
    Updated the question with the issue - this would pop up randomly on the site and then would stay like that until we recycled the app pool. Oct 6, 2016 at 14:22
  • Did this happen across all pages or just a single page? Oct 6, 2016 at 14:24
  • 1
    A single page. Lambda is going up in the question. Oct 6, 2016 at 14:24

1 Answer 1


The lambda seems correct, and there are no obvious reason for failure. I think the next step is to log this as a big on Github:


You can turn the lambda cache off using the following code in the GlassMapperScCustom class:

public static  class GlassMapperScCustom
    public static IDependencyResolver CreateResolver(){
        var config = new Glass.Mapper.Sc.Config();
        config.UseGlassHtmlLambdaCache = false;

        var dependencyResolver = new DependencyResolver(config);

        // add any changes to the standard resolver here
        return dependencyResolver;

Another thing to try is wrapping your lambda's in a null check:

@if(Model != null){


  • 1
    Are there any performance concerns that need to be considered when disabling the lambda cache? Oct 8, 2016 at 15:25
  • 1
    There will be a small decrease because every time you use the lambda it has to be compiled. I don't have exact numbers on the impact. Oct 10, 2016 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.