Project property page not registered in VS2015

[GSPP]

I found the Code Contracts property page missing. I downloaded the latest package and repaired the installation. The property page still is not there. I searched the registry for "Microsoft Code Contracts Property Page" and these are the results:

Shouldn't there be an entry for version 14? The installer repair did not add it. Is this a bug?

I just tried it in a VM with a different Windows installation. Here, the problem did not occur but it was a fresh install.

Then I uninstalled, then installed. This repaired the tab. So this might be a bug in the repair functionality. Maybe it thought that VS15 was not present because I might have installed VS15 aftter installing CC into VS13.

---

Update: The update dialog in VS suddenly shows a CC update. It shows a wrong old version:

Because the current version is the latest, which is:

"CodeContractsHelper.dll" also has the same version number.

And when I download the update that is offered I just get a repair option. So it's installed already.

Strange again.

[mlhaufe]

Similar issue here as well with VS Community 2015 Update 3.

This seems to have come up in the past:

https://social.msdn.microsoft.com/Forums/en-US/82a61434-b368-4500-9f6b-4e56c754029f/code-contract-tab-missing?forum=codecontracts

In my case I chose the repair option in the Windows Control panel then reloaded the Solution.

[pgeerkens]

All afternoon I have worked on his, uninstalling; re-installing; repairing; nu-getting; un-nu-getting; re-nu-getting. No matter the sequence, if the VSIX is installed the version on the property page and compiled against is 1.9.10714.2; if I the VSIX is not installed then no property page is visible, but v1.10.20606.1 is compiled against. I had this all figured out and working, but it broke again when I installed Update 3 for VS 2015. HELP!

[yaakov-h]

Are you trying to build against the NuGet package for 1.10.20606.1, with 1.9.10714.2 installed globally on the machine?

[pgeerkens]

Yes, bceause that appears to be the only way to get the Property Page to show up for projects. If I uninstall the global install of 1.9.10714.2 then all the property pages disappear.

[yaakov-h]

You need to define this in your csproj file before Microsoft.CSharp.Targets/Microsoft.CSharp.Portable.Targets:

    <PropertyGroup>
        <DontImportCodeContracts>True</DontImportCodeContracts>
    </PropertyGroup>

This will bypass the version installed globally and allow you to manually import the MSBuild props file from NuGet.

[pgeerkens]

I don't see that in my csproj file. The closest match is this near the bottom of the file:

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
  </Target>

However adding the snippet you recommend (immediately before this section) has no effect I can detect.

I also get no noticeable effect when I add the snippet very early in the file, as the very first PropertyGroup element.

[yaakov-h]

If you define that as I said, you should get the property pane for 1.9 and be building against 1.10. You can verify this by trying to invoke a bug that was fixed in 1.10 or a method that didn't have BCL contracts in 1.9.

[pgeerkens]

The problem is that the location you specified doesn't exist in my csproj files, and if I put the element elsewhere it either has no effect (ie checking continues to be against v v1.9) or results in Static Checking not occurring at all.

More explicit instructions on where the element must be placed would really help.

[pgeerkens]

As per your instructions, as best I can interpret a location that doesn't exist, this is what the tail-end of my csproj files now looks like; with the result that Code Contracts runs but is still running v1.9. Please inform me as to where in a csproj file of this vintage I should place the new element.

  <ItemGroup>
    <Service Include="{82A7F48D-3B50-4B1E-B82E-3ADA8210C358}" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
    <PropertyGroup>
        <DontImportCodeContracts>True</DontImportCodeContracts>
    </PropertyGroup>
  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
  </Target>
  <PropertyGroup>
    <PreBuildEvent>
    </PreBuildEvent>
  </PropertyGroup>
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

[yaakov-h]

Perhaps I should have been clearer. When I said:

You need to define this in your csproj file before Microsoft.CSharp.Targets/Microsoft.CSharp.Portable.Targets

I meant your csproj should end up looking like this:

<!-- other stuff here -->
<PropertyGroup>
    <DontImportCodeContracts>True</DontImportCodeContracts>
</PropertyGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<!-- other stuff here -->

[pgeerkens]

I have made that change in all three projects of the solution, and performed Rebuild Solution. That very successfully ensures that the static checker does not run at all. This is the very first placement that I tried, and again get the very same result.

[yaakov-h]

For static checking, you need to ensure that CodeContractsInstallDir is defined and correct. For example, this is what I have in one such project. Note that this bit needs to go after Microsoft.CSharp.targets.

<PropertyGroup>
    <!-- Adjust as appropriate -->
    <PackagesRootDirectory Condition="$(PackagesRootDirectory) == ''">$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\packages'))</PackagesRootDirectory>
    <CodeContractsInstallDir>$(PackagesRootDirectory)\DotNet.Contracts\</CodeContractsInstallDir>
</PropertyGroup>
<Import Project="$(CodeContractsInstallDir)\MsBuild\v$(MSBuildToolsVersion)\Microsoft.CodeContracts.targets"/>

[pgeerkens]

That again is resulting in no static analysis being performed. It is not clear to me what the correct value for CodeContractsInstallDir value should be. However, this is what the tail end of my csproj files now looks like. If I also added the Import element then the project simply wouldn't load.

Note - You seem to be making the assumption that I have a basic understanding of the csproj file structure - beyond the basics of it being an XML file, that assumption is incorrect.

  <PropertyGroup>
      <DontImportCodeContracts>True</DontImportCodeContracts>
  </PropertyGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

  <PropertyGroup>
      <!-- Adjust as appropriate -->
      <PackagesRootDirectory Condition="$(PackagesRootDirectory) == ''">$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\packages'))</PackagesRootDirectory>
      <CodeContractsInstallDir>$(PackagesRootDirectory)\DotNet.Contracts\</CodeContractsInstallDir>
  </PropertyGroup>

  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

[pgeerkens]

Okay - it was a long night yesterday; I do appreciate your assistance. With time for some research I am feeling more comfortable in the project files. I have restored the Import element as follows:

<Import Project="$(CodeContractsInstallDir)\MsBuild\v$(MSBuildToolsVersion)\Microsoft.CodeContracts.targets"/>

and things are generally working as they should. However I am concerned that the version of CodeContracts is hardcoded in the project file:

<CodeContractsInstallDir>$(PackagesRootDirectory)\DotNet.Contracts.1.10.20606.1\</CodeContractsInstallDir> Is there a build variable available that stores that.

Also, the fix to display CodeContracts Results, Warnings and Errors in the Error List window is no longer working; messages only display in the Output window.

Finally, where should invocation of the target EnsureNuGetPackageBuildImports occur? Currently I have placed it as the last target in each file. Does its location matter?

[yaakov-h]

There's no build variable available for the version of code contracts, particularly since you haven't yet imported it, you have no idea what version you want.

If you want to remove the version number from your project, consider using something like Paket to handle NuGet package restoration.

Personally I have a custom setup and have never seen EnsureNuGetPackageBuildImports before, so I have no comment regarding it.

Sent from my phone, widescreen iPod, and internet communicator.

On 5 Jul. 2016, at 10:12 am, Pieter Geerkens notifications@github.com wrote:

EnsureNuGetPackageBuildImports

[pgeerkens]

I am revisiting this project again. I have uninstalled both DotNet.Contracts (from the solution using NuGet) and the VS Extension Code Contracts from VS Tools and Extensions using Programs and Features. Then, in order, I re-installed VS Extension Code Contracts from VS Tools and Extensions (to get the Code Contracts property page), and added the latest NuGet package for DotNet.Contracts (v 1.10.20606.1) to the entire solution. Static Analysis runs and the property page displays. However I believe that the version of cccheck that runs is actually from the VSIX and not NuGet.

The tail end of my project config files looks like this:

  <ItemGroup>
    <Service Include="{82A7F48D-3B50-4B1E-B82E-3ADA8210C358}" />
  </ItemGroup>
  <PropertyGroup>
    <DontImportCodeContracts>True</DontImportCodeContracts>
  </PropertyGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <PropertyGroup>
    <!-- Adjust as appropriate -->
    <PackagesRootDirectory Condition="$(PackagesRootDirectory) == ''">$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\packages'))    </PackagesRootDirectory>
    <CodeContractsInstallDir>$(PackagesRootDirectory)\DotNet.Contracts.1.10.20606.1 \</CodeContractsInstallDir>
  </PropertyGroup>
  <Import Project="$(CodeContractsInstallDir)\MsBuild\v$(MSBuildToolsVersion) \Microsoft.CodeContracts.targets" />
  <PropertyGroup>
    <PreBuildEvent>
    </PreBuildEvent>
  </PropertyGroup>
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

Is there a definitive way to verify that the correct, desired, version, namely the NuGet DotNet.Contracts version of cccheck, is the one running?

My main reason for believing that the incorrect version, the VSIX one, is running is that all messages still are reported to the Output Window (only); none go to the Error List window as was the case following the January update.

Thanks again for your patience. I really like this product, and would like to actually be able to enjoy its enhancements.

[pgeerkens]

Just to confirm, this is what is reported in the Output Window when I rebuild one project of the solution:

1>------ Rebuild All started: Project: Monad, Configuration: Debug Any CPU ------
CodeContracts: Monad: Schedule static contract analysis.
CodeContracts: Monad: Background contract analysis started.
1>  elapsed time: 1311.0005ms
1>  elapsed time: 1047.2037ms
1>  
1>  Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
1>  Copyright (c) Microsoft Corporation.  All rights reserved.
1>  
1>  Assembly 'obj\Debug\Monads.dll' successfully re-signed
1>  Monad -> C:\Users\Pieter_2\Git\Monads\Monad\bin\Debug\Monads.dll
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
CodeContracts: Monad: Time spent connecting to the cache: 00:00:06.5115222
CodeContracts: Monad: Cache used: (LocalDb)\MSSQLLocalDB
CodeContracts: Monad: Validated: 100.0 %
CodeContracts: Monad: Checked 581 assertions: 581 correct
CodeContracts: Monad: Contract density: 2.90
CodeContracts: Monad: Total methods analyzed 204
CodeContracts: Monad: Methods analyzed with a faster abstract domain 0
CodeContracts: Monad: Method analyses read from the cache 204
CodeContracts: Monad: Methods not found in the cache 0
CodeContracts: Monad: Methods with 0 warnings 204
CodeContracts: Monad: Total time 4.026sec. 19ms/method
CodeContracts: Monad: Retained 0 preconditions after filtering
CodeContracts: Monad: Inferred 0 object invariants
CodeContracts: Monad: Retained 0 object invariants after filtering
CodeContracts: Monad: Detected 0 code fixes
CodeContracts: Monad: Proof obligations with a code fix: 0
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Monads.dll(1,1): message :     CodeContracts: Checked 581 assertions: 581 correct
CodeContracts: Monad: 
CodeContracts: Monad: Background contract analysis done.

[yaakov-h]

IIRC, the Tasks/Errors pane bug was fixed in the VS extension side of things, not the cccheck side. You are probably using a newer version of cccheck, but it's output is still going to the Tasks List because of the older extension from the MSI/VSIX.

Sent from my phone, widescreen iPod, and internet communicator.

On 11 Sep. 2016, at 12:24 am, Pieter Geerkens notifications@github.com wrote:

Just to confirm, this is what is reported in the Output Window when I rebuild one project of the solution:

1>------ Rebuild All started: Project: Monad, Configuration: Debug Any CPU ------ CodeContracts: Monad: Schedule static contract analysis. CodeContracts: Monad: Background contract analysis started. 1> elapsed time: 1311.0005ms 1> elapsed time: 1047.2037ms 1>
1> Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 1> Copyright (c) Microsoft Corporation. All rights reserved. 1>
1> Assembly 'obj\Debug\Monads.dll' successfully re-signed 1> Monad -> C:\Users\Pieter_2\Git\Monads\Monad\bin\Debug\Monads.dll ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== CodeContracts: Monad: Time spent connecting to the cache: 00:00:06.5115222 CodeContracts: Monad: Cache used: (LocalDb)\MSSQLLocalDB CodeContracts: Monad: Validated: 100.0 % CodeContracts: Monad: Checked 581 assertions: 581 correct CodeContracts: Monad: Contract density: 2.90 CodeContracts: Monad: Total methods analyzed 204 CodeContracts: Monad: Methods analyzed with a faster abstract domain 0 CodeContracts: Monad: Method analyses read from the cache 204 CodeContracts: Monad: Methods not found in the cache 0 CodeContracts: Monad: Methods with 0 warnings 204 CodeContracts: Monad: Total time 4.026sec. 19ms/method CodeContracts: Monad: Retained 0 preconditions after filtering CodeContracts: Monad: Inferred 0 object invariants CodeContracts: Monad: Retained 0 object invariants after filtering CodeContracts: Monad: Detected 0 code fixes CodeContracts: Monad: Proof obligations with a code fix: 0 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Monads.dll(1,1): message : CodeContracts: Checked 581 assertions: 581 correct CodeContracts: Monad: CodeContracts: Monad: Background contract analysis done.

― You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.