Netload in 2025

[dirvine_behlen_ca]

I have a plugin that is targeting net8.0 and am trying to use the same registry entries that worked for the framework version and it is not loading correctly. 

[HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\AutoCAD\R25.0\ACAD-8126:409\Applications\FriendlyTools]
"Description"="Friendly Tools for Friends"
"LOADCTRLS"=dword:00000002
"MANAGED"=dword:00000001
"LOADER"="C:\\Program Files\\Autodesk\\AutoCAD 2025\\Plugins\\FriendlyTools\\FriendlyTools.dll"

These settings work if I target framework 4.8. But, in my migrated app which targets net8.0, I seem to only be able to run it if I manually netload. I have tried most or all of these: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-autoload-DL.... 

Success with framework 4.8. With net8.0, it works only with a manual netload. I tried changing the managed value to 2 (on a whim) and no bueno. Not sure if there is a setting of Managed, or LOADCTRLS that will work better. I had the impression that net8.0 was the way to go for ACAD 2025, but not managing the autoload well here.

Edit:

I have found that I have to not have any autoload options done during a session of AutoCAD and then run netload manually for it to work with the net8.0 solution. It appears that if I have an autoload option attempted and then do interactive netload that even netload doesn't work. I have to shut ACAD down, remove the autoload option I tried and start ACAD again, then netload interactively as my first and only option for loading the application.

[ActivistInvestor]

The problem is most likely that your assembly is being loaded and an exception is occurring in the code that executes when the assembly is loaded. If your assembly contains an IExtensionApplication,  the exception is most likely occurring in the Initialize() method, or in code that's called from it. 

The reason that you might not get an exception when you use the NETLOAD command is because it runs in a different execution context then the one that loads your extension at startup (NETLOAD runs in the document context, while the auto-loader runs in the application context).

To ensure that your startup code always runs in the application context, you can use an Idle event handler to execute the initialization code. When you do that, your initialization code always runs in the same execution context, regardless of how your extension is loaded. You should also enclose all startup code in in a try{} block, followed by a catch{} block that catches any exception that's thrown and displays a message on the command line along with the exception stack Trace.

Here is a basic example IExtensionApplication that does what I describe above:

public class MyApplication : IExtensionApplication
{
   /// Do not initialize your app in this method:

   public void Initialize()
   {
      Application.Idle += OnIdle;
   }

   private void OnIdle(object sender, EventArgs e)
   {
      Document doc = Application.DocumentManager.MdiActiveDocument;
      if(doc != null)
      {
         Application.Idle -= OnIdle;
         try
         {
            /// TODO: Initialize your app here <-----
         }
         catch(System.Exception ex)
         {
            doc.Editor.WriteMessage($"\nError: {ex.ToString()}\n");
         }
      }
   }

   public void Terminate()
   {
   }
}

[dirvine_behlen_ca]

I appreciate the suggestion and I tried it out.

My initialization was like this:

Public Sub Initialize() Implements IExtensionApplication.Initialize
    ' if there was some load time initialization required to avoid repeated time costs during the execution
    ' of some of the commands, we can do that here; we can also set event handlers

    AddHandler Application.DocumentManager.DocumentActivated, AddressOf Tasker_DocumentActivated
End Sub

So, I have tried this:

    Public Sub Initialize() Implements IExtensionApplication.Initialize
        ' if there was some load time initialization required to avoid repeated time costs during the execution
        ' of some of the commands, we can do that here; we can also set event handlers

        AddHandler Application.Idle, AddressOf Idle

    End Sub

    Private Sub Idle(sender As Object, e As EventArgs)
        Dim doc = Application.DocumentManager.MdiActiveDocument
        If doc IsNot Nothing Then
            RemoveHandler Application.Idle, AddressOf Idle
            Try
                AddHandler Application.DocumentManager.DocumentActivated, AddressOf Tasker_DocumentActivated
            Catch ex As System.Exception
                doc.Editor.WriteMessage(vbCrLf & ex.Message)
                doc.Editor.WriteMessage(vbCrLf & ex.StackTrace)
            End Try
        End If
    End Sub

I'm fairly sure the code is not getting loaded. The initialize statement isn't running.

For completeness, I have also tried with a blank initialization to make sure there is no possibility of an exception there and my custom commands (which show in the  framework 4.8 solution), don't show.

[ActivistInvestor · Accepted solution]

Assuming that the code you show loads and works as expected when your DLL is NETLOADed, then I would suspect there's an issue with registration, and/or the location of the assembly. 

I would create a new ClassLibrary project that targets .NET 8, with nothing but an IExtensionApplication like the one you're using that displays a message in the Idle sub confirming the method was called. Add a registry entry for it using the same values used in your existing app's registry entry (except for the name of the DLL). Then see if that loads. If it does, you can rule out any issues with the registry or the location of the library.

[kerry_w_brown]

Perhaps write a message to the console from inside the Try block,

spmethomg like 

AcActive.Editor.WriteMessage("\nThe answer is 42.\n");

Regards,

[dirvine_behlen_ca]

I was able to make a blank project load with a simple command targeting net8.0. However, I can't find any difference between the way I have the two projects registered or defined. My other project has a lot more dependencies. It is possible that the problem lies in the dependencies. I might transfer features from one project to the other a few at a time until I break it--or mysteriously not break it.

The project I started with was an attempt to upgrade to net8.0 and maybe something subtle is wrong there.

[dirvine_behlen_ca]

A revised test program works like this (to test loading on document activated).

Public Class FriendlyToolsInit
    Implements IExtensionApplication

    Public Sub Initialize() Implements IExtensionApplication.Initialize
        AddHandler Application.DocumentManager.DocumentActivated, AddressOf Tasker_DocumentActivated
    End Sub

    Public Sub Terminate() Implements IExtensionApplication.Terminate

    End Sub

    Private Sub CommandEnded_Export_Attributes(sender As Object, e As CommandEventArgs)
        If TypeOf sender Is Document Then
            ' do that thing
        End If
    End Sub

    Public Sub Tasker_DocumentActivated(sender As Object, e As DocumentCollectionEventArgs)
        If e.Document IsNot Nothing Then
            e.Document.Editor.WriteMessage(vbCrLf & "Document Activated. Don't worry.")
            AddHandler e.Document.CommandEnded, AddressOf CommandEnded_Export_Attributes
        End If
    End Sub
End Class

I am guessing that I have a dependency problem in my original program. I have actually changed things over to use the new stub program with the previous registry entry (some renaming going on of the stub project). I will keep adding until I break it or don't.

[dirvine_behlen_ca · Accepted solution]

Main issue was that the new style of projects in Visual Studio needs you to use a Publish configuration to get all of the dependencies.