ILMerge CSLA to avoid version conflicts for plug-in apps?

[michaelcsikos]

We develop plug-ins for AutoCAD and Revit. If two or more plug-ins use CSLA (i.e. if CSLA is used by other plug-in developers), only the first Csla.dll will be loaded as .NET can't load two versions of the same DLL, potentially causing a version conflict. Could ILMerge be used to avoid this problem?

[rockfordlhotka]

I have no idea. When this sort of thing comes up I always turn to @JasonBock because he knows way more about this sort of thing than I do!!

[JasonBock]

I also have no idea :). I know of ILMerge, but I've never used it in practice. But....this would be a problem with any 3rd party library, correct? Meaning if you reference 3.2.0 of AwesomePackage in one plug-in, and 3.3.0 of that package in another add-in, same issue, right? And even if you could merge both into ILMerge, how would that solve the problem? You still have two add-ins trying to reference two different versions of a dependency.

[michaelcsikos]

I think with ILMerge AwesomePackage 3.2.0 could be merged into SuperPlugIn and then AwesomePackage 3.3.0 could be merged into WidgetPlugIn. When SuperPlugIn and WidgetPlugIn get loaded into Revit or AutoCAD, AwesomePackage doesn't really exist as it has been internalised by each plug-in.

[JasonBock]

I was curious, so I did a quick search and I found this, but it's unclear if this addresses your scenario.

[JasonBock]

One last thing....the ILMerge project is now archived, so no new work is being done here. Even if you get this to solve your problem, you're now tied to a solution that has no future. Furthermore, it's Windows-only, meaning it only targets .NET Framework, and that is also essentially "archived" in that no new feature work is being done with .NET Framework. If you're doing .NET Core/5 and beyond, this doesn't seem like it will help.

[michaelcsikos]

All good points. The versions of .NET we target are dictated by Autodesk for each version of AutoCAD and Revit. Eventually we will have to target .NET 5, so this would not be a future-proof solution.

[rockfordlhotka]

Thinking about this, and given what Jason said regarding ilmerge being archived, you might want to think more about the architecture you want to use for add-ins.

Platforms like SharePoint have moved away from hosting add-ins in-proc to the idea of hosting them as a separate service. That allows each add-in to run in its own context/environment, reducing the chance of add-ins conflicting with each other, or crashing the host.

Maybe something like that is a model you should consider? Run each add-in in its own process, so it is isolated from other add-ins and the host, avoiding any conflicts like with specific versions of csla, dotnet, etc.

[michaelcsikos]

Forking a new process from our add-in was something I discussed with the boss yesterday. The main plug-in DLL would still need to be loaded in AutoCAD or Revit and interact with the drawings, but much of the the business layer and UI could be in a separate process. The plug-in could do its work with POCO DTOs. There would still be some hurdles, as some forms need to allow the user to select objects from the drawing.