How will using Code Contracts in my web project affect deployment?

Question

If code contracts are used in an application then do we need to install anything (from Code Contracts package) on production server like putting assemblies into GAC or running code contracts installation package on production server?

Or just putting libraries in bin folder will work?

Answer 1

It should be enough to put them in the bin/ folder.

Did something like this a few weeks ago, i'd downloaded a trial for a charting engine, put the .dlls in my lib folder and added a reference to them in my web-project.

We used to use the "Publish" option in Visual Studio when we deployed a website so we got a nice, clean build to upload (now we have a build-server).

This all worked perfectly until we decided to buy the component, I installed it, and added all the assemblies we're moved/installed to the GAC. I took the assemblies and put them in our lib folder and re-added the references.

Everything we're working fine until we decided to publish an update to the project with the new chart-engine assemblies. The site stopped working! :(

After a short time of debugging we found that the error was the new .dlls for the chart-engines weren't outputed to the bin folder since they were in the GAC. But when we published to our server they're aren't there, so to fix the problem we just copied them over and everything worked like a charm again.

Answer 2

From the Code Contracts site linked in your question:

Contracts act as checked documentation of your external and internal APIs. The contracts are used to improve testing via runtime checking, enable static contract verification, and documentation generation.

Correct me if I'm wrong, but I think that code contracts are designed as a development-time aid only. Therefore, it is supposed that you will disable them when you compile the asemblies intended for deployment/production.

Answer 3

I realize this is an older thread but the question is still a valid one...

Assuming the use of .NET 4.0, the System.Diagnostics.Contract classes are already included in mscorlib.dll. So all you'll need to have installed anywhere is the .NET 4.0 runtime.

You'll only need to have the CodeContracts package installed to the dev machines and any other machines that compile your binaries down to IL (i.e. via VisualStudio, msbuild using csc.exe - the C# compiler, etc.). There is are several .exes included in that install package. One of them is 'ccrewrite.exe'. This is an IL rewriter that injects IL code into your assemblies after the compiler has completed. Note that ccrewrite and the .NET compiler you use for whatever language you are using are not related, connected, or share any dependencies.

Once your binaries are compiled, there is no need to install or deploy anything to any of the servers where your code will execute. This is true regardless of the options you have configured in your Project Settings:

• using Runtime Contract checking
• using Static Contract Checking
• configured to build the CodeContract Reference Assemblies (you don't need to deploy these either).
• etc.

The CodeContract Reference Assemblies are only used when you need to expose your contracts to a Library/API that is outside of your Solution and Static Checking is enabled for that project. You also should not directly reference them nor do you need any kind of post-build step to copy them into any bin folder (except in the case I just mentioned about exposing them to another Library/API).

HTH