dll on the network, will that be a problem?

[Anonymous]

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?

Than you,

-Jay

[Alfred.NESWADBA]

Hi,

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

[dgorsman]

Let me ask you this: how many programs do you already have installed that have network-located DLL files?

[chiefbraincloud]

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

[dgorsman]

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.

[chiefbraincloud]

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.

[Anonymous]

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?

[chiefbraincloud]

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 😉

[chiefbraincloud]

Alfred,

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.

[Alfred.NESWADBA]

Hi,

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

[chiefbraincloud]

Yes, since my last post, I tested it and found that to be true...

I have to say I have a big problem with that, from a security perspective, in that the previous CASPol methods allowed me to declare only specific files as being trusted (as my previous posts indicate), but the new, supposedly better, method is to say, Oh, yeah AutoCAD can load whatever the heck it wants!  (I realize this is not an AutoCAD issue but a MS .NET 4+ issue)

I am going to have to take another look at all this from a security perspective, and inform the powers that be of my findings. 

Not two minutes before I loaded my email and saw your reply (I am at home now ~9:30 pm GMT -7:00), I did find a potential solution that MIGHT re-enable the legacy CASPol behavior.  But as yet I have not investigated it enough to understand whether this should be applied to my add-ins or to the acad.exe.config.  And I can't test it until I get back to work tomorrow.

<configuration>
   <runtime>
      <NetFx40_LegacySecurityPolicy enabled="true"/>
   </runtime>
</configuration>

 I can say for sure (I think) that applying it to my add-ins will not solve the problem of AutoCAD being able to load whatever it wants, or nothing at all, from remote sources, so I assume I am supposed to add this to the acad.exe.config file (possibly in place of, or possibly as well as, the LoadFromRemoteSources value?)

Seriously, I just found it right before I saw your reply, so I have not had the time to investigate it further.

and if dgorsman wants to weigh in on this, I'd be happy to hear any input you might have, and perhaps more importantly, future searchers on this issue can learn from it.

P.S. Alfred, I know your native tongue is not English, but I promise you my German is worse than your English.  So I hope you understand the nuances of what I posted.  I didn't try to change my language for non-English speakers.  I'm not really sure how to do that, honestly.

[Alfred.NESWADBA]

Hi,

for me and for just a few tries, I didn't get the parameter NetFx40_LegacySecurityPolicy to work, setting it to false or to true does not make any difference to the settings I do with CASPOL. So the type of sandboxing of earlier Frameworks seems not to come back to Framework4.

I tried to activate and to deactivate directories with CASPOL, makes no difference, it's just the settings in the ACAD.EXE.CONFIG that makes it working or not.

BUT what is interesting: until now I only saw the parameter loadFromRemoteSources to be the (only) toggle for having the rights to load assemblies from network or not. Now with your parameter NetFx40_LegacySecurityPolicy (=true) it seems to be this is also a toggle for making the assembly loader to trust network-drives.

But looking at >>>this site about NetFx40_LegacySecurityPolicy<<< we should be careful as there are some issues for assamblies not installed in the GAC! Of course I haven't had any issues as I haven't done any performance tests now.

Sorry, for the moment I didn't find a way (for Framework 4 based assemblies) to create security-rights for just specific network-based folders, and so also not for files, but I never played with files security in this context yet.

- alfred -

[dgorsman]

Sorry if that came off a bit harsh.  I'm working on getting a handle on the finer points of DataSets, DataTables, and DataGrid/TreeView controls while being dragged away every 15 minutes by users with easily solved problems.  NOT conducive to getting anything done. 

Our IT is pretty locked down, but its also a different department with the servers and the supervisors in another city.  There is no corporate mandate for local/network storage so I'm free to do whats looks best.  We have a couple of local admins but they have all sorts of IT things to get done.  I wrote the update EXE in far less time than it would have taken to submit the proposal, let them bump it to the head office (and promptly forget about it), remind them I *need* this done, and finally get something which sort of (but doesn't really) get the job done, *plus* getting them to force certain files to unlock overnight so they can be replaced, yadda yadda yadda...  Its just easier to follow the established routines of other programs and be done with it.

Oh, and the updater EXE isn't a "blind" folder watcher - it reads an XML manifest file so it knows precisely which files to be updating (plus any registry entries to handle demand-loading).

[chiefbraincloud]

Sounds familiar.  I am actually working on some code to allow paste operations into a DataGridView control.  I was befuddled to find that there is no automatic paste handling when I created my latest form that uses a DGV.

I am in a small to medium sized Commercial Engineering firm, about 70 people here in the office, with an IT staff of 2.  It does take me some time to get things done if it requires any equipment or software purchase, but with the file locks, I just shoot her an email, and she sends me one back saying who has the file(s) locked, then I check to see if they are in the office, and if not, I ask her to break the lock.

That said, as my previous couple of posts indicated, I have just discovered that for AutoCAD 2012 (or more precisely the .NET 4.0), setting the LoadFromRemoteSources = True means AutoCAD will load anything it is asked to load from anywhere, regardless of CASPol settings.  So I am probably going to want to change the way we do things now, but that will require me convincing the President that it is a problem (shouldn't be too hard, he's no fool).

[chiefbraincloud]

Alfred,

I was able to get the behavior I am looking for with <NetFx40_LegacySecurityPolicy enabled="true"/>.

The assemblies that had been granted trust loaded fine, but assemblies that had not been granted trust did not load.  (There was no error thrown, which is what I would have seen in previous versions of .NET, but at least the assembly did not load)

My guess is that you had both <NetFx40_LegacySecurityPolicy enabled="true"/> and LoadFromRemoteSources = True?

You have to take out LoadFromRemoteSources, and Replace it with LegacySecurityPolicy.  I have currently only tried it on two machines (one Win7 64 bit, ACAD 2012 64bit, and one XP 32 bit, and ACAD 2012 32bit) but both machines seem to be doing what they are supposed to now.  Glad you pointed that out to me, I thought they were already obeying the CAS policies.

Oh, and I don't think the issue about Native assemblies not loaded in the GAC will be a problem for me.  I don't have any Native assemblies, and this setting should only apply to AutoCAD.  I'll come back to this post later if I do see any strange behavior related to this setting.  (and I'm going to tell Kean about it, so maybe he'll do another post)

[Alfred.NESWADBA]

Hi,

>> My guess is that you had both

No, I haven't had them both in the config-file, either the LoadFromExternalSource or the NetFx40_LegacySecurityPolicy.

What I want to ask now is to the following statement:

>> The assemblies that had been granted trust loaded fine

Can you describe me what you do to get a "granted trusted assembly"? Do you define that with the CASPOL-utility or am I missing now something?

If it's CASPOL, then for my testing environment I had removed all groups defined with CASPOL -ag, then I have tried each one of the parameters in the config and in both situations I had success loading the DLL's into AutoCAD (using _NETLOAD). But to be honest, if I really had every situation CASPOL off/on, LoadFromExternalResource off/on, NetFx40_LegacySecurityPolicy off/on correct sorted out? I'm not as sure as I should be (except of I had not both active within the same config) and will it verify again when I know what your definition of granted trusted assembly is.

- alfred -

[chiefbraincloud]

Yes, with CasPol.exe.  This is an example of what I use.

for Win7x64

C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\CasPol.exe -q -machine -addgroup All_Code -url "file://SERVERNAME/PATH/ASSEMBLY.dll" FullTrust -name SR2GcadTools -description "SR2G Cad Tools"

Or if it is a XP 32 bit machine, CASpol.exe is in this directory
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\CasPol.exe

(yeah, I know, there is probably a system variable to get the path to the Framework directory)

I make a .bat file that has one line for each assembly that a user has access too (I have about 4 different types of users, on 2 different types of machines, resulting in 8 different batch files, plus 2 more for a special assembly that only has about 5 authorized users, some on 32bit, some on 64bit)

I tested on of the standard users machines, and yesterday before changing the acad.exe.config, that user was able to load the restricted assembly (sort of, he didn't have a registration code, so he couldn't actually run it, but it did load and prompt him to enter the registration code).

Today after changing the .config file, he is still able to load the assemblies he is supposed to load, but the restricted assembly does not load.

[Alfred.NESWADBA]

Hi,

@chiefbrandcloud

Thank you for your testing and even if I blame myself now, maybe somebody else has the same troubles so I describe what I did wrong in my first tests (for message 12 from this thread).

My primary problem was that I thought that CASPOL from the "Framework 2.x" folder does influence the same security-settings as the CASPOL.EXE from "Framework 4.x"-folder does.

And I always played with the older release, did a

CASPOL.EXE -m -reset

to be sure that all is back to default, but it is not. And so my test-results with different settings in the ACAD.EXE.CONFIG where different to yours as I didn't realise that I have some Framework 4 - settings allowing things to be used.

I had to start the CASPOL.EXE from the "Framework 4.x"-directory to come then to the same result like you have.

Thank you for kicking me into the right direction!

So now I'm also able to use the directory- and filebased security-settings 😉

Thx again, - alfred -

[Anonymous]

I don't know if this is the best way for deploying a dll from a single network location but this is how I am doing it...

I created a lisp file that loads the dll which is put into in my users Startup Suite, this lisp file is also network accessible. So if I make a change to the dll I recompile and copy it to the network location and just increment the number in the filename and then I update the lisp file with the new filename for the dll. The only issue is the users tools dont get updated until they restart there AutoCAD, so I just send out a mass email to remind them to if it's an important update. This is the easiest solution I came up with.

[Anonymous]

TJK77, all this methods listed on the forum look very cumbersome not to mention intimidating. Except yours TJK77. When I initially asked the question I did not even think about the version of the framework, I am currently running 3.5 and am dreading yet another move towards 4.0  .

As I am reminiscing the good old lisp/vba and the ease of how things used to be I have to remind myself to keep searing for strength to pass this learning curve and that somehow it will all pay off after the dust settles.

At the current time I am not seeking any overwhelming solutions, my current goal is to convert thousands of vba line of code to vb.net and to be able to load them to several dozens of users. As users start finding bugs I would like to be able to easily update the dll until all or most bugs are gone. Only after I have achieved I can focus on more elegant ways to deal with the challenges that Mr. Bill has introduced.