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

[baleti3266]

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?

[BlackBox_]

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

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

[baleti3266]

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 😛 

[BlackBox_]

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

[baleti3266]

> 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)

[BlackBox_]

---

@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

[baleti3266]

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

[BlackBox_]

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.

[baleti3266]

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.

[baleti3266]

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

[BlackBox_]

---

@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

[ricaun]

---

@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.

[kerry_w_brown]

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,

[ricaun]

---

@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.

[gleeuwdrent]

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.