Length Query and RevitLookup Heralds DLL Paradise

Exciting new RevitLookup release solves Revit add-in DLL hell, and a clarification on the arc length properties provided by curve elements:

Curve Length versus ApproximateLength

Last week, the Revit development team helped to provide a useful clarification of the difference between Length and ApproximateLength in Curve class:

Question: The Curve class provides two properties to get the length of a curve, Length and ApproximateLength. What is the difference?

Answer: For many types of curves, the results will probably be identical. Differences probably only occur for complex curves. For example, there is no closed-form expression for the arc length of an ellipse. One efficient and fruitful way to address this kind of question is to implement a little test suite with benchmarking and try it out for yourself.

The development team clarify:

Seems pretty well documented in the remarks for the ApproximateLength property to me. ApproximateLength is completely accurate for uniform curves (lines and arcs) but could be off by as much as 2x for non-uniform curves, and so it may be worth checking the curve’s class and deciding which method to call from there, or just using the Length property in all cases, if accuracy is a concern. I recommend the latter, as the time savings hasn’t shown to be significant in my work.

ApproximateLength uses a rough approximation that depends on the curve type. There's no guarantee that the approximation method will be unchanged in future releases.

Length performs a line integral to compute the curve length, which can be considered exact for all practical purposes. Lines and arcs have closed-form expressions for their lengths that are used instead. I agree that a user is unlikely to see a noticeable performance difference between the two methods. The performance differences are mostly relevant for internal usage, e.g., in graphics functionality.

Arc length

RevitLookup Dependency Isolation Ends DLL Hell

The new RevitLookup release 2025.0.8 runs in an isolated container for addin dependencies.

This new capability prevents conflicts and compatibility issues arising from different library versions between plugins, ensuring a more stable and reliable environment for plugin execution.

This enhancement uses the Nice3point.Revit.Toolkit to manage the isolation process, effectively eliminating DLL conflicts. By integrating this package, RevitLookup ensures a consistent and predictable user experience.

The detailed description how it works is provided in the release notes for RevitToolkit release 2025.0.1, also reproduced below.

The dependency isolation is available starting with Revit 2025. Note that the isolation mechanism is implemented by an additional library that must be loaded into Revit at first startup for it to work. Therefore, if your other plugins use Nice3point.Revit.Toolkit, it must be updated to version 2025.0.1, which introduces this feature.

RevitLookup 2025.0.8 addresses the following issues:

As further improvements, the following type extensions are added for the Part class, associated classes #255 and WorksharingUtils #257:

Part:

PartMaker: - GetPartMakerMethodToDivideVolumeFW: Obtains the object allowing access to the divided volume properties of the PartMaker

Element: - GetCheckoutStatus: Gets the ownership status of an element - GetWorksharingTooltipInfo: Gets worksharing information about an element to display in an in-canvas tooltip - GetModelUpdatesStatus: Gets the status of a single element in the central model - AreElementsValidForCreateParts: Identifies if the given elements can be used to create parts

Add-In Dependencies Isolation

The RevitLookup isolated plugin dependency container is built using .NET AssemblyLoadContext.

This feature enables plugins to run in a separate, isolated context, ensuring independent execution and preventing conflicts from incompatible library versions.

This enhancement is available for Revit 2025 and higher, addressing the limitations of Revit's traditional plugin loading mechanism, which loads plugins by path without native support for isolation.

How it works:

The core functionality centres on AssemblyLoadContext, which creates an isolated container for each plugin.

When a plugin is loaded, it is assigned a unique AssemblyLoadContext instance, encapsulating the plugin and its dependencies to prevent interference with other plugins or the main application.

To use this isolation feature, developers must inherit their classes from:

These classes contain the built-in isolation mechanism under the hood. Plugins using interfaces such as IExternalCommand will not benefit from this isolation and will run in the default context.

Limitations:

For further details, please refer to the discussion between ricaun and Nice3point on build automation version breaking Revit 2025 #246

They recommend that Autodesk and Revit adopt similar functionality and include it in the basic Revit API add-in handling architecture, so that all add-in dependencies are automatically isolated and DLL hell conflicts never occur.

ricaun recorded a nine-minute video on RevitLookup - End of DLL hell - Revit API explaining and demonstrating exactly how RevitLookup for Revit 2025 can herald the end of DLL hell:

Many thanks to both of you for your thorough implementation, testing, discussion and documentation!