The teamcity Visual Studio build runner does not seem to report warnings in a meaningful way (other than the log).
Is there an easy way to get TeamCity to report the warnings?
I've found:
http://blogs.lessthandot.com/index.php/EnterpriseDev/application-lifecycle-management/displaying-net-build-warnings-in
but I wonder if I'm missing a more straightforward solution.
One option is to use the "Inspections (.NET)" Build Step as ReSharper Code Inspections include compiler warnings.
Should you and your teammates be using Resharper locally you can also set a "Custom settings profile path" in the Build Step's advanced settings, i.e. use a committed ReSharper settings file, not to get any unexpected warnings in CI versus those found working locally.
For each build result you'll have the total number of inspections (warnings) in the build status text, and also a "Code Inspection" tab where the inspections are categorized and you can drill into the .cs files in question.
Like any metric change you can also configure the build to fail if the number of inspections go above a specified amount or go up by a specified amount versus a previous build.
Related
Lately I have tried to get all quality and style rules for my team into an .editorconfig file. As ReSharper still has a larger scope of style rules than .NET Analyzers and other such things, and as it has grown to embrace the EditorConfig approach, I have exported all of our ReSharper rules to the .editorconfig file, and deleted our team's DotSettings file. I've been attempting to make almost all rules have a minimum severity of warning, and to have warnings be treated as errors. This goes for ReSharper and the standard VS rules. My end goal is to have our builds break, both locally and on our Azure DevOps Pipelines, if any of the rules in the .editorconfig, from ReSharper or otherwise, are violated.
So far, I have been unable to get ReSharper-specific errors or warnings to break the build in any of the following:
Visual Studio build (MSBuild)
dotnet build (local)
ReSharper Build
dotnet build (Azure DevOps YAML Pipeline)
Now I'm starting to suspect that the ReSharper rules are really only for assistance at design time, but that there are no mechanisms to make them actually cause a build to fail. I'm hoping I'm wrong and that I just need to change a configuration or install some kind of add-on locally and/or on Azure DevOps.
As you already suspected, some of your criteria cannot be met ootb, namely:
Visual Studio build (MSBuild)
dotnet build (local)
dotnet build (Azure DevOps YAML Pipeline)
This is because R# is an IDE feature and low(er)-level tools like MSBuild or the .NET global tools are simply unaware of R#, its rules, etc.
I think one had to write a Roslyn analyzer to enable this because this is Microsoft's intended way of integrating custom code checks into the build pipeline.
Another option would be to use InspectCode out of the R# Command Line Tools. If you integrate this tool into your build pipeline, it will fail when specific R# rules are violated.
But you should be able to make builds fail using R# Builds when setting the severity of all your relevant rules inside .editorconfig to error.
I've been setting up SonarQube analysis for one of our builds in VSTS, and I've noticed that there's a difference in the code analysis / build warnings if the advanced option "include full analysis report in build summary" is enabled in VSTS.
We have a custom ruleset enabled for our local builds in Visual Studio, which combines Microsoft CodeAnalysis warnings and StyleCop analyzers. When we run the build in VSTS with the full analysis report setting enabled, these warnings don't show up, and only the SonarQube warnings are displayed. I thought this was expected for all builds using SonarQube, as mentioned here in the link below.
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Extension+for+VSTS-TFS#AnalyzingwithSonarQubeExtensionforVSTS-TFS-Note
However, if we disable this setting, we get additional SonarQube warnings, but the Microsoft and StyleCop warnings also show up.
Can anyone explain why the two behaviors are different? Ideally, we'd like warnings from Microsoft, StyleCop and SonarQube to show up, AND for the build to include the full analysis report - is there any way to do this?
I'm using SonarQube v6.7.1.35068, SonarC# v6.7.1 (build 4347), and v3.* of the VSTS SonarQube task.
The Include full analysis report in the build summary setting doesn't change the ruleset or analyzers that are run during the analysis. All it does is cause the End task to poll the SonarQube server until the server-side part of the analysis has completed so that it can show the final analysis results on the VSTS build summary page.
To work out what is different between the builds you could try enabling more verbose logging:
for SonarQube, set the Additional Settings property of the VSTS Begin task /d:sonar.verbose=true
for VSTS, set the system.debug build to true
You're right, the Begin task does limit the analyzers and rules that are run to those that are configured on the SonarQube server.
To have the Microsoft FxCop rules run as past of the analysis run you would install the FxCop plugin for SonarQube and include its rules in your Quality Profile.
To run the StyleCop rules (assuming you're using the new Roslyn-base StyleCop analyzers) you would first have to create a SonarQube plugin for it using the SonarQube Roslyn SDK, then install the plugin and add the rules to Quality Profile.
First, the Include full analysis report in build summary shouldn’t affect the result in Issues section of build summary, it is used to upload the report to build summary and the result will be show in the bottom of build summary (below Work items linked to associated changes section).
Secondly, the Issues section of build summary can’t show all analysis result, just part of it.
You can upload the result files to build through Logging Command (e.g. Write-Host "##vso[task.addattachment type=Distributedtask.Core.Summary;name=testsummaryname;]c:\testsummary.md") and it will show in the bottom of build summary (The sonarqube task uses this way too).
I currently have a solution with a number of projects which include Unit Tests.
We've got a CI build and a separate Scheduled build and I would like to be able to run Code Coverage on the latter (not the CI).
At the moment we are using Visual Studio 2010 and TFS 2008. None of these can be changed.
I've looked around for hours and lots of suggestions mention a Process tab to select in the Build Definition however further investigation shows that the combination of VS/TFS that we have does not have this option.
Another source says to modify some testsettings such that they contain the Code Coverage option (which I have done) and then define the Test Settings file in the build - but I have no idea how to do this (http://www.codewrecks.com/blog/index.php/2010/06/14/running-code-coverage-in-tfs2010-builds/).
I have a testsettings configuration that will run code coverage locally so my issue is that I need the MSBuild TFSBuild.proj file to know which testsettings file to use when running it's tests (through the <RunTest>true</RunTest> option).
Any help on this would be greatly appreciated. I've trawled through the various other proposed solutions but none seem to match this. They either use a better version of TFS, or do something else.
EDIT. I suspect I might be restricted to using an Exec task within the build script and running the Vsperfmon.exe command with some arguments. If this is the case please provide an example because I've no idea how to capture the results from this command and tie them to my Scheduled build.
Thanks all.
We want to refuse checkins which break our custom defined static code rules. Therefore we have defined a Gated Checkin build, with "Perform Code Analysis" set to 'AsConfigured'.
When I build the solution locally, using the same configuration and target as defined for the Gated Check in build, there are no errors. But the Gated Checkin build seems to ignore any [SuppressMessage] attributes that we have defined in source, thus reporting errors.
The Gated checkin build does not ignore [SuppressMessage] attributes that are defined in a GlobalSuppressions file.
Any one else have this problem?
When you said you build locally fine, did you build from Visual Studio, or did you build with MSBuild?
TFS Build uses MSBuild to build the projects, and you should be able to see what MSBuild command is run during the build by looking the log from the build report (if you set the verbosity level at least to Normal).
To investigate this issue, I would recommend you use this MSBuild command to build your solution locally (you would need to change the path to the solution on your machine, rather than the path used on the build machine), and it will likely give you the same errors, which indicates a discrepancy between building with MSBuild and building with Visual Studio. Then we can look at the MSBuild command and see why it does not behave the same way.
Hope this helps.
We have a 50 projects solution in VS 2005.
Is any way to get incremental build if nothing was changed?
It is kind of doing it now, but it executes all prebuild and post build events for each project.
Is any way to prevent it?
Have a look at the Build Events tab. Notice the dropdown at the bottom that says Run the post-build event:. Does it say "On successful build"? Try changing it to "When the build updates the project output".
Visual studio does what you describe by default, custom build steps are not executed for up to date projects.
Something in your dependancies or build settings are causing it to update all builds. Unfortunately it's hard to track down without additional infromation.
If you know ahead of time which ones you would like to build or not build, you could create different build configurations that only build specified projects.
This solution doesn't use dependencies at all, so it will only work if you have a few different distinct groups of projects.