How can I run it under VS 2017?

[TrueWodzu]

Hi,

Extension doesn't load into Visual Studio, activity log says:

  <entry>
    <record>1774</record>
    <time>2019/11/14 11:14:22.082</time>
    <type>Error</type>
    <source>VisualStudio</source>
    <description>CreateInstance failed for package [CoverageExtPackage]Source: &apos;mscorlib&apos; Description: Could not load file or assembly &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos; or one of its dependencies. The system cannot find the file specified.&#x000D;&#x000A;System.IO.FileNotFoundException: Could not load file or assembly &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos; or one of its dependencies. The system cannot find the file specified.&#x000D;&#x000A;File name: &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos;&#x000D;&#x000A;   at System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type)&#x000D;&#x000A;   at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)&#x000D;&#x000A;   at System.Activator.CreateInstanceFromInternal(String assemblyFile, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo)&#x000D;&#x000A;   at System.AppDomain.CreateInstanceFrom(String assemblyFile, String typeName)&#x000D;&#x000A;&#x000D;&#x000A;WRN: Assembly binding logging is turned OFF.&#x000D;&#x000A;To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.&#x000D;&#x000A;Note: There is some performance penalty associated with assembly bind failure logging.&#x000D;&#x000A;To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].&#x000D;&#x000A;</description>
    <guid>{3D61029D-1E2F-4471-93CA-18FDB2F50CD9}</guid>
    <hr>80004005 - E_FAIL</hr>
    <errorinfo></errorinfo>
  </entry>

What shuold I do, to run it? Do I need to install Visual Studio 2015?

[TrueWodzu]

I guess Version=16.0.0.0 means that I have installed VS 2019 dev tools?

Have tried build this on my VS 2017, but got a bunch of unresolved/ incompatible references..

[atlaste]

Yea I guess that's the VS2019 dev tools. The moment we create a package for VS2019, we have to use the 2019 dev tools, which gives this kind of pain.

You can also simply build it using VS2017; we did that in the past and it works just fine. The only reason we switched to the 2019 dev tools was to support VS2019 as well.

[atlaste]

"Have tried build this on my VS 2017, but got a bunch of unresolved/ incompatible references.." -- hmm. You might just want to grab an older version like this one: https://github.com/atlaste/CPPCoverage/blob/e81a19e4bf1423ef52b9c35a0c0fdb9a83ac4bff/CoverageExt/CoverageExt.vsix .

Not much has changed since then; we're currently working on a much better version of the coverage tool, but that's another story...

[TrueWodzu]

Thanks for answering.

I am afraid it got to the point that it can't be simply compiled under VS2017. I've tried and got a lot of errors. I've read that there is a possibility to have two version of extension (VS 2017 / VS2017) in one solution, but I have no knowledge nor experience to handle that.

I was able to compile it under VS 2019 and it works fine under 2019 but it does not install itself correctly under 2017, even after editing manifest file.

Thank you, I will try proposed version :)

[atlaste]

Either ways, thanks for the feedback. We'll keep it in mind for our new version that we have to create virtual machines for each version of VS that we want it to run on... I guess there's just no other way.

[TrueWodzu]

Take a look at this: https://devblogs.microsoft.com/visualstudio/new-features-for-extension-authors-in-visual-studio-2019-version-16-1/

maybe this will allow you to have different versions without virtual machines.

[atlaste]

Yes, I am aware of that, but to be honest we have to look more into the details of that. The "funny" thing about the VS SDK is that you quickly run into assemblies and legacy COM that you didn't really want to use... There's also subtle differences like the adornment layer ordering, which suddenly changed from 2017 to 2019 (in other words: suddenly everything was gone). Also worth noting is that my desktop has both VS2017 and VS2019 installed... The only way to know for sure is apparently a VM.

In the version we're now developing, we're doing a lot of integration in VS, much more than this relatively simple tool. We should make an announcement in a month or so I guess...

[TrueWodzu]

I can only imagine what problems you must be facing in terms of making it compatible across several versions of VS.

I wanted to let you know that I've tried version which you suggested and it worked. Thank you for this. Well..it works in general but doesn't work for my main project which has sources located in various folders.

So, after reading documentation I see that I need to use Coverage-x64.exe (or 86) and there is a -p switch to give a path to the source code. What if my source code is located in couple of directories, can I specify multiple paths?

[atlaste]

From the top of my head: just set it to the shared root folder of your source code.

It's not ideal, but it'll probably do. I'll make a note of it for the version we're currently working on; I'm fairly sure we will support it eventually.

[TrueWodzu]

I know we've deviated from original question in this topic but if you don't mind answering:

How can I view .cov file? Coverage-64.exe created cov file but how can I view its contents? How can I see which lines have been hit and which not? Can I somehow open this file in Visual Studio?

[atlaste]

The plugin opens it for you if it's in the solution folder.

[TrueWodzu]

Now I get it, it must be named CodeCoverage.cov

[atlaste]

Yea. Normally you create a coverage file from right click -> run coverage, but that assumes a different folder structure I suppose.

[TrueWodzu]

I have few observations in regards to excluding files via -x switch:

1. Currently it is not possible to exclude more than one file name. For example, if my .cov file contains such entries and I would want to re-run coverage and exclude these files:

FILE: c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.16.27023\include\sstream
FILE: c:\coding\development\c++\libs\opencv 3.4.1\build\include\opencv2\core\matx.hpp

I can remove first file by -x "program files" but I can't remove both lines. I've tried -x "program files, libs".

2. Excluding doesn't work at all for cobertura file type. This basically means I can't use this tool in our Continuous Integration system.

3. Apart from excluding multiple file names, I would also suggest an "-i' switch. This would allow us to specify what file names we want to have included. This makes sense, if my project has 3 .cpp files I want to have code coverage only for these files. So I would call Coverage-64.exe with -i "FirstFile, SecondFile, ThirdFile" I think "-i" switch would be mutually exclusive to "-x".

Just an idea. Maybe there is a way to have code coverage only for files that I want?

[atlaste]

Thanks for your feedback.

1. Yes, that's correct. All symbols are passed through the filters (which is a lot, especially when users are using template meta-programming). Because we want to keep the system fast, we decided back then to exclude based on simple criteria. Including your code root folder makes more sense to me (c:\coding I suppose). Most users have some kind of 'root folder' for their code...

That said, the system we're now developing is more flexible in this sense; we traded some performance for a hierarchical filtering system, that allows for more complex filters.

It is of course always possible to implement some kind of post-processing.

2. Right, I wasn't aware of that, but I do know this will be fixed in the new system (because we reimplemented the output converters from scratch, and they work a bit different).

Because you mention CI, be aware that during the conversion to clover and cobertura, information gets lost. For example, cobertura assumes a Java namespace->class->method structure, with a single compilation unit -- which isn't always the case in C++. Think for example of templates, macro's, etc. We're mapping as good as we possibly can and aggregated scores are fine, but at the end of the day, it's just not the same...

For that reason, we've also been working on better CI integration at the moment. Actually we've already implemented some version of that for some years back, and we've been using that in my company. We're actually integrating that into the new system as we speak.

3. Yes, we're adding more fine-grained control of filters in the new version. But like I said in (1), why not simply use -p "c:\coding" ? After all, that's pretty much the whole point of the -p inclusion filter.

[atlaste]

I'm going to close this ticket because I guess the issue at hand is solved.

Since you seem to need features that we're currently building, I'm happy to send you an e-mail once we have something live, that is of course: if you're interested. Just drop me an e-mail at info@nubilosoft.com with your contact details and when the time is there we'll send you an e-mail.

[TrueWodzu]

I've tried -p at the very beginning but I guess I was confused by the instruction what path to give. I must have given wrong path that is why I haven't got my files filtered. Today I've tried it once again and worked perfectly. Thank you for taking your time to help me with my issues.