I'm getting an exception when I use ORMProfiler with v5.2

System.IO.FileNotFoundException was unhandled
Message: An unhandled exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
Additional information: Could not load file or assembly 'SD.Tools.BCLExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a3f87088dcb994e1' or one of its dependencies. The system cannot find the file specified.

This happens when I initialize the Interceptor.

SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("MyApp");

I can resolve it with a runtime redirect but I'd prefer not to need that.

      <dependentAssembly>
        <assemblyIdentity name="SD.Tools.BCLExtensions" publicKeyToken="a3f87088dcb994e1" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0"/>
      </dependentAssembly>

I'm guessing that a new build of ORMProfiler with the updated BCLExtensions assembly would fix that. Any chance of that happening?

Did you install the interceptor from nuget? If you install it from nuget the assembly redirects should be made automatically.

We never noticed this to be honest, as the usage of the profiler during 5.2 was done using the nuget version, and we never had a problem.

Also, if you use the interceptor dll from a local folder, it comes with bclextensions 1.0, or did you reference 1.1 in your own code?

Our configuration pattern is slightly different and that is probably causing our issue. We've been using LLBLGen and ORMProfiler long before they were available via NuGet. Our method of referencing the dll files has been through file references.

    <Reference Include="SD.Tools.OrmProfiler.Interceptor.NET45">
      <HintPath>..\Lib\LLBLGen\SD.Tools.OrmProfiler.Interceptor.NET45.dll</HintPath>
    </Reference>

That same folder (..\Lib\LLBLGen) has the dll files for both ORMProfiler and LLBLGen. In making the changes to v5.2, I updated the BCLExtensions dll in that folder.

I'll try using a NuGet reference to ORMProfiler instead and see what happens with that.

aaah then that's the cause Indeed if you build the driver of DB2 against 5.2, you indeed will reference 1.1.0.0 of BCL extensions, and that doesn't match with 1.0.0.0 of the interceptor. Normally one doesn't run into this as BCL extensions normally aren't present in the build output folder of someone's project, yet in your specific case it is.

Sorry for this problem, an assembly redirect will suffice:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="SD.Tools.BCLExtensions" publicKeyToken="a3f87088dcb994e1" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.1.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>