topic Re: NuGet Package DLL Loading Issue in .NET Forum

NuGet Package DLL Loading Issue

jeremyperna7254 — Tue, 01 Oct 2024 20:47:41 GMT

In a test project I am working on I am trying to use the FontAwesome.WPF NuGet package for icons to be displayed on a palette control. Here is the current solution structure

Solution

- Core.csproj (references UI.csproj for views)

- UI.csproj (the project that references the FontAwesome.WPF package)

In the WPF UserControl that needs the icons I have added the namespace declaration and usage of the icons like this

xmlns:fa="http://schemas.fontawesome.io/icons/" ... <fa:ImageAwesome Icon="Plus" Width="16" Height="16" Margin="0 0 5 0"/> <TextBlock Text="Connect To Existing Project" />

Everything in the XAML designer renders fine. However, when I NETLOAD my plugin from bin/Debug/Core.dll and then trigger the command that shows my palette with the icons I get the following error at the InitializeComponent method in the code-behind my user control

System.Windows.Markup.XamlParseException HResult=0x80131501 Message=Could not load file or assembly 'FontAwesome.WPF, PublicKeyToken=0758b07a11a4f466' or one of its dependencies. The system cannot find the file specified. Source=PresentationFramework StackTrace: at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri) at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri) at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri) at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream) at UI.View.ProjectTabView.InitializeComponent() in C:\Users\jerem\source\repos\PluginUIDemo\UI\View\ProjectTabView.xaml:line 1 This exception was originally thrown at this call stack: [External Code] Inner Exception 1: FileNotFoundException: Could not load file or assembly 'FontAwesome.WPF, PublicKeyToken=0758b07a11a4f466' or one of its dependencies. The system cannot find the file specified.

Now the part where I get really confused is that I have confirmed that the FontAwesome.WPF.dll is present in my output directory (bin/Debug/FontAwesome.WPF.dll). I also am referencing a MVVM NuGet package in UI.csproj in the same way and that works just fine (however the difference is this isn't being loaded during initialization of a user control).

Interestingly, I can fix this error by manually copying the FontAwesome.WPF.dll into the C:\Program Files\Autodesk\AutoCAD 2024 directory, which confirms that is where ACAD is looking for this package. What I don't understand is why ACAD is looking for this package in the program files directory (C:\Program Files\Autodesk\AutoCAD 2024) and not in the bin/Debug output directory where I indicated that my plugin dll is and all the other dlls that mine depends on are located. Is there something different about loading assemblies for user controls?

Re: NuGet Package DLL Loading Issue

ActivistInvestor — Tue, 01 Oct 2024 22:58:17 GMT

In many scenarios I've had to deal with, involving multiple managed extension apps that were all dependent on a common set of libraries, I use something like the following (which is vastly-simplified from the actual working code, which searches through the Applications subkey of the registry to find dependent assemblies).

This overly-simplified example should find and load a dependent .dll having the same location as the .dll containing the IExtensionApplication.

public class MyApplication : IExtensionApplication { string myLocation; public void Initialize() { string path = typeof(MyApplication).Assembly.Location; myLocation = Path.GetDirectoryName(path); AssemblyLoadContext.Default.Resolving += OnResolve; } Assembly OnResolve(AssemblyLoadContext context, AssemblyName name) { string path = Path.Combine(myLocation, $"{name.Name}.dll"); if(File.Exists(path)) { return context.LoadFromAssemblyPath(path); } return null; } public void Terminate() { } }

Re: NuGet Package DLL Loading Issue

jeremyperna7254 — Wed, 02 Oct 2024 01:45:40 GMT

I took your idea of adding an event handler to the assembly resolution failure event and got it working with this code. Thank you so much for the response!

public class Program : IExtensionApplication { private string _rootDirectory; public void Initialize() { string path = typeof(Program).Assembly.Location; _rootDirectory = Path.GetDirectoryName(path); AppDomain.CurrentDomain.AssemblyResolve += OnResolve; } private Assembly OnResolve(object sender, ResolveEventArgs args) { AssemblyName assemblyName = new AssemblyName(args.Name); string path = Path.Combine(_rootDirectory, $"{assemblyName.Name}.dll"); if (File.Exists(path)) { return Assembly.LoadFile(path); } return null; } public void Terminate() { } }

Re: NuGet Package DLL Loading Issue

kerry_w_brown — Wed, 02 Oct 2024 04:57:12 GMT

@ jeremyperna7254 and others

It's great that you were able to use the solution provided to solve your issue.

To my way of thinking you should be applying the solved credit to the poster of the solution, not to yourself.
What you have done is essentially stealing credit for someone elses knowledge and effort.

This is a peer to peer support group; unpaid and usually unthanked and uncredited.

If users continue to not thank or credit the people who take the time to decipher questions and attempt to resolve issues, these users shouldn't be surprised if, before long, thay are ignored.

Regards

Re: NuGet Package DLL Loading Issue

ActivistInvestor — Wed, 02 Oct 2024 08:56:38 GMT

@jeremyperna7254 wrote:
I took your idea of adding an event handler to the assembly resolution failure event and got it working with this code.

IOW, you took the code I posted and just renamed a few identifiers/variables?

Good Job!

Re: NuGet Package DLL Loading Issue

jeremyperna7254 — Wed, 02 Oct 2024 13:01:18 GMT

Oh my goodness! I am so sorry! That was a complete misclick. Of course the credit should go to @ActivistInvestor. I just wanted to post the exact code that worked for me but I didn't intend to mark my reply as the accepated solution. I have marked @ActivistInvestor's reply as the accepted solution now. Thank you for pointing out the mistake and so sorry for the mess up. I really, really appreciate how engaged this forum is and all the helpful users. I definitely want to give credit for all the help you all provide.

Re: NuGet Package DLL Loading Issue

soonhui — Wed, 04 Feb 2026 06:32:15 GMT

@ActivistInvestor , I'm not sure how your solution actually works in a robust way. I thought AssemblyLoadContext.Default.Resolving will not not safely isolate dependencies per plugin, due to the fact that it is global across the host application. The first one that wins pollutes the process, and the other can break, isn't that the case?

However, it just works on my testing thus far!! Anything that I miss?

Re: NuGet Package DLL Loading Issue

ActivistInvestor — Wed, 04 Feb 2026 09:36:02 GMT

If there are multiple handlers for the event, they are called in the order that they were added to the event, and the first one that returns an Assembly 'wins', and any remaining handlers do not get called.

Re: NuGet Package DLL Loading Issue

soonhui — Wed, 04 Feb 2026 10:01:07 GMT

@ActivistInvestor , but isn't that dangerous ( and not robust in solving the problem)? Because the winner will take over the rest and then we might have the original problem. And given that it's all indeterministic on how they are called, the problem may or may not be manifested