LSP to run NETLOAD to load custom DLL not working, but manually loading same DLL with NETLOAD from the commandline works

[Curtis_Waguespack]

Has anyone seen something like this before?

Can we intercept the NETLOAD call to see information about what is happening when the DLL fails to load?

Any thoughts or ideas?

• Customer uses LSP routine to run the NETLOAD command to load a custom DLL
• was working in this version of ACAD (2021) before updating the DLL
• stopped working when custom app was upgraded from .NET 4.71 to 4.8
• They can determine that NETLOAD is running successfully from the LSP, as their other parts of the LSP script that run before and after run without issue
• Oddly, if they run the NETLOAD command manually from ACAD they can load the DLL and the custom app into ACAD as expected

• there is no "Cannot load assembly. Error details:" message or details in the ACAD command line when it fails to load

• Customer has followed the recommendations in the article:

Cannot load assembly... Operation is not supported" when loading a DLL file via NETLOAD in AutoCAD (autodesk.com) 

[ActivistInvestor]

What does "not working" mean? 

Does the assembly define commands that are not recognized?

Does the assembly have a class that implements IExtensionApplication?

What dependencies does the assembly have on non-AutoCAD APIs?

Without knowing the above and various other specifics about your app, it's just a guessing-game.

So, my guess is that there is a dependence on a non-AutoCAD API, framework, or assemblies that are not compatible with .NET 8.

[norman.yuan]

You did not say it explicitly, but I assume the LSP is executed on AutoCAD startup (say, it is Acad.lsp/acad202x.lsp). 

Yes, there is way to intercept the DLL loading: implement IExtensionApplication.Initialize() in the DLL. My bet is that the DLL already implemented it and that is very likely the source of the issue: the DLL did not work when loaded on AutoCAD startup, but works if loaded with NETLOAD command manually AFTER AutoCAD has started.

That is, if there is code execution in the IExtensionApplication.INitialize() and run into exception, it would render the DLL as failed loading silently. Different AutoCAD versions/verticals may have different components loading orders. If the code in Initialize() depends on something must be available, then error could happen. One of the most incidents of this kind, which are so often asked here, is the code trying to load/create custom ribbon menu items on AutoCAD startup, but the ribbon menu component is yet not available.

So, you need to look into the DLL project/code to see if there is IExtensionApplication.Initialze() ipelemented, what the code does there.

[Curtis_Waguespack]

Thank you all for the replies.

A deeper look into the Prism.Unity.Extensions, revealed a mismatched assembly (System.Runtime.CompilerServices.Unsafe).  Removing Prism IOC completely and replacing with Microsoft.Extensions.DependencyInjection fixed the netload issue in this case.