Address code analysis warnings

[adamralph]

The core FakeItEasy project has 74 warnings. Other projects may also have further warnings.

In each case we should fix the code or suppress the warning, whichever is appropriate.

We should also consider our policy for running code analysis as part of the build. The issue here is speed. Code analysis can really slow the build down. If we do choose to run code analysis as part of the build, it should fail when there are warnings, as mentioned by @philippdolder (#36 (comment)).

• switch to FakeItEasy ruleset
• address warnings
• switch all warnings to errors
• switch on analysis for all release builds (if desired)

[adamralph]

Currently held up by this http://stackoverflow.com/questions/16119178/false-positive-for-ca1801-in-release-config-only

[adamralph]

Managed to answer my own SO question ;-). Now I have to decide how to resolve the warnings.

[adamralph]

@FakeItEasy/owners does anyone know why the obsolete Configure.Fake<TFake>() has been left in the net35 and SL projects but is not in the net40 project?

I'm getting a code analysis warning because the Obsolete attribute does not have a message. I'm wondering if I can just remove the type altogether. This would be a breaking change but I'd be reluctant to increment the version to 2.0 just for this. Alternatively I can just add a message. Something the following?

Use A.Fake<T>() and A.CallTo() instead.

[adamralph]

I did some metrics to gauge build times with code analysis switched on vs off.

Type	On	Off
Rake build (inc. version and clean)	37s	20s
VS Rebuild	15s	8s

I think we should leave code analysis switched off for Debug builds (which is what we do most of the time in VS). But switch it on for Release builds (rake).