Feedback on Link and Disjunctive Demands

re: Feedback on Link and Disjunctive Demands

Nicole Calinoiu — Wed, 09 Mar 2005 12:07:00 GMT

Oops... I missed the friend assemblies aspect of this that Michele caught. I've already responded to a similar recommendation to use friend assemblies in place of identity permissions at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=e6d03969-e4f1-4b81-a051-2540429efee2. In case you don't want to wade through that mess, my two main points from there are:

1. One might want to expose a semi-public API to assemblies that don't yet exist at the time the API is released.

2. Not all internally visible types and members should necessarily form part of a semi-public API.

I also agree with Michele's point concerning reflection, but it'll become largely irrelevant if fully trusted code passes all identity permissions since most code that has permission to reflect into internally visible members acquires that permission via a full trust grant.

re: Feedback on Link and Disjunctive Demands

Michele Leroux Bustamante — Sun, 27 Feb 2005 05:09:00 GMT

"Whidbey also introduced friend assemblies, which can help you achieve the same goal."

I have a real issue with recommending friend assemblies to achieve the same goal:
1. This couples assemblies. You have to specify the assembly name for the InternalsVisibleToAttribute, but what you more likely want to do is specify which "strong name callers" can access all of your types. With StrongNameIdentityPermissionAttribute I can (yes, for each type) specify a group of callers by their private key signature - i.e., approved partners or more likely "our" assemblies).

2. InternalsVisibleTo does not prevent reflection over types and members, even if those types/members are internal/protected/private. StrongNameIdentityPermissionAttribute does protect private members (et. al.) if you apply it at the type level (it can't be applied to fields).

IMHO on very rare occasions should friend assemblies be leveraged.
Thankfully, now we have DemandChoice to specify multiple valid strong name demands/linkdemands.

re: Feedback on Link and Disjunctive Demands

Nicole Calinoiu — Wed, 16 Feb 2005 20:48:00 GMT

a) So far, only in scenarios for which DemandChoice would be a better option. That said, I do have a plan to use a custom non-CAS permission that would be quite expensive to verify under certain conditions. Having the option to use a LinkDemand where appropriate could help avoid some performance bottlenecks.

b) There are scenarios where I would find DemandChoice to be very useful. For example, when invoking a managed wrapper that calls into an unmanaged API (e.g.: OpenFileDialog), the managed wrapper often maps from some other permission onto UnmanagedCode permission. In this sort of situation, I might want to be able to use DemandChoice to force all calling code to have either UnmanagedCode permission or the permission demanded by the managed wrapper. (In the OpenFileDialog example, this might mean asserting FileDialogPermission after making a disjunctive demand for FileDialogPermission or UnmanagedCode permission.)

re: Feedback on Link and Disjunctive Demands

Sebastien Pouliot — Wed, 16 Feb 2005 19:42:00 GMT

a) Yes I've already implemented something like that using a custom (non CAS) IPermission based class. LinkDemand was cheaper to use (but a full Demand would have worked).

b) The only time I missed that feature (1.0/1.1) was for grouping multiple identity permissions together. We prefered using declarative security (as much as possible) to allow "easier reviewing" of the permissions. However I much prefer using declarations at a class/method level than at the assembly level.