Home/ Questions/Q 3423536
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T06:22:00+00:00

I’m trying to understand FxCop CA2122 messages (probably before disabling the wretched things), and

  • 0

I’m trying to understand FxCop CA2122 messages (probably before disabling the wretched things), and I have clearly overstepped my understanding of .NET CAS.

The application is a .EXE, not marked with AllowPartiallyTrustedCallers. We get CA2122 warnings from Code Analysis, complaining about our failure to propagate LinkDemands upwards from the lowest level of calls to methods which themselves have LinkDemands.

Obviously we can run around putting LinkDemands on callers, and then callers of callers, ad-infinitum. This seems entirely purposeless, as every invocation of this code is always going to be full-trust, and hence (AIUI) every link demand is always going to be met anyway. Eric Lippert seems to think it’s highly dangerous to do that, too.

So:

  • What assembly-level attribute am I missing to say ‘this code will only run at full-trust’? (I thought the absence of AllowPartiallyTrustedCallers’ implied this, but perhaps not for .EXEs)

  • Or should I just turn off that CA warning and move on? I do like to understand them properly before I disable them…

Update: I was asked which framework version we’re using – it’s 2.0RTM, and it’s extremely difficult to get upgraded past that point because it’s on an XPe platform.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your underlying assumption that the assembly will only ever run as a fully trusted executable is faulty. There’s nothing stopping someone who can get their hands on your assembly from using it as a referenced library assembly in a piece of malware. If you’ve altered a machine’s CAS policy to grant full trust to your assembly regardless of how it’s deployed, then the malware would potentially be able to use your assembly to execute operations for which it would otherwise not have had adequate permissions.

    The upshot of this is that you really ought to be doing something to prevent satisfying link demands on the behalf of calling code, regardless of your intended deployment scenario. Given that you’re targeting a full trust scenario yourself, this is actually going to be pretty easy. However, the exact approach depends largely on which version of the .NET Framework you’re targeting, so could you please post that detail?

    For .NET 2.0, the simplest approach to addressing the issue would be to apply either SecurityTransparentAttribute or SecurityCriticalAttribute to your assembly. Both attributes will result in the code in your assembly becoming security-transparent by default, which means that it cannot do things like satisfy link demands on behalf of its callers. If there are parts of your code that need to do things that are not allowed to security-transparent code, you should use the SecurityCriticalAttribute instead of SecurityTransparentAttribute at the assembly level since this will allow you to explicitly promote types and/or members to security-criticality if they need it. (For a bit more detail, see Link.)

    • 0