OK...please don't refer me to a previous post about this...I just looked at those previous posts...and none anwer my question.
Can you run a 4.0 DLL from a network location?
I can run it on my machine.....
(And yes, I hvae posted similar questions recently...)
I had a user install AutoCAD 2011
I had that user Download .NET Framework 4.0
I had user update his acad.exe.config file accordingly (To allow 4.0)
When he tried to load the DLL from a network location...he got:
This topic has been discussed here many times.
You need to configure the computer for the .NET security if the .NET code is loaded from outside the local computer (from LAN/iThe Internet...) with tool CASPOL.exe.
Google "CASPOL.exe" for learn more on this topic.
At this moment, you first want to verify if your .NET4 DLL works with a user's Acad2011 with .NET 4 installed. So, copy the DLL to local (or even just use a mamory stick) and do your test. You'd worry about loading DLL from network drive later.
Norman Yuan
OK.....got it....thx
I thought one of the "advantages" of the .NET programming environment....Was the ability to run an app from a centralized location.....not haveing to Copy and Register DLL's locally as you had to do with VB 6.0 etc.......Is this crap any different?
Frustrating....
There is no comparable counterpart to .NET's code security configuration in COM DLL (VB6 dll). By the way, you can place a VB6 DLL (COM DLL) in a network folder (central location) and do regsvr32 it from there.
Norman Yuan
"....VB6 DLL (COM DLL) in a network folder (central location) and do regsvr32 it from there......"
But each user (client machine) must regsvr32 it right?
I thought .NET was supposed to do away with that?
Sort of, but not really. The Frameworks collect all those little methods, properties, objects, and other goodies so you don't have to do them all yourself, enabling you to do more in less time. If you need something uber-optimized you can still write your own to replace them. With all that power comes the possibility of it being used to do nasty things, so the default security settings are quite tight. Its generally easier to duplicate what other software is doing, which is locating its operation DLLs on the users computer while providing the option of reading data-only files from a network.
It requires a little extra planning up front (where to locate, use scripting or bootstrap DLL to copy-local, version control, roll-backs, timing, etc.) but there are some benefits. You don't need to diddle with security settings on everybody's computer that may or may not be locked down. DLLs can't be overwritten while they are loaded, which can be a pain if they are being loaded from the same network location (middle of the night, you say? There's always a few users who never log off or even close the program overnight).