.NET Core samples should not include CAS elements

[danmoseley]

In .NET Core, CAS types (like FileIOPermission, etc) and Security Transparency types are stubbed only. CAS is not supported. Therefore the samples in .NET Core topics should not include use of them.

For example, in the AppDomain.UnhandledException topic for .NET Core 2.1 it has this sample:

using System;
using System.Security.Permissions;

public class Example 
{
   [SecurityPermission(SecurityAction.Demand, Flags=SecurityPermissionFlag.ControlAppDomain)]
   public static void Main()
   {
...

Here [SecurityPermission(SecurityAction.Demand, Flags=SecurityPermissionFlag.ControlAppDomain)] should be removed as it does nothing and implies that CAS is relevant.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 48667829-dc8d-680d-6fde-71a46dee4ce7
• Version Independent ID: 15184777-1251-be89-27a7-7ca859082294
• Content: AppDomain.UnhandledException Event (System)
• Content Source: xml/System/AppDomain.xml
• Product: dotnet-api
• GitHub Login: @rpetrusha
• Microsoft Alias: ronpet

[mairaw]

Thanks @danmosemsft. I've added this issue to our security review project. We're hoping to get started on this soon.

[danmoseley]

Here's another example, which reminded me.
https://docs.microsoft.com/en-us/dotnet/api/system.console.bufferheight?view=netcore-3.0

Security
UIPermission 
for modifying safe top-level windows and subwindows. Associated enumeration: SafeTopLevelWindows

A bit confusing if you heard that CAS is dead.

[rpetrusha]

This issue has languished, @danmosemsft, but I'll start addressing it in the next sprint.

[danmoseley]

Thanks, @rpetrusha

[tdykstra]

@danmosemsft How can I get a list of the CAS types and Security Transparency types?

[danmoseley]

https://github.com/dotnet/runtime/blob/master/src/libraries/System.Security.Permissions/ref/System.Security.Permissions.cs seems like a pretty good list

@GrabYourPitchforks does that map pretty well to what should not be in samples anymore?

[GrabYourPitchforks]

That list, plus pretty much everything else in the System.Security.Permissions namespace, regardless of which reference assembly defines it.

Conveniently, Dan just provided a nice list of every API I want to slap [Obsolete] on. ;)

[tdykstra]

The only instances I've found where the CAS types are used for Core snippets are in API ref. There, the same snippet is shown regardless of whether Core or Framework is selected. To remove CAS from the snippet removes it from the Framework 4.x version too. Some options that come to mind:

1. Duplicate each snippet, remove CAS types from one copy, and include both copies in the doc with an appropriate heading for each.
2. Remove CAS types from each snippet, i.e., let the CAS types be missing even when Framework 4.x is selected.
3. Add a code comment at the top of each snippet noting that CAS doesn't apply to Core.

Given that > 1,000 snippet files are affected, all of these options will involve a significant time investment, # 3 seems least problematic, and # 1 seems questionable whether the benefit would outweigh the cost.

[danmoseley]

We haven't supported CAS in .NET Framework for years either. So I think generally (2) would make most sense.

I see the size of the task. If I search samples\snippets for ^\s*\[\w+Permission[^\]*\] I see 819 hits in .cs files. That ignores .vb, and attributes that cross lines. And any imperative use of these things. And of course any use of them in the docs for themselves needs to be preserved.

The good news is that it doesn't have to be perfect or complete. My suggestion is to look for something like the regex above (possbily improved to straddle lines) and just search and replace it away. Then do the same (using angle brackets) for VB. Then bulk revert anything the seems inappropriate. Then compile and either fix or just revert anything that breaks. I'd imagine you could spend a few hours and make a major dent, if you reverted anything that broke.

It does seem like a bunch of work, but after all these years, we should not be encouraging people to continue using these broken things. Thoughts?

[tdykstra]

That sounds like a good plan to me, I'll get started on it next week.

[tdykstra]

Discussed this issue offline with @GrabYourPitchforks and @danmosemsft. Levi will identify specific categories of changes required, and for each category I'll make a PR that addresses all affected snippets.