dotnet security exception issues

[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

[Cerebrus]

Re: dotnet security exception issues

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
SecurityExcepti ons.

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.
[color=blue][color=green]
>> has any of this improved with the latest dotnet version?[/color][/color]

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.

[Dave Cullen]

Re: dotnet security exception issues

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

Cerebrus wrote:[color=blue]
>
> 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
> SecurityExcepti ons.
>
> 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.
>[color=green][color=darkred]
> >> has any of this improved with the latest dotnet version?[/color][/color]
>
> 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.[/color]

[Phill W.]

Re: dotnet security exception issues

Dave Cullen wrote:[color=blue]
> The applications I've written refuse to run on our shared network drive,
> giving security exceptions.[/color]

Look into Code Access Security polies (caspol.exe).
You need to convince the Framework that your network share is as
"trustworth y" as your local disks.
[color=blue]
> My question is, has any of this improved with the latest dotnet version?[/color]

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.
[color=blue]
> 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.[/color]

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.

[Cerebrus]

Re: dotnet security exception issues

>> I've created a strong key .snk file and put reference to it in the[color=blue][color=green]
>> 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?[/color][/color]

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 ("..\..\myKeyNa me.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.s nk", but that doesn't seem to work. But
the above line does work, so I stopped questioning it ! ;-)
[color=blue][color=green]
>> I'll give it a shot and see if I can make this work.[/color][/color]

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

Regards,

Cerebrus.

[Dave Cullen]

Re: dotnet security exception issues

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

Cerebrus wrote:[color=blue]
>[color=green][color=darkred]
> >> 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?[/color][/color]
>
> 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 ("..\..\myKeyNa me.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.s nk", but that doesn't seem to work. But
> the above line does work, so I stopped questioning it ! ;-)
>[color=green][color=darkred]
> >> I'll give it a shot and see if I can make this work.[/color][/color]
>
> Believe me, it works. It's a common issue, so don't worry yourself.
>
> Regards,
>
> Cerebrus.[/color]