AlibreX.dll, Working .NET 7 upgrade and using Alibre Design with modern tech and tooling

[stepalibre]

I only use Alibre Design for the API. I think this is important in understanding my perspective and use case. Sorry for the long post but I tried to cover everything important and be clear.

I'm working on integrations and workflows with Dynamo (Open Source Graphical Programming for Design), Grasshopper (graphical algorithm editor included with Rhino), Godot and Unity engine.

Here are some more contexts:

VS Code
Any Python 3 software or library
Jupyter notebooks
AI/LLM tech is all bleeding edge and I've been researching it seriously this year with some tools made and many ideas.
Blender for rendering, animation and is Python 3, FreeCAD is Python 3.
Web Tech, 3D viewers, configurators.

The problem:

AlibreX.dll = .NET framework 4.8 and .NET 6 or 7 is what all the .NET based 3D libraries and game engines use, Dynamo is preparing for .NET 6 and Rhino 8 will have .NET 7 support.

Dynamo upgrading to .NET 6 - Dynamo BIM

Kia ora everyone, We are actively working on upgrading Dynamo from .NET 4.8, which we have been on for a long, long time, to .NET 6.0. This post is the precursor to a larger technical post coming after the work has been done giving package authors in particular a head’s up that changes are...

dynamobim.org

Moving to .NET 7

This guide walks you through making the transition to .NET 7

developer.rhino3d.com

I spent the past few months exploring AlibreX.dll in detail. Being a single library is great and easy to navigate.

Why is .NET 6/7/8 so important, what are some benefits, why should I care?

The latest .NET versions allow us to work with Python 3 more easily, JavaScript via WebAssembly, among other features and it is cross platform. This is more important for development and tooling. I'm not trying to sell it to you but rather point out some other benefits.

The solution I have working:

.NET 7 build of AlibreX.dll. This solves the issues noted above and is a drop-in replacement for AlibreX.dll. Its not fully tested.

Other key pieces include:

Code to make it easier to program COM based libraries like AlibreX. COM is tricky and there are differences in how .NET Core handles COM. Many issues are COM related and not necessarily your code.

.NET 7 and .NET 4.8 bridge techniques a fallback to use .NET 4.8 code or project in .NET 7 contexts.

Issues and what is not working:

I spent most of the time on foundational work not able to work much on the integration pieces. I needed to pull apart the API and try things out to understand what is even possible and then how is .NET 4.8 and .NET 7 different. When I find issues in AlibreX.dll or the documentation I take notes and move on, building demos and tests all along the way. The process is slow.

What if Alibre update AlibreX.dll?

My process can be applied to newer versions of AlibreX.dll It shouldn't matter at all.

What if Alibre update AlibreX.dll to .NET 7 in v28?

Great everything should still work as is, I'll just change the target files.

Why integrate or use a program like Alibre Design a feature based, parametric modeler with Dynamo or Grasshopper?

The goal is to use them for their strengths combining one powerful tool with another powerful tool.

What's next?

I will be updating all my projects on GitHub and making more of the work public. I have cleanup, rethinking and reorganizational work to do first.

Any Dynamo or Rhino/Grasshopper users?
Special thanks to @bolsover and @NateLiqGrav

This is all for free, if anyone is thinking what's the catch. This is personal work. Much more to do but I'd like to share progress even this early. If you want more details, see examples or something sooner than later please let me know.

 

[stepalibre]

Alibre Design + VS Code + Notebooks .NET 7 demo

Alibre Design + VS Code + Notebooks Demos | Notion

Alibre Design + VS Code + Notebooks demo 2

testbed-for-alibre-design.notion.site

 

[stepalibre]

 

[stepalibre]

As I understand it AlibreX.dll is only interfaces so I believe this makes upgrading to .NET 7 a simpler process. It still needs to be thoroughly tested before It should be labeled as stable.

Simply because the code compiles for .NET 7 does not guarantee absence of issues or edge cases.

 

[stepalibre]

For Addons that are loaded inside of Alibre you would still need that version of AlibreX.dll to be .NET 4.8 and if you load your own dlls into AlibreScript like in the console as I do. Any dlls that run inside of Alibre will need to be .NET 4.8 or whatever version Alibre require.

But the .NET 7 version of AlibreX.dll can be used during development e.g. inside VS Code, Godot engine and in other .NET 7 programs and scripts running outside of Alibre.

 

[bolsover]

+1 for .NET 7.
I know I've only done limited work with Add-ons but being able to move on to .NET 7 would be a real benefit.

I guess the real benefit of .NET 7 for Alibre would be potential cross platform support - got to be a good thing.

David

 

[stepalibre]

Deploy target = .NET 4.8 to Alibre
Development targets = .NET4.8, .NET Standard 2.0, 2.1 and so far I only I'm testing .NET 7 for Godot engine but in theory 6 and 8 should work.

I blame Microsoft for my headache trying to sort out their versioning and branding.

 

[stepalibre]

+1 for .NET 7.
I know I've only done limited work with Add-ons but being able to move on to .NET 7 would be a real benefit.

I guess the real benefit of .NET 7 for Alibre would be potential cross platform support - got to be a good thing.

David

A change like this is forward looking. I think the benefits can be huge.

 

[stepalibre]

Compile and work as is:
<TargetFrameworkVersion>v4.8.1</TargetFrameworkVersion>
<TargetFramework>netstandard2.0</TargetFramework>
<TargetFramework>netstandard2.1</TargetFramework>
<TargetFramework>net6.0</TargetFramework>
<TargetFramework>net7.0</TargetFramework>
<TargetFramework>net8.0</TargetFramework>

 

[DavidJ]

Is this really for the General Discussion area or should it be in Add-on Development ?

I personally don't see what this thread is actually for, so I can't realistically make a decision about moving it. Perhaps someone who does understand can advise?

 

[bolsover]

Is this really for the General Discussion area or should it be in Add-on Development ?

I personally don't see what this thread is actually for, so I can't realistically make a decision about moving it. Perhaps someone who does understand can advise?

Hi @DavidJ
I'm sure that @stepalibre will offer his view but yes, for me this is very relevant to Add-on development. Having said that, it is also generally relevant to the future direction of the Alibre product.
.NET 4.8 framework (what the majority of Alibre .dll files are compiled against is a Microsoft proprietary product that runs only on Microsoft windows platform.
.NET 6,7 (8 will be released soon) are open source and available for Windows, Linux and MacOs.
Recompiling the ALL the Alibre source code to also target these later versions is almost certainly possible but not without a reasonable effort.
Recompiling JUST AlibreX.dll to also target later versions is probably quite straightforward.

There are a couple of advantages (just my view) of moving the code base to the later versions:
1 It allows developers to use the up to date versions of C#. With .NET 4.8 framework, you are really stuck with C# 8. .NET 7 allows developers to use C# 11.
2 Migrating ALL of Alibre to .NET 6+ opens the way for cross platform development (Alibre on Linux, Windows and MacOs)

Moving to .NET 6+ is however not risk free. Because .NET 4.8 framework is essentially an integral part of Win 10, 11 it is almost certain to be supported for many years to come - I don't know the official end of life date but probably around 2031. .NET 6 is a Long Term Service (LTS) release but the official support period ends November 2024. .NET 7 is a Standard Term Service product with support ending May 2024. Even numbered releases (one release each year in November) are LTS products - so .NET 8 which will be released in November 2023 will get support to November 2026.

HTH.
David

 

[stepalibre]

Is this really for the General Discussion area or should it be in Add-on Development ?

I personally don't see what this thread is actually for, so I can't realistically make a decision about moving it. Perhaps someone who does understand can advise?

You can move it.

 

[stepalibre]

Hi @DavidJ
I'm sure that @stepalibre will offer his view but yes, for me this is very relevant to Add-on development. Having said that, it is also generally relevant to the future direction of the Alibre product.
.NET 4.8 framework (what the majority of Alibre .dll files are compiled against is a Microsoft proprietary product that runs only on Microsoft windows platform.
.NET 6,7 (8 will be released soon) are open source and available for Windows, Linux and MacOs.
Recompiling the ALL the Alibre source code to also target these later versions is almost certainly possible but not without a reasonable effort.
Recompiling JUST AlibreX.dll to also target later versions is probably quite straightforward.

There are a couple of advantages (just my view) of moving the code base to the later versions:
1 It allows developers to use the up to date versions of C#. With .NET 4.8 framework, you are really stuck with C# 8. .NET 7 allows developers to use C# 11.
2 Migrating ALL of Alibre to .NET 6+ opens the way for cross platform development (Alibre on Linux, Windows and MacOs)

Moving to .NET 6+ is however not risk free. Because .NET 4.8 framework is essentially an integral part of Win 10, 11 it is almost certain to be supported for many years to come - I don't know the official end of life date but probably around 2031. .NET 6 is a Long Term Service (LTS) release but the official support period ends November 2024. .NET 7 is a Standard Term Service product with support ending May 2024. Even numbered releases (one release each year in November) are LTS products - so .NET 8 which will be released in November 2023 will get support to November 2026.

HTH.
David

AlibreX is compiling and all my tests work from 6 to 8 preview. The only issue is COM is handled differently starting in .NET Core you need this.

public static object GetActiveObject(string progId, bool throwOnError = false)
    {
        if (progId == null)
            throw new ArgumentNullException(nameof(progId));
        var hr = CLSIDFromProgIDEx(progId, out var clsid);
        if (hr < 0)
        {
            if (throwOnError)
                Marshal.ThrowExceptionForHR(hr);
            return null;
        }
        hr = GetActiveObject(clsid, IntPtr.Zero, out var obj);
        if (hr < 0)
        {
            if (throwOnError)
                Marshal.ThrowExceptionForHR(hr);
            return null;
        }
        return obj;
    }
    [DllImport("ole32")]
    private static extern int CLSIDFromProgIDEx([MarshalAs(UnmanagedType.LPWStr)] string lpszProgID, out Guid lpclsid);

    [DllImport("oleaut32")]
    private static extern int GetActiveObject([MarshalAs(UnmanagedType.LPStruct)] Guid rclsid, IntPtr pvReserved, [MarshalAs(UnmanagedType.IUnknown)] out object ppunk);
}

 

[stepalibre]

Hi @DavidJ
I'm sure that @stepalibre will offer his view but yes, for me this is very relevant to Add-on development. Having said that, it is also generally relevant to the future direction of the Alibre product.
.NET 4.8 framework (what the majority of Alibre .dll files are compiled against is a Microsoft proprietary product that runs only on Microsoft windows platform.
.NET 6,7 (8 will be released soon) are open source and available for Windows, Linux and MacOs.
Recompiling the ALL the Alibre source code to also target these later versions is almost certainly possible but not without a reasonable effort.
Recompiling JUST AlibreX.dll to also target later versions is probably quite straightforward.

There are a couple of advantages (just my view) of moving the code base to the later versions:
1 It allows developers to use the up to date versions of C#. With .NET 4.8 framework, you are really stuck with C# 8. .NET 7 allows developers to use C# 11.
2 Migrating ALL of Alibre to .NET 6+ opens the way for cross platform development (Alibre on Linux, Windows and MacOs)

Moving to .NET 6+ is however not risk free. Because .NET 4.8 framework is essentially an integral part of Win 10, 11 it is almost certain to be supported for many years to come - I don't know the official end of life date but probably around 2031. .NET 6 is a Long Term Service (LTS) release but the official support period ends November 2024. .NET 7 is a Standard Term Service product with support ending May 2024. Even numbered releases (one release each year in November) are LTS products - so .NET 8 which will be released in November 2023 will get support to November 2026.

HTH.
David

I agree with all you points. I suspect the decision to upgrade would include partner addons which is more likely the driving force for addon development.

 

[stepalibre]

Planning (WIP) • Testbed-for-Alibre-Design

Planning (WIP)

github.com