.NET Instrumentation - Call to Custom Assembly Fails - COR PROFILER

Question

I am trying to deploy my .NET Instrumentation profiler into Azure web apps. Using COR_PROFILER_32 and *_64 and COR_PROFILING_ENABLED i am enabling my profiler in Azure web app.

My profiler will instrument codes into all the modules including .NET Framework modules. (such as System.dll , System.Core.dll.. etc.) and even in user modules too. The instrumented code will call functions that are defined in a separate assembly "CAssemblyHelper.dll" which is "Any CPU" built.

The issue here is , when my instrumented code is getting called there is a "FileNotFoundException" happening with error message.

The blacked out is the assembly name CAssemblyHelper.dll that i am referring to. The assembly is not having any dependencies. I have probed the location of the dll in the web config file.

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;PrivateFolder"/>
    </assemblyBinding>
  </runtime>

How to resolve this error..! I am using DefineAssemblyRef in IMetaDataAssemblyEmit to define the assembly in the Modules. In the normal IIS server machine , the CAssembly helper will be installed in GAC, and everything was working perfectly. While trying in Azure the problem comes.!

Update 1:

I tried by giving code base to the web config file.. and still dint work

    <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;PrivateFolder"/>
      <dependentAssembly>
        <assemblyIdentity name="CAssemblyHelper"
                          publicKeyToken="XXXXXXX"
                          culture="neutral" />
        <codeBase version="1.0.0.0"
                  href="https://XXXX.scm.azurewebsites.net/api/vfs/SystemDrive/home/site/wwwroot/PrivateFolder/CAssemblyHelper.dll"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Additional Error:

Exception: System.IO.FileLoadException

Message: The specified user does not have a valid profile.

This exception and message comes when i am trying to instrument only System.Configuration.dll module.

Answer 1

According to your description, i recommend to do the follow troubleshoot:

Using KuDu to check if the CAssembly is in the right directory, for example, under bin. About how to use KuDu, we can refer to: Using KUDU with Microsoft Azure Web Apps

As a workaround, we can upload the CAssembly.dll to the Azure storage, then we can use codeBase node to specify the URL of this dll. For example:

<codeBase version="2.0.0.0" href="https://xxxxx.blob.core.windows.net/mycontainer/CAssembly.dll?sp=r&st=2018-07-25T06:12:18Z&se=2018-07-25T14:12:18Z&spr=https&sv=2017-11-09&sig=FUBDgfV9pxxxxxxyHqnbvz0E9r%2BhSnA%3D&sr=b"/>

How CLR loads a set of assemblies:

When the method is compiled, CLR determines which types and members it refers to, then looks up the AssemblyRef metadata reference table in the program set that is referenced, determines which assembly is referenced by the assembly, then checks the configuration file, and redirects the specified version number. That is the operation of dependentAssembly, assemlyIdentity and bindingRedirect elements.

At this point, CLR knows the version of the assembly that really needs to be loaded, and will be loaded to GAC (you can understand it as a shared folders in our respective computer). If the configuration file that performs the last redirection operation contains the codeBase, then the codeBase element is checked, CLR is loaded from the specified URL, otherwise it will be found in the root directory of the application, not found in the root directory, and found in the directory specified by the configuration file probing. CLR will first look for the DLL file, and CLR can not find the DLL file to change the suffix name to exe and then search it according to the rules.

If the bindingRedirect element is deleted from the configuration file, the application will recover.

Update:

If <assemblyIdentity> does not correspond to a strong name assembly, <codeBase> can only point to files in the application base directory. At this point, <codeBase> will be very restricted and very similar to the <probing> element.

If <assemblyIdentity> corresponds to a strongly named assembly, then <codeBase> can point to any URL (local file or network address can be).