For the last few months I\'ve been developing a side project for my company, but the higher-ups have now decided it would be a good fit in an existing product.
I\'ve
The short answer is: Yes. If you check in the code with Code Contracts, then all developers that might build that code must also have Code Contracts installed in order to build the code.
In contradiction to what @CBauer wrote in his answer, there is a "blessed" package for Code Contracts. No, it's not a NuGet package—it's an MSI installer based installation.
Finally, if you are in a Continuous Integration environment for debug builds (e.g. Development, QA/QC and/or Testing), then those build servers will also need to have Code Contracts installed.
When you use Code Contracts, Debug builds always require the use of Code Contracts. Please note that this is not necessarily the case for Release builds. It depends on what form of contract checking you're using and the options specified in the Project Properties.
The Code Contracts manual has all the details. It's quite good and I highly recommend taking the time to read and understand it.
It should be noted that if you use the Contract.Requires<TException>(bool condition)
form of preconditions, you must have Code Contracts enabled for Release builds (see Section 5: Usage Guidelines, specifically, page 20, Usage 2 scenario).
Since you are integrating this code into an existing codebase that has not been developed with Code Contracts, you should consider revising your Code Contracts Project Property settings to conform to Usage Scenario 3 outlined on page 20 of the Code Contracts manual, and reformulate your contracts using the "legacy" if-then-throw pattern. This will enable your team to best tranisition the code base to using Code Contracts everywhere, allowing you to eventually replace "legacy" if-then-throw precondition checks with actual Code Contracts Contract.Requires(bool condition)
checks, and if you like, Contract.Requires<TException>(bool condition)
checks.
UPDATE: There Will Soon Be A NuGet Package For Code Contracts I was at the new GitHub repository for Code Contracts today. For those of you who don't know, Microsoft has open-sourced this and it is now a community-driven effort.
They recently (back in January) announced v1.10.xxxx.RC1 release. You can find information about it here on their GitHub repository.
Unfortunately it's difficult to keep a library that is not installed via nuget up to date without forcing your coworkers to maintain their personal environment. Code contracts does not appear to have an official Microsoft-blessed package out there for use.
fourpastmidnight's post below has a recently updated answer to my original concern above, but the bottom half I think remains relevant even now. Get your buy-in, people!
In my (admittedly subjective) experience, tools like this come to be reviled if buy-in is not established among coworkers in advance. You might try broaching the subject slowly to see if they would be receptive to using it.
Contract.Requires<TException>()
will fail if the code contracts rewriter is not installed, regardless of setting CONTRACTS_FULL
or not.
One solution is to build a separate class FailableContract
which tests the preprocessor condition CONTRACTS_FULL
, which is set by Code Contracts.
Then all you have to do is remember to remove CONTRACTS_FULL
from your build parameters before committing your code to the code base. You still get code contracts, everybody else gets guard statements.
A small portion of FailableContract
(which I'm still writing):
public class FailableContract
{
public static void Requires(bool condition)
{
#if CONTRACTS_FULL
Contract.Requires(condition);
#else
if (!condition) throw new ArgumentException(); //Just go with an argument exception because we haven't been supplied with an exception type.
#endif
}
public static void Requires<TException>(bool condition) where TException : Exception, new()
{
#if CONTRACTS_FULL
Contract.Requires<TException>(condition);
#else
if (!condition) throw new TException();
#endif
}
}
Then a simple Find, Replace Contract.
to FailableContract.
should get most issues.