Seems to me most of developers completely ignore this features. People prefer handling security exceptions as generic ones relying on standard windows roles and rights instead of learning to use CAS ways of enhancing security - probably because CAS is quite confusing in its logic and naming.
Can anyone suggest any general rule-of-thumb/best practices for using CAS at his best in a clean way?
See also this discussion.
The problem is exacibated because a lot of code (perhaps too much) runs at full trust. And then the only checks that get done are things like PrincipalPermissionAttribute checks - most of the rest are simply bypassed. So in many cases there isn't much point! Unless you are loading in external (untrusted) files [and so need CAS], it simply doesn't add a lot in many cases (and yes, there are plenty of exceptions).
CAS is much more useful for clients running in the sandbox (for example downloaded from the internet). Sliverlight takes this to the extreme, with stricter rules (especially around reflection) than regular .NET.
Yes and no.
Unfortunately, you're right - developers rarely use CAS at all, let alone utilize it to it's fullest. In very few situations do I see them actually doing this (okay, its not really the programmers but the organization forcing them....)
Besides being used to allow users to limit assemblies downloaded from the Internet (for example) - though this is rarely deployed outside of Silverlight - I have seen two main uses of CAS.
First is general policy limitations, generally the easiest way to get your feet wet with CAS (esp. since VS can auto-generate the policy file for you). I have seen this in use (rarely) when a sensitive enterprise (e.g. banks) have a third-party custom development of a system that must be secure. This can benefit them by adding additional limitations on what they dont know their programmers are doing.
Second is very specific link demands, in the (again rare) situation that you have a module running at relatively high privileges, and want only specific assemblies calling into your module. For instance, just last week I had a client with a module writing to ActiveDirectory, and wanted to limit access to this function only from a specific system.
Of course, CAS is much bigger than this, but those are really the two best places to start from. As a general rule, and this is of course true for everything, dont decide to use it just because its there, unless it answers a need you have. Policy is the simplest, and makes the most sense to put in place ahead of time.