Unable to load Syncfusion SfSpreadsheet control on Revit 2025

[gopinath.rajendran]

I'm attempting to utilize the SfSpreadsheet control for data editing. However, I encountered an exception that I traced back to the TabControlExt, which seems to be the source of the issue. I'm currently investigating the problem, but it occurs only when loading the plugin in Revit 2025. In other versions of Revit and regular desktop applications, it functions without any problems.

Getting below exception:

[jeremy_tammik]

Probably a DLL conflict. If your add-in uses a DLL that is also used by Revit, Revit will mostly have loaded it first. Revit loads the specific version that it needs. If your add-in needs a different version, it will not be able to load it. Maybe Revit 2025 now loads one DLL that you need, but the wrong version, whereas previous versions of Revit did not load it, so you were free to do what you want. One possible next step is to research what DLL is causing the problem, which exact version  is loaded by Revit, and whether or not you can use the same version in your add-in. Many similar issues have been discussed here in the forum in the past and resolved in various ways. 

[gopinath.rajendran]

@jeremy_tammikThank you for the quick reply. Apart from the sample I shared in the previous post, I haven't installed any other plugin for Revit 2025. I've checked for Syncfusion.Tools.WPF in the Revit 2025 installation, but I couldn't find any.

[jeremy_tammik]

Aha. Well, then I do not know what is going on. Of course, what I described for your add-in may apply to other assemblies that your add-in refers to as well, recursively. So, maybe Syncfusion is tied to a specific version of a low-level DLL, and Revit is now loading a different one first, preventing Syncfusion from doing its thing. The error message looks like it is caused by a constructor.

[gopinath.rajendran]

Is it possible to determine whether the issue can be resolved on the Revit side, or if I should reach out to Syncfusion for assistance? One of our DiRoots plugin functionalities relies on this control, and we have another plugin in development that will also utilize the same control.

As Syncfusion may not be able to directly replicate the issue, I'll need to provide more information to help them diagnose and resolve it

[jeremy_tammik]

Sorry, I cannot really say much more. As said, many aspects and solutions have been discussed here in the forum in thr past. I highlighted a few of them in The Building Coder as well:

• Handling Third Party Library DLL Conflicts
• Set Floor Level and Use IPC for Disentanglement
• RevitLookup Update, Fuslogvw and Override Joins
• Export, gbXML and Python Tips
• DLL Paradise and a Fall

[marco.giacomelliZSW69]

Check the journal log at %localappdata%\Autodesk\Revit\Autodesk Revit 2025\Journals

and look for "Assembly version conflict in some references in", usually the assembly load conflicts get logged there and from there you can go further in finding out which library is causing the issue

[nice3point]

Find out what dependencies Syncfusion uses and check if they are loaded in Revit using RevitLookup:
https://github.com/jeremytammik/RevitLookup

Also the problem could be in dependency resolution and the plugin doesn't understand which dlls to load, this is a common problem in WPF, but I have a solution that works 100% of the time (excluding version conflict).

Try using ExternalCommand from this Nuget package, instead of IExternalCommand:

https://github.com/Nice3point/RevitToolkit?tab=readme-ov-file#external-command

ExternalCommand has a dependency resolver that solves all dll loading problems

[TripleM-Dev.net]

Hi @gopinath.rajendran,

Is the control .NET Core (xx version) compatible?

A quick search turned up depending the version of the SyncFusion version which support .NET 8:

https://help.syncfusion.com/wpf/dotnet-core-compatibility 

Is the correct NuGet linked / or ref. assemblies?

Have you tried using the controls (or app UI) in a standalone app and see it that works in a .NET 8 project?

- Michel