Cop is failing if a dependency of any assembly in the /bin cannot be loaded/resolved

[Pavel Veller]

It looks like Cop is trying to load/read all assemblies in /bin. It's probably done to search for interceptors or to get ready for JIT hooks based on JSON configuration. Either way, is there's an assembly that is missing a reference assembly Cop will not bootstrap. In my case I have an assembly that for some operations needs Nancy. I don't have Nancy in /bin but neither am I using those functions. Also, I am not asking Cop to intercept anything in that assembly and I am supplying my interceptors to Cop.Intercept().

A very similar exception was thrown by another dependency that wasn't properly redirected to the version that was in /bin.

Once I cleared up my /bin and added "missing" redirects Cop went ahead with the bootstrapping process but I wonder if there's a less obtrusive way to bootstrap Cop.

[Ricardo Barbosa]

Hi Pavel,

Thanks for reporting this issue back to us.

AutoDiscovery happens for interceptors and for intercepted types as well. Sometimes at the moment of bootstrap your intercepted types may not be loaded yet into the appdomain so CodeCop tries to discover those by scanning the bin.

To avoid that, please use the AssemblyPath property on the JSON file and point directly to the Assembly that has the type(s) you want intercepted

Here's an example:

{
    "Types": [
        {
            "TypeName": "ConsoleApplication1.FooClass, ConsoleApplication1",
            "Methods": [
                {
                    "MethodSignature": "FooMethod1()",
                    "Interceptors": [ "WriteMethodNameToConsoleInterceptor"]
                },
                {
                    "MethodSignature": "get_Property1()",
                    "Interceptors": [ "WriteMethodNameToConsoleInterceptor"]
                }
            ],

          "GenericArgumentTypes": [ ],
          "AssemblyPath":"C:\\Projects\\MyApp\\bin\\Foo.dll"
        }

    ],
    "GlobalInterceptors": ["GlobalFooInterceptor", "GlobalBarInterceptor[MethodName=~Foo]"],
    "Key":"Your product key or leave empty for free product mode"

}

Please tell us if that fixed the issue for you.

Thanks,

--Ricardo

[Pavel Veller]

Thanks Ricardo. I was trying the AssemblyPath as well but I don't think it helped. I was still experiencing those reflection errors from assembly loading. I will give it another try later. Right now I am struggling to get the Cop to bootstrap itself (see other issues that I have posted and thanks a lot for coming back to me that quickly!)

[Ricardo Barbosa]

Hi Pavel,

Same solution as issue #12, please try v.1.3.3 and use the AssemblyLoadConstraints property.

Thanks,

--Ricardo

[Pavel Veller]

Trying v1.3.3 with the AssemblyLoadConstraints and I still see the "Nancy" issue. Here's the error:

Exception: System.IO.FileNotFoundException
Message: Could not load file or assembly 'Nancy, Version=0.23.2.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

And here's my config for 1.3.3:

{
  "Types": [
    {
      "TypeName": "Score.Custom.Pipelines.Editor.RunComponentDatasourceLocationRules, Score.Custom",
      "Methods": [
        {
          "MethodSignature": "*",
          "Interceptors": [ "ScoreMonitoringInterceptor" ]
        }
      ],
      "GenericArgumentTypes": [ ]
    },
    {
      "TypeName": "Score.Custom.Pipelines.Editor.RunGetLookupSourceItemRules, Score.Custom",
      "Methods": [
        {
          "MethodSignature": "*",
          "Interceptors": [ "ScoreMonitoringInterceptor" ]
        }
      ],
      "GenericArgumentTypes": [ ]
    },
    {
      "TypeName": "Score.Data.Extensions.ItemExtensions, Score.Data",
      "Methods": [
        {
          "MethodSignature": "*",
          "Interceptors": [ "ScoreMonitoringInterceptor" ]
        }
      ],
      "GenericArgumentTypes": [ ]
    }
  ],
  "AssemblyLoadConstraints": ["Score.Custom", "Score.Data", "PG.CustomerOnline.Web"],
  "GlobalInterceptors": [ ],
  "Key":  ""
}

I am bootstrapping the same way. Here's my Global.asax:

<%@Application Language='C#' Inherits="Sitecore.Web.Application" %>
<script runat="server">
    void Application_Start(object sender, EventArgs e)
    {
        try
        {
            CodeCop.Core.Cop.Intercept(new [] { new PG.CustomerOnline.Web.Areas.Customer.ScoreMonitoringInterceptor() });   
        }
        catch (Exception exc)
        {
            var reflection = exc.InnerException as System.Reflection.ReflectionTypeLoadException;
            if (reflection != null)
            {
                foreach (var ex in reflection.LoaderExceptions)
                {
                    Sitecore.Diagnostics.Log.Error("COP", ex, this);
                }
            }

            throw;
        }
    }
</script>

I haven't tried the other utility you sent me yet.

[Ricardo Barbosa]

Sorry to hear that Pavel.

That's an odd behavior though .What the AssemblyLoadConstraints property does is restrict assembly discovery/loading to those 3 assemblies only. Are you 100% sure that none of those AssemblyLoadConstraints referenced assemblies holds a reference to Nancy?

[Pavel Veller]

Positive. The only assembly in that /bin that references Nancy is Sitecore.Ship.* and I would delete those to let CodeCop continue the bootstrap process. The AssemblyLoadConstraints didn't seem to change anything. I did look into CodeCop.dll and while it's control flow obfuscated I can still see the use of the setting. The JSON mapping attribute and the lambda in .Where on assemblies. What would help really is a special build of CodeCop with extra logging around bootstrapping and assembly loading that would tell you (and me) what exactly CodeCop is doing and where it gets stuck.