If I create a dll and put it on the network, and 20 cad users netload the dll at the same time will that create any problems in AutoCAD?
>> If I create a dll and put it on the network, [...] will that create any problems in AutoCAD?
Yes, they will not be loaded as by default all non-local drives are "not secure".
You have to use the CASPOL-utility for defining network-drives to be seen as secure, or, beginning with Framework 4 (beginning with AutoCAD 2012) you can modify the acad.exe.config and add a parameter
<loadFromRemoteSources enable = true>
See also Kean Walmsley's site >>>here<<<
- alfred -
Let me ask you this: how many programs do you already have installed that have network-located DLL files?
Refer to Alfred's post (and the link to Kean Walmsley's site) for how to allow it. As far as what I believe you were actually asking, no it will not cause a problem to have 20 (or 200) users load the same .dll from a network location.
It will cause you problems when you attempt to make updates, because the file will be locked if any user has it loaded. This, for me, is easy enough to get around, by making updates after hours when there usually isn't anybody left in the office.
dgorsman... I've seen you make the same comment several times, and I want to ask you, do you have 1000+ .lsp routines installed on each individual cad machine? I think not, and I don't see this as any different. Having my .dll addins located on and loaded from a network location allows for a single point of update, and tighter access control. This is the way I chose to do it (and I think I may have said before, that is the way the people who sign my paycheck want it done).
LSP is *vastly* different than dotNET managed DLLs, they are far closer to scripting and data files, and unlike DLL files have much more limited security implications. LIN files? Sure. CUIx? No problem. AutoCAD (or any other application) DLL files? Whoops, not working - and for good reason. Personally, I always think a good starting point is to look at what professional software compaines are doing for their programs rather than trying to find ways to get around features which are there for good reasons. That applies to not just file locations but types of files (database? XML? CSV? Excel? HTTP query?) and settings (CFG file? Registry? Hard-coded?) as well. Look at what's been done, why it's done that way, why it isn't done another way.
Trying to update centralized DLL files requires *everybody* to be kicked out of AutoCAD. Not possible during working hours, as there is always somebody working; can't do it overnight either as some users leave their computers logged-in, running, and locked. Trying to remotely and automatically kill those sessions is hard enough, let alone dealing with project leads yelling at me for doing so; and getting IT to set up some that kind of batch service (or permit using CASPOL to poke holes in the security system) is more pain than it's worth. If you don't have to deal with that, great - makes life easier for you. Not so much here, and I suspect in other places as well. For me it's easier to code up a hundred-odd line EXE to do a periodic update check to update the local files.
First, before I get into any of this, I'm not starting an eFight here. Just trying to have a meaningful discussion.
My SysAdmin can (if needed) identify and detach any connections to my .dll in about two minutes (even remotely). (That does not even require the AutoCAD session to be killed, only the file lock on my .dll)
Since this is a LAN with no outside WWW access, and I set the access permissions to each .dll file individually, not the entire directory, I don't believe there is any security risk involved with what I am doing. At the very least, any security issue that may exist, could still be a security issue under your proposed .EXE updater. Unless you are doing some sophisticated signing and verifying of the updates, all a person would need to do is put a malicious file in the location watched by your updater, and you will end up copying it down to the local machines where it can do whatever it wants.
Whatever the code is doing (accessing the registry, writing local files, whatever...) it would be doing the same thing if it were installed on the local machine, so if it is going to be trusted to perform those actions from the local machine, why should it be denied the right to perform those same actions from a secure LAN?
Maybe someone in my company could make a malicious .dll with the same name as mine, and overwrite my file in the same directory, but now we get into my comment about tighter access control. They would have to have write access to the directory, which they do not. They would also be required to have the knowledge of CASPol and network security to even arrive at that option as a plan. The only people in my office that applies to is the two SysAdmins.
I don't even feel like what "They" (Commercial Developers) have done even applies to the thought process of what I am doing. Most commercial software is not designed to be used in the same manner as an AutoCAD add-in, and even if it is, it usually carries some form of licensing restrictions as to the number of users, or number of installations. This is in-house software, with no such restrictions.
It seems to me from your comments, that your company's IT department enforces tighter restrictions on you than mine does. As I said before, the President of my company is adamant that our proprietary developement efforts NOT be installed on the local machines, so for me, it is the opposite sort of moot point.
Hi everyone and thank you for your input. For the past seven years I have implemented both local and network load of dvb and lisp files. Both have their pros and cons. I also wrote a code that updates the local systems menu, dvb,lisp,pallets when the update is available.
However, with windows 7 systems I get too many security questions making a simple update a little bit confusing for the users.
Chiefbraincload, perhaps a solution to the locked files would be to have the new dll files under a newly dated folder. When the user starts autoCAD a simple code will check if a new dll folder exist and if so, will switch a new pointer lisp loader file to point to the new directory; afterwards report that PC to a txt file for tracing purpose. After sometime the old dlls can be deleted.
That is just an idea. My initial concern was more towards multiple users loading a single dll. If a dll is locked will everyone have to get out of AutoCAD or will just the last user have to close AutoCAD?
That would require code access security to be applied to each new folder for each update, and I currently only use Lisp (a menu Lisp .mnl file to be precise) to load one of my .dll's whenever the coresponding menu is loaded. The rest of them are demand loaded on Command Invoke through the registry, and the registry entries would have to be changed for every update.
For what it is worth, I have contemplated putting together some sort of Updater code, to watch a certain directory for updates, and then try (overnight) to copy them into the appropriate deployment folder, but I have never gotten around to actually setting it up. They keep me too busy to spend any time on it.
For the moment, I'll just continue making updates after hours, and the file lock issue isn't that big of a deal (for my SysAdmin, I don't have access to the tool she uses, or I would tell you what it is).
"If a dll is locked will everyone have to get out of AutoCAD or will just the last user have to close AutoCAD?"
As far as the users are concerned, any number of users can load (read) the same .dll at the same time (there MIGHT be a problem if two or more users actually tried to load the .dll at the exact same precise moment in time, but I have never experienced that as a problem). The file itself is only read once, and loaded into memory on the local machine. (Which does cause me some confusion as to why AutoCAD holds a file lock open on the file once it has been loaded, I don't understand why that is necessary)
The problem of the file lock only comes into play when you, the programmer, try to update the code. You can not rename, delete, or overwrite the file while AutoCAD has a lock on it. In that case, All users who have the file loaded will have to exit AutoCAD in order for that file lock to be released. In my case, after hours, about half the time, there is no lock, and the other half of the time it is only one or two users.
Sorry if that was too verbose, but even if you knew half of that before, maybe the next guy to find this thread on a search doesn't
Your post leaves me with a question...
"You have to use the CASPOL-utility for defining network-drives to be seen as secure,"
First for clarification, I would never use CASPol to declare a "network drive" to be secure, or even a network folder. I restrict my trust declarations to the specific files that I want to declare as trusted, so that no one can simply put a new file in the same "secure" directory and run it without having to assign trust to that specific file.
now my question, you say "or, beginning with Framework 4 (beginning with AutoCAD 2012) you can modify the acad.exe.config and add a parameter", but I would say and ... you must modify the acad.exe.config. I can state for certain that applying Code Access Security alone will not allow the .dll to be loaded, if you do not add the LoadFromRemoteSources value, but are you saying that setting the LoadFromRemoteSources = true means that you do not have to set the Code Access Security trust level? I was not under that impression, but I don't think I have ever tested it that way.
>> are you saying that setting the LoadFromRemoteSources = true means that you do not have
>> to set the Code Access Security trust level?
In short words: yes.
With Framework 4 you just need the LoadFromRemoteSources-setting and that's it. It's not necessary any more to play with CASPOL (or similar network admin tools) to make a DLL loaded (and executable) from a network-drive.
- alfred -
Access a broad range of knowledge to help get the most out of your products and services.
Download & InstallationGetting your Software