1
votes

I have an Adobe acrobat plugin that uses System.Reflection.Assembly.LoadFile(path) in an AssemblyResolve event that will fail anytime I try to load a signed assembly. The error is

The assembly with display name 'Microsoft.AspNet.SignalR.Client' failed to load in the 'Load' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.AspNet.SignalR.Client, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))

I have to use AssemblyResolve event because the needed assemblies will live in a folder a couple levels beneath Acrobat's exe. Here is the code that AssebmlyResolve calls.

Assembly^ TeamMateIntegrationManagedWrapper::ResolveAssembly(Object^ sender, ResolveEventArgs^ args){
try
{
    // This method will be called if an assembly cannot be found.
    // The assembly should be 2 folders below the current working directory where the Adobe Acrobat executable lives.
    AppDomain^ appDomain = static_cast<AppDomain^>(sender);
    String^ path = appDomain->BaseDirectory;        

    path += "plug_ins\\MyAppName\\" + args->Name->Split(',')[0] + ".dll";

    return System::Reflection::Assembly::LoadFile(path);
}
catch (Exception^ ex)
{
    String^ msg = ex->Message;
}

return nullptr;}

The Acrobat plugin is in mostly C but has a CLI bridge class to wrap the managed C# Assembly that uses SignalR.

Things I've tried.

  • Put all the necessary dll's in the same folder as Acrobat's executable to get around using the AssemblyResolve event.
  • Verified the SignalR version and PublicKeyToken of the dll that I'm providing in the AssemblyResolve event matches exactly what is being requested in the ResolveEventArgs
  • Verified that all my assemblies (including plugin dll) are targeting .Net Framework v4.6 and the plugin dll is building for x86 and other assemblies are build for Any CPU.
  • Tried Assembly::LoadFrom(path) instead of LoadFile(path), same error loading assembly.
  • Rebuilt SignalR from the source code and removed the Strong Name, the SignalR assembly loaded successfully in the AssebmlyResolve event. Added the strong name back to the SignalR assembly and got the above error again.
  • Added Strong name to my C# assembly, got the same error as above just like SignalR assembly.
  • Looked at fusion log viewer but nothing was logged for Acrobat.
  • Created a C++ console application that contains the same CLI bridge wrapper class that uses the same C# assembly that consumes SignalR, same error as above. Looked at fusion logs but no log for Microsoft.AspNet.SignalR.dll under my ConsoleApplication.exe folder. Looked at fusino log for my C# assembly that uses SignalR and there is not any reference/mention of SignalR dll trying to load in the log file.
1
Don't just blindly offer to be able to load any missing assembly, first check if it actually exists in your plugin directory. And always use LoadFrom, never use LoadFile. And you'll have to get fuslogvw.exe going, be sure to start it from an elevated command prompt (Run as Administrator).Hans Passant
Thanks for the suggestions Hans. I added a File.Exists(path) check before trying Assembly.LoadFrom(path). I had Acrobat Reader and Acrobat Pro both installed on my dev machine. I decided to uninstall Reader and try to get it working with Pro. With Pro, the Strong name dll loads without problems, fusion logs are created, all is good. In the next day or so, I'll uninstall Pro and try working with only Reader installed. I'll add a comment when I get it straightened out. Thanks.Byron

1 Answers

1
votes

Adobe Reader has an option/preference Edit->Preferences->Security (Enhanced)->Enable Protected Mode at startup that launches the application in a protected sandbox. This protection was preventing the Strong named dll from being loaded.