2

I created a chart C# library (let's call it chartlibrary) which itself has dependencies on multiple third-party dll files.

In another executable project (let's call it chartuser), I reference the chartlibrary project (both projects sit within the same solution in Visual Studio).

Upon compilation, I can see that all the third-party dll files that chartlibrary references are also contained in the bin/Debug folder of chartuser. However, I get a runtime error which basically points to the fact that some of the references in chartlibrary cannot be resolved. I then tried to get a better idea via 

AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

and

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        var assemblyFileName = args.Name.Substring(0, args.Name.IndexOf(",")) + ".dll";
        var assemblyPathFileName = _currentPluginPath + @"\" + assemblyFileName;

        if (File.Exists(assemblyPathFileName))
        {
            return Assembly.Load(File.ReadAllBytes(assemblyPathFileName));
        }

        return null;
    }

Problem is that the RequestingAssembly is null and Name is very cryptic.

What am I doing wrong that the reference dlls cannot be found and assemblies cannot be resolved even though all the dlls are in the bin/Debug folder of the executable project?

xmojmr
  • 8,073
  • 5
  • 31
  • 54
Matt
  • 7,004
  • 11
  • 71
  • 117
  • There should be no reason to handle the `AssemblyResolve` event if all dependencies are in the same folder. Could you include the exact error message you're getting? Sometimes the "...or one of its dependencies" one indicates that a 3rd party library itself has an additional dependency. Perhaps you could try creating a single test solution that uses these 3rd party libraries and see if it runs. – C.Evenhuis Sep 11 '19 at 11:17

1 Answers1

1

Fix: A fix for the third party library related to their obfuscation engine solved the issue.

.NET Dependencies: Maybe skim this old answer: How do I determine the dependencies of a .NET application? - and go through any manifest files?

Debugging: The Microsoft Assembly Binding Log Viewer can show you what's going on at runtime. Launch it via a Developer Command Prompt for Visual Studio (just search for "developer command", type in "FUSLOGVW.exe" and press Enter). Also maybe have a skim: How the Runtime Locates Assemblies.

I am not familiar with their use that much, but there are some further tools (most have further uses beyond dependencies):

Application Launch Check-List:

Runtimes: If the issue happens on another computer, the obvious runtimes that are first on the check-list: .Net, .Net Core, Java, Silverlight, Direct X, VC++ Runtime, MS-XML (legacy), Crystal Reports, Microsoft Report Viewer, SQL Server / Database Runtimes, etc... Plus anything involving COM-registration and obviously any third party framework components that you refer to (COM, COM Interop, GAC, Assemblies, etc...).

Other Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thanks, though I do know which dependency is required. The problem is that the dll file is in the bin/Debug folder and hence the dependencies were correctly copied into the output folder. However, somehow during the dependency resolution, the actual output folder does not seem to be searched for those dlls. – Matt Sep 11 '19 at 13:00
  • .NET is not my specialty, so apologies if this is irrelevant: Do you have anything in the GAC - (that can interfere)? Tried on a clean system? Bitness issues (x64, x86)? Did you diff the actual source file to see if it made it safely into the Debug folder? Any [publisher policy files](https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-create-a-publisher-policy) (for [assembly override](https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions))? And maybe diff the config files? – Stein Åsmul Sep 11 '19 at 13:05
  • Hard coded references? Not sure if that is likely or not - no practical experience. I'll throw in a link to my [minimally psychotic list of things to check for unexpected stuff in your release files](https://stackoverflow.com/questions/48311010/how-do-i-avoid-distributing-sensitive-information-in-my-msi-by-accident). – Stein Åsmul Sep 11 '19 at 13:13
  • Thanks, let me chew on your post and comments for a while, am also in contact with the developer of the third-party dependencies. – Matt Sep 11 '19 at 13:14
  • OK, please let us know what it was. Could be very common - or very curious and all the more reason to document. – Stein Åsmul Sep 13 '19 at 14:52
  • The developer (Scichart) of the third party library came back and hinted at the issue being related to their obfuscation engine. I can't verify that but they posted an update with a fix on their nuget feed and the problem went away. I am sorry that there are not more details obtainable surrounding the solution to this issue. – Matt Sep 15 '19 at 04:16
  • 1
    OK, thanks! Great to have that documented so people who see the same problem can find it. Should be good for the vendor too? It sounds like they came back quickly. Hope you are all sorted with that. Onwards as my old colleague used to say (adding: to the next problem :-) ). – Stein Åsmul Sep 15 '19 at 10:41