locked
CA1062 code analysis rule is broken by code contracts. RRS feed

Answers

  • The next release will fix some issues with 1062. There is blame on both CodeContracts and CodeAnalysis. If the rule passes with CodeAnalysis without the rewriter, then it should also pass with the rewriter, otherwise it is a CodeContracts problem.

    The issue with 1062 is that if you use your own helper method to validate a parameter, CA1062 will also still fire. The code produced by CodeContracts when using Requires or Requires<E> looks essentially like passing the parameter to another method for validation. So CodeAnalysis will need to be updated to handle this general pattern, not specific to CodeContracts.


    Cheers, -MaF (Manuel Fahndrich)
    Thursday, May 6, 2010 5:41 AM

All replies

  • Hi Oleg,

    This issue has already been reported:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=488341&wa=wsignin1.0

    and discussed:

    http://social.msdn.microsoft.com/Forums/en/codecontracts/thread/32f0f5c1-89fd-486f-9530-add3670552d0

    According to their response in the MS Connect report, the Code Analysis team is not going to fix this before the next full release of VS, not even in VS 2010 SP1.

    - Dave


    http://davesexton.com/blog
    • Proposed as answer by Dave Sexton Sunday, May 2, 2010 10:33 PM
    Sunday, May 2, 2010 10:29 PM
  • Hi Oleg,

    Hmm, I see from your example that you're not actually specifying any contract.  I was able to repro successfully, and I see that the argument check remained in the rewritten assembly untouched - so I guess this is a Code Analysis bug.

    - Dave


    http://davesexton.com/blog
    Sunday, May 2, 2010 10:43 PM
  • Well, the rule works fine when Code Contracts rewriter is disabled, which makes me think that Code Analysis is not the only guilty party here. Rewriter slightly modifies the IL. In particular, it replaces brtrue.s (short form) instruction with the brtrue (long form) instruction. Perhaps this is just enough to break the Code Analysis logic.

    I can't introduce code contracts in my project if it defeats Code Analysis; CA1062 is one of the most useful rules. I ended up disabling code contracts, and going to the old way of doing things.


    Oleg
    Monday, May 3, 2010 9:42 AM
  • The next release will fix some issues with 1062. There is blame on both CodeContracts and CodeAnalysis. If the rule passes with CodeAnalysis without the rewriter, then it should also pass with the rewriter, otherwise it is a CodeContracts problem.

    The issue with 1062 is that if you use your own helper method to validate a parameter, CA1062 will also still fire. The code produced by CodeContracts when using Requires or Requires<E> looks essentially like passing the parameter to another method for validation. So CodeAnalysis will need to be updated to handle this general pattern, not specific to CodeContracts.


    Cheers, -MaF (Manuel Fahndrich)
    Thursday, May 6, 2010 5:41 AM
  • When you say 'next release', did you mean 1.2 or 1.3? Or some other release?

    Because I've tried both and CA1062 is still firing incorrectly. I've tried different settings in the 'code contracts' tab under the project properties.

    Wednesday, June 2, 2010 8:04 AM
  • David,

    the 1.3 release fixes some issues described above. If the rule does not fire without running the rewriter, then it should not fire when you run with the rewriter either. If you have a repro that seems to show otherwise, I'd love to see it.

     

     

     


    Cheers, -MaF (Manuel Fahndrich)
    Thursday, June 3, 2010 12:09 AM
  • Guys I am seeing this also in the latest release (downloaded yesterday - 1.4.30601.2 showing in the project property form).

    I just have Perform Runtime Contract Checking Full, Perform Static Contract Checking Full, Check in background and I get these.

    Suddenly thought it might be the check-in background or order of rewrite/vs check - and I was ... wrong. It still happens when it is turned off

    Example for constructor:

     

     

     

    public ColumnJoin(string joinCondition)

    {

     

     

    Contract.Requires(joinCondition != null);

     

     

    ... stuff to build object

    }

    Warning 6 CA1062 : Microsoft.Design : In externally visible method 'ColumnJoin.ColumnJoin(string)', validate parameter 'joinCondition' before using it. C:\Users\bgerhardi\Documents\Development\Working Directories\Evolution\Vapour\EvoImportModelConnector\ScriptHelpers\ColumnJoin.cs 26 EvoImportModelConnector

     

    Although actually I am now not seeing any messages from code contract when turning off Check In Background.

    Turning off Perform Runtime contract checking (so I only have Perform Static) also shows no error messages (when I get them if I check in background)

    Friday, June 11, 2010 7:31 PM
  • Here's the question for you: if you turn off runtime contract checking and run code analysis, do you or do you not get CA1062 on ColumnJoin ?
    Cheers, -MaF (Manuel Fahndrich)
    Thursday, June 17, 2010 3:55 AM
  • There are 2 things here that I may have confused. In summary

    1. Static checking warnings don't appear if "check in background" isn't ticked. (regardless of runtime contract checking) - I can create a new item for this if you like as it is off-topic

    2. CA1062 Runtime warnings occur on the constructor above if - there is no if(blah==null) throw new ArgumentNullException("blah") AND:

    Contract.Requires(blah != null) exists
    and Runtime checking is off
    and Static checking is off

    Contract.Requires(blah != null) exists
    and Runtime checking is on
    and Static checking is off

    Contract.Requires(blah != null) exists
    and Runtime checking is on
    and Static checking is on (check in background)

    I tried also the 2 different assembly types and that didn't make any difference.

    I am running 64 bit OS in case that matters - it seems to affect a number of addin's.

    Thursday, June 24, 2010 8:57 AM
  • Sorry about that! Can you please send a (small!) self-contained repro to me?
    Sunday, August 1, 2010 10:12 PM
  • Sorry to necro such an old thread, but it is the same subject as discussed above.

     

    Was this issue ever fixed?

     

    I ask because Code Contracts in the Visual Studio 11 Preview is still showing this as an issue.  Let me know if you need additional details.

    Tuesday, September 20, 2011 9:25 PM
  • Hasn't been fixed AFAIK. It's 3 years after being originally reported, and I'm still getting this error with contract validation in VS2012 Update 2 with Code Contracts v1.5.60502.11

    Wednesday, June 26, 2013 8:23 PM