Why? You asked...
I work at a very large architecture firm and we have lots of custom tools and scripts (old, new, third party, etc). All of our tools and scripts are located on a central file server in each office. We wanted a consistent way of loading them into AutoCAD, and we also wanted to be able to update them across multiple offices even while the tools are in use. I've developed a tool that autoloads the latest version of a tool, reguardless of whether its VBA, ARX, .Net, EXE, or LSP. We can deploy the latest version of a tool into a new versioned folder without worrying about locked file issues. The next time the user loads AutoCAD, they get the latest version or each tool loaded. This enables drag and drop deployment of any type of autocad custom tool. I can also disable a specific tool version, rollback to a previous version, or load a specific version. CAD managers don't need to rewrite menu files, update the registry, update acad.lsp, or wait until architects go home at one in the morning so they can get past locked file issues.
I've got everything working great with the exception of Lisp files (I'm using acedCmd). Obviously, lisp files don't have the locking issue, but it would be nice if I can load them with the same versioning mechanism. I wrote a simple version of this in lisp to load lisp files (once again, drag and drop deployment), but I wanted to expand on this and I much prefer .Net to do this.
So, examples of using this tool:
netload "S:\CAD\MyCompany.AutoCAD.AutoLoader.dll"
autoload ADDpath "S:\CAD\CustomTools"
autoload ALL
autoload ARX ALL
autoload EXE SampleUtility
autoload ARX SampleTool/01.00
autoload NET SampleDotNetTool
So what can't .Net do??? From what I can tell, it can't load a list of lisp files without crashing autocad do to SendStringToExecute behavior.
Thanks for the info on acedPostCommand. It looks like I might be stuck with having an independant lisp loader written in lisp.