FYI, while TJK77 did not mention it, he must, and you will still have to use CASPOL to set the Code Access Security Policy Permissions to allow your .dll to be run from a network. It is not optional under any circumstance prior to the .NET 4.
The only way to avoid it is to have your .dll installed on each machine.
And the way TJK77 suggested, requires either that you redo the CAS policy every time you update, or that you apply the policy to the folder, instead of the file. I have a Network security specialist here that would string me up if I did that, because that would mean anything placed in that directory would be allowed to execute (not just things loaded into AutoCAD).
And it would mean you can't do demand loading, or you have to change the registry entry that specifies the file every time you update.
Since we are sharing deployment secrets, I will share mine as well. Not sure if anyone will like it, but it works well for us.
To avoid the networked .DLL fiasco, I load all of our applications from the users local machine using the Autoloader utility (AutoCAD 2012 and up).
I store all of the .DLLs on our server in a secure location. I have a login script that deletes all of the folders in the ApplicationPlugins folder on each local machine and then re-copies the folder structure and its contents from the server back to the ApplicationPlugins folder of the local machine. Everything in that folder is autoloaded when AutoCAD starts up depending on parameters in each specific Autoloader .XML file.
So if I need to make a change, I re-build, put the file on the server. The next time the users log into their machine, the script runs and updates the contents of the ApplicationPlugins folder. AutoCAD is started and all of the required apps are loaded!
On a very rare occasion a user will get an "unknown command" on one of the tools (as if something was not copied over properly), so I simply have them run the script manually, or have them log off and back on again! If they just run the script manually, they don't even need to close AutoCAD as it will autoload and new files dumped into the ApplicationPlugins folder!
Works great! The really nice thing is that I can do this with CUI menus as well!
Like I said, not sure if anyone will like it, but it works well for us!
The new autoloader system is definitely on my list of evaluations for our next major version upgrade.
Always nice to have a boss like that Mine isn't a fool by any means, but he readily admits he has no idea of the how or why of most of what I do, so I can operate with very little oversight as long as the clients and users are happy.
Hi Dull_Blades, the way you have it set up is similar to the way I currently have my VBA set up. The only difference is that when the user starts the AutoCad it checks the network to see if an update is available. If an update is available then it does the copy. I was planning to eventually do the same with dll files but because I will have a lot of updates initially I was hoping I could just have the stuff on the network until all bugs are resolved. The way things are turning to be I may end up doing the same thing with dll as I have done with VBA.
Also, fyi, I have a Uploader code that copy the stuff from the network, if I get error during copy all the user has to do is to restart autocad again and it will do the copy again until it done correctly. This way the user never has to load anything manually. Below is the process:
AutoCAD starts à a loaded code checks if a new ‘Loader.dvb’ is available à if Yes it then copies the ‘Loader.dvb’ from network and starts it à The ‘Loader’ then checks to see if an update is available à if Yes it then copies all the dvbs from network.
This approach gives me the flexibility to change the ‘Loader.dvb’ at any time and automate every step of the update even menu and palettes replacement/update.
IMO, running things locally is the only way to go.
People always want to start with tools on network, then the boss says "Bob has to work off site", then you make some offline setup, then get tired of supporting two setups.
You soon realize a local setup has many advantages, like letting the user scew things up, and it gets set back on login.
Also, you can update server files like menu dll's, as the users do not have them in use.
We have used robocopy.exe for years to mirror server tools to local, super slick and free.
Be aware that there is a newer robocopy that handles daylight savings time when looking at file times.
Its size is 208kb, and its tricky to find. I can post if anyone needs it.
internal protected virtual unsafe Human()
Access a broad range of knowledge to help get the most out of your products and services.