Marshal.GetActiveObject Replacement in .NET 8+: Connecting to Running Autodesk Inventor Instances

<?xml encoding=”UTF-8″>by Chandra shekar Gopal,

As Autodesk Inventor continues evolving, developers targeting automation through its COM API face new challenges. One key issue is the deprecation of System.Runtime.InteropServices.Marshal.GetActiveObject in .NET Core and its obsolescence starting with Inventor 2025, which now supports .NET 8. This blog post focuses specifically on how to work with running Inventor instances in modern .NET environments using a reliable P/Invoke workaround.

⚠️ Note: Marshal.GetActiveObject was fully supported in Inventor 2024 and previous releases. However, Inventor 2025 officially supports .NET 8, making this method obsolete and unsupported. Developers must adopt alternative approaches for interacting with live Inventor sessions.

What Was Marshal.GetActiveObject in Inventor Automation?

In .NET Framework, Marshal.GetActiveObject("Inventor.Application") enabled developers to connect to a running instance of Autodesk Inventor. This capability was crucial for add-ins, scripts, or standalone tools automating tasks via Inventor’s COM API.

Unfortunately, .NET Core and .NET 5/6+ do not support this method. To continue developing automation tools with modern .NET runtimes, an alternative method is needed.

The Solution: Using P/Invoke to Access Inventor’s COM Object

Platform Invocation Services (P/Invoke) allow managed .NET code to call native Windows API functions. By importing COM interop functions directly, we can replicate the behavior of Marshal.GetActiveObject and connect to Inventor instances.

Sample Implementation

Here is a practical C# workaround that allows you to retrieve the active Inventor session in .NET Core or .NET 5/6/8:

using System;
using System.Runtime.InteropServices;
using System.Security;
namespace InventorInterop
{
internal static class NativeMethods
{
private const string OLEAUT32 = "oleaut32.dll";
private const string OLE32 = "ole32.dll";
[DllImport(OLE32, PreserveSig = false)]
[SuppressUnmanagedCodeSecurity]
public static extern void CLSIDFromProgIDEx([MarshalAs(UnmanagedType.LPWStr)] string progId, out Guid clsid);
[DllImport(OLE32, PreserveSig = false)]
[SuppressUnmanagedCodeSecurity]
public static extern void CLSIDFromProgID([MarshalAs(UnmanagedType.LPWStr)] string progId, out Guid clsid);
[DllImport(OLEAUT32, PreserveSig = false)]
[SuppressUnmanagedCodeSecurity]
public static extern void GetActiveObject(ref Guid rclsid, IntPtr reserved, [MarshalAs(UnmanagedType.Interface)] out object ppunk);
}
internal class InventorConnector
{
public static object GetInventorInstance()
{
Guid clsid;
string progId = "Inventor.Application";
try
{
NativeMethods.CLSIDFromProgIDEx(progId, out clsid);
}
catch
{
NativeMethods.CLSIDFromProgID(progId, out clsid);
}
NativeMethods.GetActiveObject(ref clsid, IntPtr.Zero, out var obj);
return obj;
}
}
}

Code Breakdown

NativeMethods Class:

• Wraps required COM interop functions.
• Includes methods for converting a ProgID to CLSID and accessing the Running Object Table (ROT).

InventorConnector Class:

• Contains GetInventorInstance, a utility method specifically tailored to connect to Inventor.
• Falls back to CLSIDFromProgID if CLSIDFromProgIDEx is unavailable.

Why This Matters for Inventor Developers

This workaround allows .NET Core and .NET 8+ developers to continue building powerful Inventor automation tools:

• Ensures compatibility with Inventor 2025 and future releases.
• Unlocks modern .NET features while maintaining access to the Inventor COM API.
• Offers a robust template for other Autodesk automation scenarios.

Conclusion

With Inventor 2025 moving forward on .NET 8, legacy features like Marshal.GetActiveObject are no longer viable. Fortunately, by using P/Invoke to access native COM APIs, you can still attach to running Inventor instances and build effective automation workflows.

This method provides a future-proof way to maintain your productivity tools while aligning with Autodesk’s platform evolution.