ccrewrite exited with code 1

[rkeithhill]

I have only turned on runtime checking with only "Perform Runtime Contract Checking" checked and set the dropdown to "Preconditions". I'm on 1.9.10714.2 and am running VS 2015.

Is there a upcoming release to fix this issue and the bogus update issue? VS 2015 thinks I need to update from 1.8.10107.10 to 1.9.10714.2 when I already have the latter installed.

[SergeyTeplyakov]

Issue with update was fixed and would be released soon, but for the first issue we need more details to understand why ccrewrite exited with code 1? Maybe a repro example... Otherwise we can't fix the issue...

[petergummer]

Hi, I’m not Keith, but yesterday I was struggling with ccrewrite exiting with code -1. Same version of Code Contracts but in VS 2013.

In the Output window I found the error code MSB3073. I turned on verbose build output and as far as I could figure out it’s because it couldn't find ShDocVw.dll, which a third-party library apparently depends upon. I don’t know why ccrewrite would need to inspect an interop assembly used by a third-party assembly.

I couldn’t figure out how to work around the problem, so I’ve turned off runtime contract checking for now. Is there a known workaround? This kind of situation must be very common.

Regards, Peter Gummer

On 4 Sep 2015, at 02:32, Sergey Teplyakov notifications@github.com wrote:

Issue with update was fixed and would be released soon, but for the first issue we need more details to understand why ccrewrite exited with code 1? Maybe a repro example... Otherwise we can't fix the issue...

[rkeithhill]

Nevermind. I looked at the output and it was a bad contract on my part. I was doing a requires in a public method that was checking a private field.

[SergeyTeplyakov]

@rkeithhill That's fine:) Feel free to open bugs for any features you'll face! Feedback is greatly appreciated.

[SergeyTeplyakov]

@petergummer from my understanding "transitive closure" is required because contracts are transitive as well. There are some ideas how to avoid this (or at least to reduce such impact) but they're in the future.

Feel free to open separate bug, because I would like to close this one...

[petergummer]

Hi Sergey,

I wasn’t really trying to report a bug, since I was vaguely aware that this “transitive closure” was necessary. I was just seeking advice on a workaround.

Maybe I’m asking in the wrong place?

Regards, Peter

On 4 Sep 2015, at 13:43, Sergey Teplyakov notifications@github.com wrote:

@petergummer https://github.com/petergummer from my understanding "transitive closure" is required because contracts are transitive as well. There are some ideas how to avoid this (or at least to reduce such impact) but they're in the future.

Feel free to open separate bug, because I would like to close this one...

[SergeyTeplyakov]

Hi Peter,

I think this is a right place to ask. Inviting @mike-barnett, as an original author, maybe he can point out to the workaround...

[mike-barnett]

Code Contracts is built on top of CCI. The version of CCI that the rewriter uses loads all assemblies transitively referenced by the assembly it is rewriting. However, that is the same as the compiler, so the paths to all needed assemblies should be getting read from the project file. You can try adding a libpath to the assembly using the "Extra Runtime Checking Options" in the project properties. Let me know if that doesn't work. It would also be good to know the command line that is being passed to the rewriter, which you should be able to in the Output window of Visual Studio.

[petergummer]

Hi Mike,

I can’t add a libpath to the assembly because I don’t think it exists anywhere. SHDocVw is a COM component — Internet Explorer, in fact — so there ought to be an interop assembly for it somewhere but where that would be is what I need to figure out. Here’s what the Output window says about it with verbosity "Diagnostic":

23> Dependency "SHDocVw, Version=1.1.0.0, Culture=neutral, PublicKeyToken=3d67ed1f87d44c89". (TaskId:525) 23> Could not resolve this reference. Could not locate the assembly "SHDocVw, Version=1.1.0.0, Culture=neutral, PublicKeyToken=3d67ed1f87d44c89". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. (TaskId:525) 23> For SearchPath "C:\Users\Peter\Ocean\wsml\EHR\distrib\PDFTechLib". (TaskId:525) 23> Considered "C:\Users\Peter\Ocean\wsml\EHR\distrib\PDFTechLib\SHDocVw.winmd", but it didn't exist. (TaskId:525) 23> … snipped several dozen other places where it unsuccessfully searches for it. 23> Required by "PDFTechLib, Version=1.8.2.0, Culture=neutral, processorArchitecture=MSIL". (TaskId:525)

And then lots more stuff until ccrewrite fails:

23>Building target "CodeContractRewrite" completely. 23>Output file "obj\Debug\AIT.Multiprac.ActivityList.rewritten" does not exist. 23>Task "WriteLinesToFile" (TaskId:554) 23> Task Parameter:File=obj\Debug\ActivityListModuleccrewrite.rsp (TaskId:554) 23> Task Parameter:Lines=/level:4 /nologo /rewrite "/framework:v3.5" "/assemblyMode=standard" /throwonfailure "/resolvedPaths: … and then dozens of library path … ;C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\CodeContracts;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 2\Assemblies\CodeContracts;C:\Program Files (x86)\Microsoft\Contracts\Contracts\v3.5 " "AIT.Multiprac.ActivityList.dll" (TaskId:554) 23> Task Parameter:Overwrite=True (TaskId:554) 23>Done executing task "WriteLinesToFile". (TaskId:554) 23>Using "Exec" task from assembly "Microsoft.Build.Tasks.v12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". 23>Task "Exec" (TaskId:555) 23> Task Parameter:WorkingDirectory=obj\Debug\ (TaskId:555) 23> Task Parameter:Command="C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe" "@ActivityListModuleccrewrite.rsp" (TaskId:555) 23> "C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe" "@ActivityListModuleccrewrite.rsp" (TaskId:555) 23> Reading assembly 'PDFTechLib' from 'C:\Users\Peter\Ocean\wsml\EHR\distrib\PDFTechLib\PDFTechLib.dll' resulted in errors. (TaskId:555) 23> Assembly reference not resolved: SHDocVw, Version=1.1.0.0, Culture=neutral, PublicKeyToken=3d67ed1f87d44c89. (TaskId:555) 23>ccrewrite : error : Rewrite aborted due to metadata errors. Check output window 23> elapsed time: 15582.7096ms (TaskId:555) 23>C:\Program Files (x86)\Microsoft\Contracts\MsBuild\v12.0\Microsoft.CodeContracts.targets(254,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe" "@ActivityListModuleccrewrite.rsp"" exited with code -1. 23>Done executing task "Exec" -- FAILED. (TaskId:555) 23>Done building target "CodeContractRewrite" in project "ActivityListModule.csproj" -- FAILED.: (TargetId:912)

So the C# compiler doesn’t seem to care that it can’t find SHDocVw, but ccrewrite fails on account of it.

But your words have given me enough context that I’ve managed to work around the problem as follows: As recommended by http://stackoverflow.com/questions/20845140/add-reference-shdocvw-in-c-sharp-project-using-visual-c-sharp-2010-express, I added a COM reference to “Microsoft Internet Controls”. This added SHDocVw to the project references. It created the assembly Interop.SHDocVw.dll in the project’s obj\Debug folder. C# compilation failed, seemingly similarly to http://stackoverflow.com/questions/5901052/assembly-error-when-building-application; so Catch-22, I had to remove Interop.SHDocVw.dll from the obj\Debug folder. But then I was back to where I started, with ccrewrite failing. I added the COM reference to “Microsoft Internet Controls” again, but this time I moved it to the same folder as the 3rd-party assembly (PDFTechLib) that references it and I renamed it to SHDocVw.dll, since that is the name that the error was saying it couldn’t find.

This worked. Contracts are now being checked at runtime for me.

Thanks for your help!

Peter

On 5 Sep 2015, at 00:14, Mike Barnett notifications@github.com wrote:

Code Contracts is built on top of CCI. The version of CCI that the rewriter uses loads all assemblies transitively referenced by the assembly it is rewriting. However, that is the same as the compiler, so the paths to all needed assemblies should be getting read from the project file. You can try adding a libpath to the assembly using the "Extra Runtime Checking Options" in the project properties. Let me know if that doesn't work. It would also be good to know the command line that is being passed to the rewriter, which you should be able to in the Output window of Visual Studio.