Could not load file or assembly 'Xceed.Wpf.Toolkit

Question 1

So, I found a new and better solution to this question of mine from 2014.

Today I ran into the same problem where loading a WPF control from an assembly would throw an XamlParseException, except this time it was with a WPF control library assembly that I had created.

I tried moving the DLL into the same folder as the EXE, and as before this solved the problem.

After some searching, I found this question on the telerik.com forums: http://www.telerik.com/forums/xamlparseexception-could-not-load-file-or-assembly

It turns out if you simply give the control a name, by adding a x:Name attribute, this will add a reference to the control in the code-behind and for some reason resolves the issue with loading the assembly.

  <!--This causes a XamlParseException -->
  <mylib:MyCustomControl />

  <!-- This works -->
  <mylib:MyCustomControl x:Name="foobar"/>

Question 2

I am a fan of this approach. You can register an event on the AppDomain for the AssemblyResolve event, which catches when an assembly cannot be loaded.

It looks like this:

// using System.Reflection and System.IO

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args )
{
    if (args.Name.ToUpper().StartsWith("XCEED.WPF"))
    {
       string asmLocation = Assembly.GetExecutingAssembly().Location;

       string asmName = args.Name.Substring(0, args.Name.IndexOf(','));
       string filename = Path.Combine( asmLocation, asmName );

       if (File.Exists(filename)) return Assembly.LoadFrom(filename);
    }
}

You can make it a little more complete than this, but you get the idea...

Question 3

I know that this is a very old question but I happened to run across this exact error not too long ago. If your visual studio application uses two projects or a project that references another project, I would check to make sure that BOTH projects have the extended toolkit installed.

Right click on both your projects and click, "Manage NuGet Packages" and then browse on the left hand side of the dialogue to "Installed Packages". If you do not see extended toolkit on both projects then you can use the manager to search online and install them for you.

My issue was that I only had the extended toolkit installed on one project not both.

Hopefully this helps someone out in the future.

Question 4

Although this has probably been solved, a common reason is failure to add the Xceed.Wpf.Toolkit dll to your entry point project. You probably added it to one of your class libary projects and set its "Copy Local" attribute to true. A reference to this dll also has to be added to your main project which contains your App.xaml.cs with its "Copy Local" attribute set to true.

I am surprised Visual Studio 2013 does not handle this automatically.

Question 5

While I personally believe you should be doing it as stated in the accepted answer (by @Matt), I would like to mention that copying the dll to the "Program" folder in the Autodesk Revit installation would probably also do the trick. If I recall correctly, they also suggest you deploy your addins to a subfolder of this folder to ensure that it just works. I suspect, that is due to effects like the one you are having.

Question 6

In the System.Reflection namespace, there is the Assembly class. This can be used to load new assemblies into the current AppDomain.

Assembly.LoadFrom("FileLocation");

Although this is still annoying, I think this might be the only way to have it load a library not in the main directory.

Question 7

Make sure you "Unblock" the Xceed assembly. Right click on the file and select properties then "Unblock". The VS will compile the code without any errors but when you go to run, Windows will not load the assembly. Mine was even merged into a single assembly.

Question 8

I used Fody Costura to embedd the Xceed.Wpf.Toolkit.dll in the compiled .dll. Just install it using NuGet and type Install-CleanReferencesTarget into your Packet Manager Console and there you go.

Question 9

When the control is loaded from the XAML, the calling assembly from which your Xceed.Wpf.Toolkit.dll is loaded is PresentationFramework.dll. So the CLR will not look into your addin folder in this case (what it's doing when another class is loaded from the main assembly of your addin, because it looks into the folder of the calling assembly).

So you can as you've find, put a reference to the control in the code-behind or you can use the AppDomain.CurrentDomain.AssemblyResolve to force the CLR to look in your addin folder.

Putting the dll in the Revit installation folder works, but it's a bad practice in my point of view because it can be overwritten by another addin installation with consequences that are difficult to measure.

Question 10

I've seen people using this workarounds for Visual Studio Extensions. However VS provides a better solution, using the "ProvideCodeBaseAttribute":

https://learn.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.shell.providecodebaseattribute

Question 11

If you update from 4.3 to 4.4 and you are using .net6, then you get the next error:

Assembly 'Xceed.Wpf.Toolkit' was not found.

In this case you have to change the namespace to

xmlns:tk="clr-namespace:Xceed.Wpf.Toolkit;assembly=Xceed.Wpf.Toolkit.NET5"

https://github.com/xceedsoftware/wpftoolkit/issues/1722