Sorry, I should have been more explicit: "don't all strong-named assemblies have full-trust by default, unless explicitly refused?"
Strong-named assemblies are documented as "...placing a LinkDemand for FullTrust on every public or protected method on every publicly accessible class in the assembly". This means if an assembly doesn't refuse FullTrust or doesn't use AllowPartiallyTrustedCallersAttribute it cannot be loaded from a not-fully-trusted zone. And, just because an assembly does refuse some permission, doesn't imply the assembly won't be given full trust. Not that that has any bearing on this topic. So, getting back to StrongNameIdentityPermission; what is the likelihood that a) a strong-named assembly isn't running in full-trust and b) if you've used StrongNamedIdentityPermission to specify a specific assembly, that you don't know whether that assembly is fully-trusted? So, if StrongNameIdentityPermission doesn't grant permission based on the strong- name (or part thereof) is it not redundant? On Wed, 15 Feb 2006 11:25:17 -0700, Mike Woodring <[EMAIL PROTECTED]> wrote: >> Maybe I'm missing something; but don't all strong-named >> assemblies have >> full-trust? > >Nope. A strongly named assembly loaded into an app could have been pulled >from off-host somewhere via an explicit CODEBASE hint, or implicitly from >off-host as part of a no touch deployment, or from someone calling >Assembly.Load and passing in file:// or http:// url that points somewhere >off-host. It's also possible for the developer of a strongly named assembly >to use a RequestRefuse attribute to voluntarily limit the perms they're >granted. Similarly, it's possible for a machine/domain/user admin to >configure CAS policy so that an exclusive code group is used to reduce the >set of permissions a given assembly/ies are granted. Etc, etc. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
