This project is read-only.


Sep 4, 2010 at 2:37 AM


I'm starting a project where I need to develop an assembly rewriter, similar to the one used in CodeContracts. I need the same CCI features as CodeContracts rewriter uses:

  1. Decompile an assembly
    1. Read .pdb file to load source code locations for method statements
  2. Transform it using a CodeMutator
  3. Write it back to an assembly

I wonder whether CCI can be used for this purpose? Is it stable enough? What are status of the features above? Maybe there is a stable version? As far as I know CodeContracts uses CCI, but I wonder which version it uses. I tried the latest version, but it seemed to not provide some line numbers in some cases (I can send you a sample to reproduce the bug). 

There was a question about when you are going to ship a stable version, but nobody answered. Did plans change since that time?


Sep 4, 2010 at 12:56 PM

The current version of the CodeContracts rewriter uses an earlier version of CCI and suffers from some limititations. We are (slowly) woking towards porting the rewriter to CCI2 but are not there yet and do not know when we'll be done.

If you can provide samples to reproduce the bugs that you are seeing, it would help us a lot.

Sep 5, 2010 at 5:58 AM
hermanv wrote:

do not know when we'll be done.

OK, could you please confirm that this project will reach a stable state eventually? As far as I understand it has to, because such projects as CodeContracts depend on it.

CCI perfectly suits my needs because it has some advanced .NET decompilation features, for example support for anonymous delegates, but so far I'm afraid of relying on it because the development and the discussion don't look very active. I have an alternative, Cecil, which is stable, has a lot of serious users, but it does not have the decompilation.

Could you please tell me whether there are plans to publish a stable version eventually?

(if I use CCI, I will report bugs and probably make patches :))

Sep 5, 2010 at 1:27 PM

CCI has has some serious users inside Microsoft. The lower level parts (i.e. the stuff that corresponds to Cecil) are quite stable. And as you observe, to get CodeContracts to the state where we would like it to be, we need to finish the decompiler.

I'd like to think that is only six months out, but I would have told you the same thing twelve months ago. :-(

If you cannot do without decompilation, you either have to get a decompiler going on Cecil, or you can help out with the CCI decompiler.

Feb 12, 2011 at 5:26 PM

Hi again,

So, can you tell the community how the project feels now after 5 months are past? 

As for me, I'm primarily interested in decompilation and compilation, both with the support of anonymous methods (+closures).


Feb 12, 2011 at 5:43 PM

After a long diversion with other projects, I'm now working full time on CCI, at least for a while.

I have also just spent a few weeks chasing up bugs and rewriting the more shaky parts of the decompiler. Also, it is now optional to decompile iterators, which is the one area that still needs much more work. We are now at the stage where a simple round-trip via the decompiler (sans iterators) can be applied to all of the assemblies in the core part of the .NET framework. In the next few weeks we hope actually put the rewritten assemblies through their full test suites, which should flush out some more bugs, I'm sure.

The CodeContracts rewriter has now been ported onto CCI (it used an earlier version) and passes all of its tests. However, it still depends on iterator decompilation and will be adapted soon to deal with contracts in compile iterators rather than decompiled iterators.

As of yesterday's check in, I suspect that you'll have a reasonable experience with the decompiler and I would appreciate some additional testing and bug feedback.

Feb 13, 2011 at 12:43 PM
Edited Feb 13, 2011 at 3:00 PM

Great news, really! Thank you for your reply.

I don't need the iterators either, so it is OK for me.

I suppose the compilation is near to stable, since you said nothing about it and it is easier than decompilation (except closures, maybe).

P.S. Bug reports are on the go.

Feb 13, 2011 at 9:32 PM

Compilation of closures should mostly work. The major missing piece is that anonymous delegates that do NOT close over any method state are still compiled as actual closures and are allocated a new for every invocation of the method that contains them. Clearly, the C# scheme of allocating these delegates only once per execution, using static fields and lazy initialization is the only way to go. But for now, you should not notice except for performance or in the unlikely case where you depend on such delegates having a stable object identity.