> Hi,
>
> If CAS policy is setup to deny an assembly ANC the permission
> FileIOPermission, then if the assembly attempts to do File IO, the .NET
> FW assembly that handles file IO should catch it, right?
Yes, as long as the calls go through framework code paths that demand
FileIOPermission.
> It shouldn't
> be necesarry to put a check for FileIOPermission in the assembly
> itself,
Not if there's already a "downstream" demand.
> and would seem to degrade performance because the check is
> already going to be done further down the call stack, but the .NET FW
[quoted text clipped - 4 lines]
> needs, and put an attribute in the assembly to show it does a demand on
> FileIOPermission? (even though it's redundent).
There's really no need to duplicate permission demands in this way. If you
want to communicate your assembly's minimum required permission set,
consider using assembly-level RequestMinimum permission attributes instead.
In general, one only makes CAS permission demands in code that makes
assertions and/or defines or extends a resource that requires protection.
In practice, most of the latter also make assertions (usually for permission
to call into unmanaged code), so most projects aren't likely to need
permission demands that aren't coupled with assertions. Then again, since
most projects shouldn't need assertions, they probably shouldn't need any
explicit demands for CAS permissions either... ;)
Secret Squirrel - 20 Jan 2006 21:12 GMT
Thanks for the response Nicole.