dotnet security exception issues

  • Thread starter Thread starter Dave Cullen
  • Start date Start date
D

Dave Cullen

My version of dotnet is 7.0.9955 Studio 2002. The applications I've
written refuse to run on our shared network drive, giving security
exceptions. I've not been able to find a workaround for this problem and
the VS 2002 MSDN stinks.

My question is, has any of this improved with the latest dotnet version?
I'm still using VS 6.0 for development and I don't want to buy the
latest stuff if it doesn't work for me. My applications MUST run from
the network without fussing with security.

Thanks
 
Hi,

When you run code from your local machine, it runs in the MyComputer
security zone, but when you run it off of a server, or network share,
it runs in the LocalIntranet zone. The latter imposes much stricter
restrictions on your code. That would be the reason why you're getting
SecurityExceptions.

Your best option in this case would be to strong name your assemblies
(once you've finished development on them), and then use the .NET
Framework configuration tool to assign a higher level of Trust to these
assemblies. Or create a new code group with a higher trust
configuration, and add your assemblies to that code group.

Probably yes, but it still works quite well with VS 2002. I too have
2002 and have no such problems. Those security features are for your
benefit, remember. ;-)

Regards,

Cerebrus.
 
Thanks for the reply. I'll give it a shot and see if I can make this
work.

I've created a strong key .snk file and put reference to it in the
assembly module, but no matter where I stick the file the compiler says
it can't find it. Where is the file supposed to be?

Thanks

Dave
 
Dave said:
The applications I've written refuse to run on our shared network drive,
giving security exceptions.

Look into Code Access Security polies (caspol.exe).
You need to convince the Framework that your network share is as
"trustworthy" as your local disks.
My question is, has any of this improved with the latest dotnet version?

The same security model (more or less) exists in all versions of the
Framework. The way it works is completely deliberate and isn't likely
to change any time soon.
I'm still using VS 6.0 for development and I don't want to buy the
latest stuff if it doesn't work for me. My applications MUST run from
the network without fussing with security.

If you want any machine to run CLR code from a network share, you either
have to keep your applications /extremely/ simplistic, so as to work
within the Framework's security "sandbox" or more likely, as you put it,
"fuss with security".

Regards,
Phill W.
 
I've created a strong key .snk file and put reference to it in the
Yeah, this behaviour is a bit quirky. I usually put the .snk file in
the same folder in which the .vbproj file (and the AssemblyInfo.vb
file) reside. Then in the AssemblyInfo.vb file, I add :

<Assembly: AssemblyKeyFile("..\..\myKeyName.snk")>

I haven't understood this behaviour till now, since if I'm putting in a
relative path to the assembly, which resides in the bin directory, I
should be using "..\myKeyName.snk", but that doesn't seem to work. But
the above line does work, so I stopped questioning it ! ;-)

Believe me, it works. It's a common issue, so don't worry yourself.

Regards,

Cerebrus.
 
OK, I got the project to compile. Thanks for the tip on path specs.

But... If I copy the exe to the share drive, I still get a security
exception when I run it. It looks like the .NET configuration tool will
only change the target computer to "trust" the assembly. Is that true?
Does every machine need to have the security level for the assembly
changed?

Thanks for the help.

Dave
 
Back
Top