topic Re: How do you deal with .net assembly locking (making changes without restarting autocad)? in .NET Forum

How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Mon, 08 Sep 2025 12:53:19 GMT

I'm wondering if there is some established solution already to NETLOAD without locking a .dll assembly. By default you can't recompile into a .dll that has been netloaded, because it's locked by autocad. I wrote an InvokeAddinCommand that loads dll as bytes and runs command without actually opening and locking a .dll. But I'm wondering if this is reinventing a wheel and someone has done something like this already?

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Mon, 08 Sep 2025 15:05:07 GMT

Sounds like you're trying to debug with edit and continue.

https://keanw.com/2008/09/tired-of-not-be.html

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Mon, 08 Sep 2025 17:12:28 GMT

I've looked into debugging with edit and continue (I believe they call it hot reloading now?), but it's not the same as simply rerunning your new command from an updated dll. Practically, there is a lag of 2 to 10 seconds to attach a debugger to autocad/revit process - rerunning a new dll is well instantaneous, which can make a difference when you suck at coding like me 😛

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Mon, 08 Sep 2025 17:46:10 GMT

I don't have an issue with edit and continue... huh... so that's why I'm not better at coding?! 😅

Jokes aside, perhaps someone smarter than I will be along shortly to offer something more helpful.

Cheers

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Mon, 08 Sep 2025 20:02:52 GMT

> so that's why I'm not better at coding

actually that would mean that you are better (in all honesty, if you are able to develop with just the debugger and restarting autocad each time I'm somewhat impressed and a little scared)

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Mon, 08 Sep 2025 22:54:45 GMT

@baleti3266 wrote:
> so that's why I'm not better at coding
actually that would mean that you are better (in all honesty, if you are able to develop with just the debugger and restarting autocad each time I'm somewhat impressed and a little scared)

That's kind of you to say... before I had a kid and grew up, that would totally have been signature inspo Haha... 'BB is somewhat impressive and a little scary' ~ baleti3266

I guess I (still?) do that, as I've never seen a different/better way, TBH.

I know that VS can attach to a process. I've never really done it, as it was my understanding (correct me where I'm wrong), that the DLL loaded once you attach stays loaded when you detach. Debug & launch works fine for me (since edit & continue) mainly so I can be working (I'm a civil designer), pause on that session to test code in a new session, without leaving a new assembly loaded in my production instance, if that makes sense.

In any event, I genuinely appreciate the interesting topic. 🍺

Perhaps @_gile @norman.yuan can provide actual help.

Cheers

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Tue, 09 Sep 2025 00:52:39 GMT

hah thanks, I may have to give debugging another try then

method I was using feels "hacky", at startup autolisp (acad.lsp) copies .dll into a temporary directory and netloads it, so that each autocad process has its own copy. In addition to that running InvokeAddinCommand can make another copy directly in process memory (reads raw bytes from .dll) and executes that instead of locking the file and does so each time .dll changes (if it doesn't change it uses previous in-memory version). This way you can compile to hearts content without attaching debugger to autocad process and once ready the next time autocad starts it will have the updated version

just finished updating this first bit actually: Commit 72ff371

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Tue, 09 Sep 2025 01:41:21 GMT

I'm a fan of the Autoloader mechanism, especially as it allows custom sysvars to be implemented incredibly easily.

That said, for a 'sandbox' VS solution apart from my production builds, I simply block comment out the assembly loading Component from PackageContents.xml (so my main session doesn't load the sandbox assembly, it's fine if they load the sysvars, etc), then in the VS debug properties, command line arguments, I include a /b switch call to load a simple .SCR that then NETLOADs the assembly (which itself builds to the Autoloader app .bundle).

Silo for when I need to work through the plugin idea, then easily un-block comment the Component in PackageContents.xml when ready for production, and you've got yourself an app to distribute.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Tue, 09 Sep 2025 12:39:57 GMT

interesting, thanks - that's a quite different process. I guess if you know your code well that's fine, but the overhead of restarting autocad, commenting out Component in PackageContents.xml and attaching debugger (I assume .scr+netload step is instanenous though) each time is a bit much for me. Especially when it seems that you can just recompile and run .dll in a single command and in current session. Then again, I'm mostly "vibecoding" through claude, so my attention span isn't great.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Thu, 11 Sep 2025 16:07:14 GMT

after two days of running autocad I must admit that compared to revit an occasional restart is actually fairly feasible - it's only about 10-30 seconds for most sheet sets

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Thu, 11 Sep 2025 16:44:28 GMT

@baleti3266 wrote:
interesting, thanks - that's a quite different process. I guess if you know your code well that's fine, but the overhead of restarting autocad, commenting out Component in PackageContents.xml and attaching debugger (I assume .scr+netload step is instanenous though) each time is a bit much for me. Especially when it seems that you can just recompile and run .dll in a single command and in current session. Then again, I'm mostly "vibecoding" through claude, so my attention span isn't great.

Perhaps I was unclear; while I'm 'sandboxing' a new app, I comment out the PackageContents.xml component for the assembly only (once). In VS, my plugin builds to the Autoloader app .bundle folder each time, for debug & release builds. Also in VS, my Debug settings include a /b switch to load a SCR located within my VS solution (which NETLOADs the new build for me on acad.exe session launch). This allows me to be working in one session with live project drawings, and debug in a separate session without needing to quit both on next debug. While debugging, I can edit and continue repeatedly within the same, single AutoCAD or Civil 3D session, until I either raise an exception I've not accounted for which crashes, or until I make another change that prevents edit and continue from working. I do NOT debug launch, test something, stop debugging, edit the code, debug launch again, etc. Not happening. Only when done debugging, and I'm ready to distribute the app .bundle, do I then make a final release build, and uncomment the assembly load component of PackageContents.xml (once).

[Edit] - If anyone has a better, more efficient way of doing this - please share it - if it only saves me 15 minutes a day, extrapolate that out, that's an extra +/- 1.5 weeks per year of time I get to spend with my family.

@baleti3266 wrote:
after two days of running autocad I must admit that compared to revit an occasional restart is actually fairly feasible - it's only about 10-30 seconds for most sheet sets

I'm glad it's working faster for you than expected... AutoCAD.IsDefinitely != Revit

Cheers

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

ricaun — Fri, 12 Sep 2025 13:29:38 GMT

@BlackBox_ wrote:
Perhaps I was unclear; while I'm 'sandboxing' a new app, I comment out the PackageContents.xml component for the assembly only (once). In VS, my plugin builds to the Autoloader app .bundle folder each time, for debug & release builds. Also in VS, my Debug settings include a /b switch to load a SCR located within my VS solution (which NETLOADs the new build for me on acad.exe session launch). This allows me to be working in one session with live project drawings, and debug in a separate session without needing to quit both on next debug. While debugging, I can edit and continue repeatedly within the same, single AutoCAD or Civil 3D session, until I either raise an exception I've not accounted for which crashes, or until I make another change that prevents edit and continue from working. I do NOT debug launch, test something, stop debugging, edit the code, debug launch again, etc. Not happening. Only when done debugging, and I'm ready to distribute the app .bundle, do I then make a final release build, and uncomment the assembly load component of PackageContents.xml (once).

I recently create a package and a template to create AutoCAD plugins based in my Revit template.

The video is in Portuguese but has auto-generate audio in English. And here is the template package: https://github.com/ricaun-io/ricaun.Revit.Templates

In that case I'm coping the PackageContents.xml and content every build, and the debug should open AutoCAD.

At the moment I don't have any way to hot-reload the AutoCAD plugin on runtime. Only way I know would be to create a plugin to do that, like my ricaun.AppLoader plugin for Revit.

I already know a way to load/unload commands:

CommandUtils.cs

Would be easy to do I guess, AutoCAD is so much easier to work comparing with Revit plugins.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

kerry_w_brown — Sat, 13 Sep 2025 00:20:49 GMT

Perhaps it's a definition of terms issue.
to me :

Hot Reload is a feature in Visual Studio which can automatically re-compile and load in changes to your program while you are debugging, without having to pause, or do a full rebuild.

Regards,

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

ricaun — Sat, 13 Sep 2025 13:06:35 GMT

@kerry_w_brown wrote:
Perhaps it's a definition of terms issue.
to me :
Hot Reload is a feature in Visual Studio which can automatically re-compile and load in changes to your program while you are debugging, without having to pause, or do a full rebuild.

Hot Reload works great in some situations, but is not gonna restart the IExtensionApplication, like Terminate and Initialize again.

In Revit most at the time I don't use Debug, if I can 'reload' the addin application with Revit open I just build the project again and I have a new version running.

I can always attach the Debug in Visual Studio latter using this: https://github.com/ricaun-io/RevitAddin.VisualStudioDebug/

Anyway technically is impossible/really hard to unlock a .net assembly that is been using by a windows application process, if the application loads the dll by default is lock until the application closes.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

gleeuwdrent — Fri, 19 Sep 2025 07:18:49 GMT

I am using a custom workaround to reload assemblies. I put all my code in a try-catch block, and in the catch I'm displaying the error message + stacktrace. I simply load the builded dll with NETLOAD in AutoCAD (without using the Visual Studio debugger) and run the command. If I get an error, it gives the error description and error line. Then I change the code, build the dll with a different name (I'm using a version number in the name) and load the new dll with NETLOAD. This overrides the old CommandMethod and I can test again. In this way there is no need to restart AutoCAD while testing. Only disadvantage is that you only get the error message+stacktrace, no further debugging information.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Tue, 23 Sep 2025 22:24:47 GMT

@gleeuwdrent this sounds like mine approach as well, I've setup acad.lsp to first copy .dll to a temporary location and netload it instead though, so that you can rebuild the original .dll without having to juggle names. After a few weeks of working with it I must say it's shown to be quite buggy, but it should be repairable in the future.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

ActivistInvestor — Tue, 23 Sep 2025 23:19:23 GMT

@baleti3266 wrote:
@gleeuwdrent this sounds like mine approach as well, I've setup acad.lsp to first copy .dll to a temporary location and netload it instead though, so that you can rebuild the original .dll without having to juggle names. After a few weeks of working with it I must say it's shown to be quite buggy, but it should be repairable in the future.

This trick (copying the dll to another location and/or renaming it) isn't really workable in any but the simplest scenarios.

The problems with doing that are many. All previously-loaded copies of the assembly remain loaded, and the types in them are not equivalent. IOW, (assuming 'MyPlugIn01.dll' and 'MyPlugIn02.dll' are copies of the same file), 'MyClass' in MyPlugin01.dll is not the same class as 'MyClass' in MyPlugin02.dll. They are different assemblies with different types. So, if you use typeof() or GetType() somewhere you are likely going to have problems.

And then there is the problem of static (shared in VB) variables which have process-scope. That means each time you reference a static member in an assembly that was renamed and 'reloaded', you are referencing a different copy of that static member, which in most-cases, defeats the purpose of using static members, and also leads to bugs.

So, the 'trick' being discussed here and elsewhere, can actually become the source of numerous bugs.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

BlackBox_ — Wed, 24 Sep 2025 01:04:33 GMT

@ActivistInvestor - given development of AutoCAD-related tools:

How would you suggest someone properly debug a .NET (non-COM dependent, such as SSM API, etc) plugin?

When would you recommend debug launch vs process attach?

TIA, Cheers

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

baleti3266 — Wed, 24 Sep 2025 20:19:51 GMT

noted, my current implementation is very buggy and the reasons you listed may be part of it, however I had successes using this method with revit api - a Release dll loaded on start for everyday use and Debug dll invoked through reflection for development. Do you think there is anything specific to autocad api that may be getting in the way? Because if there isn't I'm tempted to continue ironing bugs out until it works. Not sure how simple my needs are, usually it's just commands setting attributes, changing views, reading .dwgs across documents as separate commands.

Re: How do you deal with .net assembly locking (making changes without restarting autocad)?

ActivistInvestor — Fri, 26 Sep 2025 15:26:21 GMT

@BlackBox_ wrote:
@ActivistInvestor - given development of AutoCAD-related tools:

How would you suggest someone properly debug a .NET (non-COM dependent, such as SSM API, etc) plugin?

When would you recommend debug launch vs process attach?

I use both, but often just use Attach to Process because it's faster. I also test without the debugger (again because it's faster), but may come across something that I need to look at more-closely, and so I can just attach at any time for that.