We Keep Coding

How does "Contract.Requires<T>" behave without ccrewrite? Does this differ from "Requires"?

When not using ccrewrite (say the project is built by another developer without CC installed),
Is Contract.Requires<T>(cond) silently stripped or does it still result in behavior equivalent to if (!cond) { throw new T() }? (I don't care if it's another method call or two - but it should "always be checked".)
I ask because Contract.Requires<T> appears to behave differently than Contract.Requires, but I'm not sure "how" or "when".
The goal is to replace the construct on public contracts
if (x != null) throw new ArgumentNullException();
with a CC-compatible version that will still throw an exception when not performing a CC rewrite during the build step.
While the above with EndContractBlock does work with "Custom Parameter Validation" (ie. legacy contract mode) I would like to use "Standard Contract Requires" in the project.
I believe there may be an equivalency, because in "Custom Parameter Validation" mode I am not able to use Requires<T>; if there is no equivalency to an always-required-check, insight as to why would be nice.
I am fine losing Requires, Ensures, and leaving in the non-honored invariant contract methods and interface contracts when CC rewriting is not done as I value them for the static analysis - but I need these always-there boundary checks to argue for keeping CC.

Please see the Code Contracts manual. It definitely tells you all you need to know about how the various forms of Code Contract checking works and what options are required to be set when using each form.
What's the Difference Between Contract.Requires(bool cond) and Contract.Requires<TException>(bool cond)?
To answer your first question, see section 2.1 Preconditions in the manual. Briefly, here is the difference:
Contract.Requires(bool cond)
This will throw a private Contract.ContractException exception if the condition evaluates to false. You cannot catch this exception (since it's private from your point of view)—this is to discourage catching and handling it, thereby making the contracts pretty much worthless.
Contract.Requires<TException>(bool cond)
If the condition evaluates to false, the specified TException will be thrown. You cannot use this form without running the contract tools on all builds.
About ccrewrite
Specifically, on page 20, in section 5. Usage Guidelines, it tells you all the different forms of contracts that Code Contracts can work with, how they work, and what the build requirements for each are.
I'll briefly summarize, but please, download the manual and read it. It's quite good, though not in any way complete—you have to do a lot of experimentation to learn how to effectively use Code Contracts. Also, if you have access to PluralSight, John Sonmez has a course called Code Contracts which is a great introductory course; and Michael Perry has an awesome course called Provable Code.
Contract Checking Is Not Required for Released Code
If you don't need contract checking in released code, then:
Use Contract.Requires everywhere
Enable Runtime Checking on Debug builds only.
Code Contract Checking is Required for Released Code
If you require contract checking on released code, you have two options:
Use Code Contracts "native" pre-conditions:
Use Contract.Requires<TException> on public API methods (e.g. methods that will be called by users of your library) for which you want to throw specific exceptions, e.g. ArgumentException.
Use Contract.Requires For non-public API methods or public API methods for which you don't want to throw a specific exception.
Enable Runtime Checking on all builds.
Ensure you enable options to only emit pre-conditions and only on public surface area of your assembly—e.g. only those methods that are callable by your library consumers.
Use "legacy" contract checking:
This is your old school style if (cond) { throw new Exception(...) } guard blocks on your public API methods
Use manual inheritance to enforce contracts on derived types. (When using option 1, Code Contracts can perform automatic inheritance of contracts from base classes, helping you avoid Liskov Substitution Principle violations.)
Make sure to place the line Contracts.EndContractBlock() after all your if (cond) { throw new Exception(...) } blocks so that Code Contracts knows these are your contracts.
On non-public API methods, you can feel free to use Contract.Requires for your contracts.
Enable Runtime Checking only on Debug builds.
One thing to note about the above: Contract checking is always enabled on Debug builds. If other developers on your team will be building this library, they will also need to have Code Contracts installed.
From Section 5.1.3: Forcing Projects to build with Contracts:
If you are using scenario 2 (Requires〈Exn〉) and you make your source code available to other developers, you might want to alert them that they need to use the tools to build your source. If so, you can insert the following snippet into your project file at the end (after the import of CSharp or VisualBasic targets):
<PropertyGroup>
<CompileDependsOn>$(CompileDependsOn);CheckForCodeContracts</CompileDependsOn>
</PropertyGroup>
<Target Name="CheckForCodeContracts"
Condition="'$(CodeContractsImported)' != 'true'">
<Error Text="Project requires Code Contracts: http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx" />
</Target>
Also, see Section 6.1: Assembly Mode where it tells you the difference between Custom Parameter Validation and Standard Contract Requires. This section makes it quite clear that the contract rewriter (ccrewrite) is always run on Debug builds.

Code Contract or if statement?

I just tried to use Code Contracts, and I see no real advantages over an if statement.
Consider the following.
private static void BindClassesToInterfacesByConvention(string classesEndingWith
, string interfacesEndingwith) {
Contract.Requires<ArgumentNullexception>(
string.IsNullOrWhiteSpace(classesEndingWith)
, "classesEndingWith");
Contract.Requires<ArgumentNullException>(
string.IsNullOrWhitespace(interfacesEndingWith)
, "interfacesendingWith");
...
}
I find it way more confusing than simply using an if statement
private static void BindClassesToInterfacesByConvention(string classesEndingWith
, string interfacesEndingwith) {
if (string.IsNullOrWhiteSpace(classesEndingWith))
throw new ArgumentNullException("classesEndingWith");
if (string.IsNullOrWhitespace(interfacesEndingWith))
throw new ArgumentNullException("interfacesendingWith");
...
}
Code Contracts are supposed to warn me at compile time that a a contract is violated. So, I was expecting to get an error or a warning when I have written the following.
BindClassesToInterfacesByConvention(null, null);
And nothing happened, everything compiled just fine, and neither an error nor a warning message appeared.
In this scenario, I believe it is best to continue with the it statement. Or perhaps was it an unfair use of Code Contracts?

Code Contracts are a great idea let down by tooling that isn't quite there.
Firstly, in order to make the exceptions actually throw, you have to install the right extensions in Visual Studio and/or configure the correct settings on your project. Great fun if you have unit tests relying on the code contracts throwing exceptions at runtime and run them on a build server.
However, it is important to understand that the real purpose of Code Contracts isn't just to throw exceptions. It enables static code analysis (if you switch it on), which when enabled may be able to give you an error at compile time - but it does require you to do a lot of work to apply it pretty much everywhere in order for the static code analysis to really work. I believe that is the scenario you are trying to test? In which case I suggest you look at the code contracts setting for your project to make sure you have enabled all the static code checking (it will make your build rather long).
Furthermore and importantly, the code contracts allows you to communicate intent to the callers of your methods; Intellisense will pick up on the conditions you have specified (provided you install the correct extensions). The informatation about the code contracts can also automatically be added to the XML file that can accompany assemblies, which will then enable 3rd party users of your assembly to know about your requirements when they write their code, as well as allowing you to include this information in helpfiles built with Sandcastle etc.
It's a great idea, just not really fully implemented in the tools yet so you get some funny behavior once in a while. Personally I have pretty much stopped using them for the time being.

You are specifying a method that requires its arguments to be null or whitespace, then passing null. The contract is satisfied. That's why you got no contract violation. (Requires() requires throws the exception when the condition evaluates to false, not to true.)
Furthermore, even if you correct the contract, you shouldn't be throwing ArgumentNullException if the parameter value is a non-null string containing no characters or only whitespace characters. In that case you should throw an ArgumentException.
I would do this:
private static void BindClassesToInterfacesByConvention(string classesEndingWith
, string interfacesEndingwith) {
Contract.Requires<ArgumentNullException>(classesEndingWith != null
, "classesEndingWith");
Contract.Requires<ArgumentException>(!string.IsNullOrWhiteSpace(classesEndingWith)
, "classesEndingWith");
Contract.Requires<ArgumentNullException>(interfacesEndingWith != null
, "interfacesEndingWith");
Contract.Requires<ArgumentException>(!string.IsNullOrWhiteSpace(interfacesEndingWith)
, "interfacesEndingWith");
...
}
To download the Code Contracts analysis tools, including Visual Studio integration, visit http://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970

This is a subjective answer, but I would say the real statement here is: "I just tried to use Code Contracts, and I see no real advantages over a Unit Test"
For Example:
private void Foo(string something)
{
Contract.Requires<ArgumentNullException>(something != null, "something");
}
is equivalent as (NUnit testing):
void Foo(string something)
{
if (something == null)
throw new ArgumentNullException();
}
[Test]
[ExpectedException( typeof( ArgumentNullException ) )]
void foo_throws_exception_with_null_param()
{
Foo(null);
}
Which is better? Well from my (limited) experience the static analysis addon for VS is quite slow. If you have done a call to foo with an explicit null'ed variable then it'll pick it up. But it won't pick up nulls loaded dynamically and send to foo during user iteraction.
On the other hand, if you have an if-statement and a unit test to ensure it WILL throw an ArgumentNullException then you know that the exception is going to be thrown; and you can deal with it in the run-time environment... you can test anything that uses Foo to make sure it handles the exception.
Ensuring that explicit check is very fast with NUnit. The downside of unit testing is setting up the tests to begin with. So my opinion is that over time you'll save more time by being explicit, making unit tests and ensuring your application can handle if those exceptions are thrown... it'll just cost you more to begin with to set it up.

Yes, Code Contracts will warn you at compile time that a a contract is violated if you enable the static checking.It proved the Code Contract add-ons(Code Contracts for .NET)only works on Visual Studio 2013 or lower versions, but not Visual Studio 2015 or 2017.
On Visual Studio 2013:
On Visual Studio 2015, we can see the error information from Output window, but not in Error List window. This bug was already logged and fixed, but it can still be repro.Warnings and messages from static contract checking don't appear in the VS2015 error list
Latest update:
Install the latest Contracts.devlab9ts.msi(Currently, it's just RC version) will resolve the issue in Visual Studio 2015.
DotNet CodeContracts v.1.10.20606.1-rc2

How is compiler dealing with these Generic Plugin Interface instance methods?

I'm working with some, unfortunately largely undocumented, existing code and I'm having trouble understanding how it calls upon the methods of the plugins it loads.
My aim at the moment is simply to step into one of the methods loaded via the plugin manager, as it's causing an exception. However I had to rebuild the pluginManager from the source to get debug symbols and when I reference this new DLL version the compiler throws up arms.
The code appears to load the plugin into plug.Instance and then access the specific methods like so plug.Instance.ReturnLeaNumber();
This compiler error makes sense, because it doesn't know the details of the plugins. What confuses me is how the compiler ever knew these where valid before run time, when no plugins are initialized. I can step through the code that doesn't work now with the older DLL!
This is an example of where the program loads up a plugin.
plug = GenericServicePlugins.AvailablePlugins.Find(Application.StartupPath + "\\Dlls\\SchoolInterface.dll");
// Compiler doesn't like this next line anymore though
plug.Instance.Initialize(null, null);
If there are any differences between my rebuilt library and the previously working one, I can't tell how as the versions match up with the ones in our source control. Would appreciate some advice on where to start looking!
public interface IGenericPluginMasterInterface
{
String returnName();
void Initialize(ExceptionStringResources.Translate ExceptionStrings);
Object ExecuteFunction(String macAddress, bool log, String functionName, LoginCredentials logonCredentials, WebConfiguration webConfig,
Int64 dataLinkId, DataLinkParam[] dataLinkParams, String dataName,
DataParam[] dataParams, Object[] additionalParams);
}
Rest of Manager code on PasteBin
How does the compiler know about these plug.Instance.Method() methods before runtime?
Edit:
I've not quite worked this out yet, but there was a "PluginsService" file I missed which partly mirrors the "GenericPluginServices".
I think this error could have been caused when I removed parts of this class that related to an now defunct plugin, which I am looking into. However I figured posting this other code snippet would help the question.
PluginService.cs code
GenericPluginService code

Find returns AvailablePlugin, so .Instance is of type IGenericPluginMasterInterface; if so, indeed; that .Instance.ReturnLeaNumber() can't possibly work...
The only way that could work (without introducing some generics etc) is if .Instance actually returned dynamic. With dynamic the name/method resolution is happening at runtime. The compiler treats dynamic very deliberately such as to defer all resolution to runtime, based on either reflection (for simple cases) or IDynamicMetaObjectProvider (for more sohpisticated cases).
However, if the code you have doesn't match what was compiled, then: we can't tell you what it was. IMO, the best option is to get hold of the working dll, and look at it in reflector to see what it is actually doing, and how it is different to the source code that you have.
Actually, strictly speaking it could still do that with the code you've pasted, but only if plug is typed as dynamic, i.e. dynamic plug = ...

Pros/cons of different methods for testing preconditions?

Off the top of my head, I can think of 4 ways to check for null arguments:
Debug.Assert(context != null);
Contract.Assert(context != null);
Contract.Requires(context != null);
if (context == null) throw new ArgumentNullException("context");
I've always used the last method, but I just saw a code snippet that used Contract.Requires, which I'm unfamiliar with. What are the advantages/disadvantages of each method? Are there other ways?
In VS2010 w/ Resharper,
Contract.Assert warns me that the expression is always true (how it knows, I'm not quite sure... can't HttpContext be null?),
Contract.Requires gets faded out and it tells me the compiler won't invoke the method (I assume because of the former reason, it will never be null), and
if I change the last method to context != null all the code following gets faded out and it tells me the code is heuristically unreachable.
So, it seems the last 3 methods have some kind of intelligence built into the VS static checker, and Debug.Assert is just dumb.

My guess is that there is a contract applied to the interface IHttpHandler.ProcessRequest which requires that context != null. Interface contracts are inherited by their implementers, so you don't need to repeat the Requires. In fact, you are not allowed to add additional Requires statements, as you are limited to the requirements associated with the interface contract.
I think it's important to make a distinction between specifying a contractual obligation vs. simply performing a null check. You can implement a null check and throw an exception at runtime, as a way to inform the developer that they are using your API correctly. A Contract expression, on the other hand, is really a form of metadata, which can be interpreted by the contract rewriter (to introduce the runtime exceptions that were previously implemented manually), but also by the static analyzer, which can use them to reason about the static correctness of your application.
That said, if you're working in an environment where you're actively using Code Contracts and static analysis, then it's definitely preferable to put the assertions in Contract form, to take advantage of the static analysis. Even if you're not using the static analysis, you can still leave the door open for later benefits by using contracts. The main thing to watch out for is whether you've configured your projects to perform the rewriting, as otherwise the contracts will not result in runtime exceptions as you might expect.
To elaborate on what the commenters have said, the difference between Assert, Assume and Requires is:
A Contract.Assert expression is transformed into an assertion by the contract rewriter and the static analyzer attempts to prove the expression based on its existing evidence. If it can't be proven, you'll get a static analysis warning.
A Contract.Assume expression is ignored by the contract rewriter (as far as I know), but is interpreted by the static analyzer as a new piece of evidence it can take into account in its static analysis. Contract.Assume is used to 'fill the gaps' in the static analysis, either where it lacks the sophistication to make the necessary inferences or when inter-operating with code that has not been decorated with Contracts, so that you can Assume, for instance, that a particular function call returns a non-null result.
Contract.Requires are conditions that must always be true when your method is called. They can be constraints on parameters to the method (which are the most typical) and they may also be constraints on publicly visible states of the object (For instance, you might only allow the method to be called if Initialized is True.) These kinds of constraints push the users of your class to either check Initialized when using the object (and presumably handle the error appropriately if it's not) or create their own constraints and/or class invariants to clarify that Initialization has, indeed, happened.

The first method is appropriate for testing for a null condition that should never exist. That is, use it during development to ensure it doesn't unexpectedly get set to null. Since it doesn't do any error handling, this is not appropriate for handling null conditions in your released product.
I would say the 2nd and 3rd versions are similar in that they don't handle the issue in any way.
In general, if there's a possibility that the variable could actually be null in the final product, the last version is the one to use. You could do special handling there, or just raise an exception as you've done.

Justification for Reflection in C#

I have wondered about the appropriateness of reflection in C# code. For example I have written a function which iterates through the properties of a given source object and creates a new instance of a specified type, then copies the values of properties with the same name from one to the other. I created this to copy data from one auto-generated LINQ object to another in order to get around the lack of inheritance from multiple tables in LINQ.
However, I can't help but think code like this is really 'cheating', i.e. rather than using using the provided language constructs to achieve a given end it allows you to circumvent them.
To what degree is this sort of code acceptable? What are the risks? What are legitimate uses of this approach?

Sometimes using reflection can be a bit of a hack, but a lot of the time it's simply the most fantastic code tool.
Look at the .Net property grid - anyone who's used Visual Studio will be familiar with it. You can point it at any object and it it will produce a simple property editor. That uses reflection, in fact most of VS's toolbox does.
Look at unit tests - they're loaded by reflection (at least in NUnit and MSTest).
Reflection allows dynamic-style behaviour from static languages.
The one thing it really needs is duck typing - the C# compiler already supports this: you can foreach anything that looks like IEnumerable, whether it implements the interface or not. You can use the C#3 collection syntax on any class that has a method called Add.
Use reflection wherever you need dynamic-style behaviour - for instance you have a collection of objects and you want to check the same property on each.
The risks are similar for dynamic types - compile time exceptions become run time ones. You code is not as 'safe' and you have to react accordingly.
The .Net reflection code is very quick, but not as fast as the explicit call would have been.

I agree, it gives me the it works but it feels like a hack feeling. I try to avoid reflection whenever possible. I have been burned many times after refactoring code which had reflection in it. Code compiles fine, tests even run, but under special circumstances (which the tests didn't cover) the program blows up run-time because of my refactoring in one of the objects the reflection code poked into.
Example 1: Reflection in OR mapper, you change the name or the type of the property in your object model: Blows up run-time.
Example 2: You are in a SOA shop. Web Services are complete decoupled (or so you think). They have their own set of generated proxy classes, but in the mapping you decide to save some time and you do this:
ExternalColor c = (ExternalColor)Enum.Parse(typeof(ExternalColor),
internalColor.ToString());
Under the covers this is also reflection but done by the .net framework itself. Now what happens if you decide to rename InternalColor.Grey to InternalColor.Gray? Everything looks ok, it builds fine, and even runs fine.. until the day some stupid user decides to use the color Gray... at which point the mapper will blow up.

Reflection is a wonderful tool that I could not live without. It can make programming much easier and faster.
For instance, I use reflection in my ORM layer to be able to assign properties with column values from tables. If it wasn't for reflection I have had to create a copy class for each table/class mapping.
As for the external color exception above. The problem is not Enum.Parse, but that the coder didnt not catch the proper exception. Since a string is parsed, the coder should always assume that the string can contain an incorrect value.
The same problem applies to all advanced programming in .Net. "With great power, comes great responsibility". Using reflection gives you much power. But make sure that you know how to use it properly. There are dozens of examples on the web.

It may be just me, but the way I'd get into this is by creating a code generator - using reflection at runtime is a bit costly and untyped. Creating classes that would get generated according to your latest code and copy everything in a strongly typed manner would mean that you will catch these errors at build-time.
For instance, a generated class may look like this:
static class AtoBCopier
{
public static B Copy(A item)
{
return new B() { Prop1 = item.Prop1, Prop2 = item.Prop2 };
}
}
If either class doesn't have the properties or their types change, the code doesn't compile. Plus, there's a huge improvement in times.

I recently used reflection in C# for finding implementations of a specific interface. I had written a simple batch-style interpreter that looked up "actions" for each step of the computation based on the class name. Reflecting the current namespace then pops up the right implementation of my IStep inteface that can be Execute()ed. This way, adding new "actions" is as easy as creating a new derived class - no need to add it to a registry, or even worse: forgetting to add it to a registry...

Reflection makes it very easy to implement plugin architectures where plugin DLLs are automatically loaded at runtime (not explicitly linked at compile time).
These can be scanned for classes that implement/extend relevant interfaces/classes. Reflection can then be used to instantiate instances of these on demand.