VB6 does not have the new Managed code security permissions, so the same
component run in VB6 will not create security exceptions.
VB.Net does use managed code in the runtime, which is why you're seeing the
security exceptions when using the same component.
The earlier comment that the security permissions run from the intranet is
correct: the permissions are much more limited. It's likely that the
component you're using violates the permission sets you've been granted for
the assembly. One example is that the same program run from the intranet
will not have permissions to write to the local hard disk.
You'll need to understand the basics of Code Access Permissions and
Administering security policy, here are some links:
Key security concepts:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconkeyconceptsinsecurity.asp
Intranet permission set default permissions:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpcondefaultsecuritypolicy.asp
Administering security policy:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpcondefaultsecuritypolicy.asp
Best practices:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconkeyconceptsinsecurity.asp
.Net security newsgroup:
http://msdn.microsoft.com/newsgroups/?url=/newsgroups/loadframes.asp?icp=msd
n&slcid=us&newsgroup=microsoft.public.dotnet.security
Outline of the best way to fix this:
1. Figure our why the referenced .dll is creating a security exception.
Usually this results from registry or File IO access. Look at the
exception message for details.
2. Use your machines management console to alter the security policy -
"Administrative tools" -> "Microsoft .Net Framework .1.1 Configuration tool"
a.) Create a new permission set based on intranet persmissions, but
with added permissions so the .dll will run correctly.
b.) Change the machines intranet zone code group to use the modified
permission set.
--------------------
