This project is read-only.

Appropriate way to reference CCI source in open source projects

Topics: Metadata Model
Apr 8, 2011 at 4:51 PM

I have just published a first version of Afterthought, an open source library that leverages CCI Metadata to provide post-compilation assembly manipulation similar to (but easier than) PostSharp.  My goal is not to do everything PostSharp does, but to instead hit the most important points and provide a free open source alternative.  

Having said this, I released the source on GitHub ( and was wondering what the appropriate process was to include the CCI libraries.  Currently, I am including copies of these on GitHub to ensure that someone pulling these down can actually get them working.  Also, I included the MS-PL license in compliance with the redistribution and am using the same license for Afterthought.

Please let me know if this approach is acceptable or if you have recommendations for alternative approaches.  I do not want to simply include the binaries, because it is almost impossible to debug CCI without the source code.



Apr 12, 2011 at 1:28 AM

I am afraid that I do not know enough about GIT to make any recommendations. With SVN (and apparently with Mercurial also) it is easy enough to just link to the original CodePlex repository, which seems like a good way to do things unless you actually want to control when you want to pick up changes in the original repository.

Sep 27, 2011 at 6:20 PM

I've created a shallow-fork for CCI-AST (and obviously CCI-METADATA) at that builds the whole thing as a single assembly. It won't be long until I publish a signed, strong-named binary there too, so you can pick that up if you'd rather not do the work yourself.

I'm using it already for our project.

Sep 28, 2011 at 3:03 PM

@fearthecowboy, thanks for the merge.  I was able to copy this directly into Afterthought and eliminate the overload of dll dependencies.  Since Afterthought is a tool used during the build process it helps to have a smaller footprint.  I had been using resource assembly embedding, but this only worked when running as an executable, not when using the MSBuild task.  Because I am subclassing ILGenerator (which is sealed) I had to copy the source and will continue to periodically pull from your fork.  Just out of curiosity, how many changes did you have to make to the source code to eliminate the file version conflicts since the same classes existed in slightly different variants across the metadata projects?

Sep 28, 2011 at 8:01 PM

There were only a few changes; but I reported them here ( ) and they fixed em! :)

So, now my fork is pretty much exactly the code that's in the cci-ast project, just one big assembly :)


Feb 27, 2012 at 10:44 AM

I Have a similar problem: My project also uses the CCI. My first question is: Is it allowed to check in the referenced CCI assemblies into the project repository? I want to ensure that only a specific version of cci is used. Secondly: When I publish my software, Codeplex does not allow to extend the license conditions, so there is no proper way to referece to your license conditions. What is an acceptable approch to keep my project compliant to your license?

Feb 27, 2012 at 3:41 PM

I have no idea of what a "proper way" would look like, but it seems to me that it should be OK to check in binaries that you've built from other projects. As for "retaining the license", I'd include the file with the license in the same directory as the one containing the "external" binaries. When you distribute built binaries of your project, along with the external binaries, I'd include the license for external binaries along with your own license, probably accompanied by a text file that explains which binaries are covered by which license.