My Solution/Project builds fine with code contracts turned off for this particular project.
When I turn on Perform Runtime Contract Checking on my project, the build fails. The CC rewriter starts to kick up hundreds of messages along the lines of:
Could not resolve member reference: ....
It seems this problem is caused by the order of the project references passed to ccrewrite via the libpaths
argument. When I pull the build apart, and run it on the command line, and I manually specify the references in a specific order to libpaths, ccrewrite works, and the build completes.
eg
ccrewrite /level:4 /rewrite "/assemblyMode=standard" /throwonfailure /libpaths:"X Y Z" "target.dll" -- fails :(
ccrewrite /level:4 /rewrite "/assemblyMode=standard" /throwonfailure /libpaths:"Z Y X" "target.dll" -- compiles/rewrites :)
This seems a little odd to me, I'd have thought ccrewrite should be able to handle an arbitrary ordering, especially since the provided 'broken' ordering is the one msbuild is passing along to the Microsoft.CodeContracts.targets file / ccrewrite, but thats an issue for the CC guys. I've also tested this on 3 different machines, with the same result, so its either a ccrewrite issue, or something odd in this specific csproj that ccrewrite doesnt like.
What I'm wondering is, can I ensure the specific ordering of my reference projects, that get passed along the chain to the CC targets file? I would have assumed that the build engine would use the order it reads in the project csproj file, under ItemGroup//ProjectReference
elements, but its not the case.
Any ideas?
This was an identified error in the tool, and has been resolved in the latest release, v1.4.31130.0 2010-11-30.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With