MSBuild SonarQube Runner: "Failed to locate the code coverage command line tool" still with version 1.0.1 - msbuild

I am trying to use MSBuild SonarQube Runner to have my TFS-builds run the Sonar analysis.
I have configured the tool to work with our sonar Server according to this manual. Actually I can start an analysis by building manually via console on my local machine. Additionally, I installed the tool on our build server and when I run it via Visual Studio, I’ll get the error "Failed to locate the code coverage command line tool".
I already found out that the CodeCoverage.exe is needed, but only given with installing an Enterprise version of Visual Studio on the server. I also read that in version 1.0.1, this issue should be fixed (see here and in the changelog this is also mentioned as fixed).
I exchanged the old MSBuild SonarQube Runner with the version 1.0.1, but with building on the TFS in Visual Studio and adding the command lines to run MSBuild SonarQube Runner v1.0.1, I still get the error "Failed to locate the code coverage command line tool".
I also have Visual Studio 2015 Professional installed on the build mashine.
How can I fix this issue without needing an Enterprise version of Visual Studio providing the CodeCoverage.exe?


Code Coverage still requires Visual Studio Enterprise in the 2015 version (see this page).
The bug you referred to fixed an issue in version 1.0 that meant that analysis would fail if the code coverage tool could not be found. Analysis will no longer fail if the code coverage tool was not found, but it doesn't change the requirement to have to VS Enterprise installed if you want to use the Microsoft code coverage tools.

Related

command line MSBuild works - remote build produces errors

I am setting up a process to build remotely a suite of COBOL programs. A virtual machine has Visual Studio 2017 installed along with a Micro Focus COBOL Enterprise Developer 4.0 Visual Studio 2017 plugin. The programs use CICS as their UI and work with a Microsoft SQL Server backend. Opening a developer command prompt in Visual Studio and issuing a MSBuild command with the solution as the parameter successfully builds the programs. A remote build does not - the error is
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
any ideas?

You need to install the "Micro Focus Enterprise Developer Build tools" on the CI machine.

SonarQube scanner for MSBuild missing CA issues

We use SonarQube 5.3 to analyze our C# code.
The analysis is triggered from the vNext build on TFS 2015 (on premise).
We have a quality profile with rules from the C# analyzer plugin (Sxxx) and some FXCop rules (CAxxxx).
We've made a .ruleset that reflects the quality profile to be able to run the code analysis from Visual Studio 2015.
However I'm missing some code analysis warnings/errors in SonarQube that are showing up when running the code analysis locally and also show up in the build log. Both in the MSBuild output that is visible when the build is running on the server, as in the [AssemblyName]CodeAnalysisLog.xml.
The weird thing is, we've been solving a lot of issues lately and we have solved several CA1725 issues that were visible in SonarQube. Now we have a number of CA1725 issues (not suppressed) still visible in the logs and the XML, but they don't show up in SonarQube.

how to use MSbuild to build a Win8 driver without Visual studio installed

I want to build a KMDF driver by WDK8.0 without Visual Studio installed. I looked the msdn, it says the MSBuild do it.
But since the WDK8.0 doesn't contain the compiler, how I can use MSbuild to build a driver without VS2012?
Can anybody explain several words for me? How can I build a windows driver without VS2012.

As far as I’m aware after Microsoft stopped shipping compiler as part of wdk they add requirement to have installed Visual Studio.
http://msdn.microsoft.com/en-us/library/windows/hardware/hh852362.aspx#_System_Requirements

Is it possible to run an FxCop Code Analysis from the MSBuild command line with VS NOT installed?

Our final build server does not have Visual Studio 2010 installed. It uses the MSBuild.exe from the .NET 4 SDK. As part of our code delivery process to our customer we need to allow him to build the projects from the command line on a Visual Studio 'agnostic' server and also to run Code Analysis rules on that machine.
On the visual studio side we started out with AllRules.rules and created exceptions going foreward so naturally we'd like the exceptions to carry over to the code analysis on the build server.
Is this possible ?
Thanks in advance.

Using standalone FxCop you can customize your CI process as you wish. Open this link and go to "Setting up continuous FxCop code analysis" chapter.
Link above seems to be dead now. You can try to look here on this SO question

How does TFPT.exe find what workspace to work in?

In using tfpt from the command, I'm getting the error:
PS D:\Main Line> tfpt uu /noget
Unable to determine the workspace.
Here I'm trying to use the Undo Unchanged command, but I've seen this error with other commands too. The path I'm at is the exact path that is mapped in my TFS workspace. I also tried this which doesn't work either
PS D:\Main Line> tfpt uu /recursive /noget 'D:\Main Line'
Unable to determine the workspace.
I thought it was just using the current path to figure it out, but I can't get it to work right. Does anyone know how this works?

I ran into this same issue, I found the answer at the bottom of the page in one of the help files that came with The power tools. (TFPTCommandLineTool.mht)
Errors
TFPT Error: Unable to determine the workspace
When running tfpt using a command that works with Version Control, you may receive one of the errors:
Unable to determine the workspace
Unable to determine the source control server
Solutions:
Run tfpt.exe from within a directory that is already mapped to Team Foundation source control.
Update your local workspace cache using the tf workspaces command. The tf.exe tool is available in the subfolder Common7\IDE of your Visual Studio installation folder. If you launch a Visual Studio command prompt, you can then run the following command (which depends on your versions of TFS/VisualStudio - you should use the version that matches version of TFPT you are using, e.g. if you have TFPT for VS2015, use TF from a VS2015 command prompt):
VS 2008-2013 / TFS 2008:
tf workspaces /s:serverURL
VS 2010-2013 / TFS 2010 (and probably later versions as well):
tf workspaces /collection:collectionURL
VS 2008 / TFS 2010 (and probably later versions as well):
tf workspaces /s:collectionURL
If you have recently installed Visual Studio 2012, you might have to connect it to the same TFS server/collection you were using in Visual Studio 2010.

When using tf workspaces /s:serverURL make sure you use the right tf.exe!
I had the same problem and was stuck because I used the tf.exe from:
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE
and not the one from:
\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

For Visual Studio 2017 users
I had the same problem when trying to run the tfpt command line on a fresh machine installation with VS215 and VS2017 installed. The latest version for the tfpt tool at the time of writing is from TFS Power Tools 2015. That means the local workspace mapping has to be loaded in VS2015 first before the tfpt tool can find the workspace.
Since my team is using VS2017, I only did the workspace mapping in this Visual Studio version. When I opened the VS2017 developer command prompt to use this tool, I got the 'Unable to determine the workspace' message.
To solve this I opened VS2015 and connect the Team Explorer to the TFS server. It immediately recognizes the workspace mapping that was made under VS2017. After this the tfpt tool works correctly under VS2015 and VS2017 developer command prompts.

I tried all of this and still i got the same error. The error is generic enough to represent multiple issues, i guess..
re-installing TFPT from
https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f
fixed the issue for me.

Actually, although I believe that in some cases these workarounds may fix things, they do not work in all cases. And I strongly suspect that ultimately this points to what could be considered a bug somewhere in the PowerTools code. The reason I say this is that the tf workspace command has no problem detecting the workspace on my machine from the VS Command console, but from that very same console with all of the same path info, TFPT cannot detect it on my lap top no matter what I try. I just got this laptop and installed VS 2010, 2012 and 2013, along with the respective Power Tools installs, and pointed to a suite of projects that currently spans several TFS 2010 and TFS 2012 instances. Because of this many-to-many relationship, I suspect there is an incorrect assembly reference somewhere, some combination of factors, GAC, Path, Environment Variables, VS Installations, TFS repositories. In each VS version I attempted to run the TFPT 2010 executable from the VS 2010 Command, and so on with the remaining versions, and tried the above workspace cache updates in all their forms... nothing. But using the same project I connected from an old server with VS 2010 and TFPT 2010 installed and ran the same command perfectly. So I think it has to do with what is running on your system, and in the future I will be much more skeptical about running the different versions side-by-side.