In VSTS (hosted TFS) I have a build definition which uses MSBuild. What I would really like is to have pull requests annotated with any rule violation detections. However I can't get the analysers to work at all. What I've done so far;
Installed Microsoft.CodeAnalysis.FxCopAnalyzers in one of the projects that gets build
Verified that running "Analyze Code" in Visual Studio does output rule violations
All the *.ruleset files are not available on the self-hosted build agent, as it only has MSBuild installed (no full-fledged Visual Studio). For the same project as in point 1, I've also used a custom ruleset.
I have also build the project on a hosted build agent (which has VS2017 installed), but also to no avail.
With all of the above, the build log / build overview in VSTS doesn't list any rule violations. It's my understanding that the code analysis should be run automatically and the output should appear on the build overview page (i.e. https://MYSITE.visualstudio.com/MYPROJECT/_build/index?buildId=XXX&_a=summary&tab=details).
The Code Analysis setting is based on the configuration and platform, so you need to make sure you build the project with the same configuration and platform that enabled code analysis on build.
You also could specify it in MSBuild Arguments of MSBuild task:
/p:RunCodeAnalysis=true;CodeAnalysisRuleSet=..\RuleSets\MyMixedRecommendedRules.ruleset
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.
My Visual Studio 2019 solution contains several projects, some of which I don't want to be built as part of continuous integration. Specifically, I'm trying to exclude tooling and unit tests.
In Visual Studio, I have created a new solution configuration and unchecked the "Build" box for each project I don't want to be built.
In TeamCity, I have specified the name of the new solution configuration to use. However, TeamCity continues to attempt to build all projects within the solution.
[I had included screenshots of my solution configuration, TeamCity build configuration, and resulting TeamCity log but I do not have enough reputation to post images apparently.]
From everything I could find so far, unchecking "Build" from the solution configuration used by TeamCity is supposed to exclude that project from building.
I figured it out by finally noticing that the TeamCity log was showing the build configuration as "ReleaseCI|Mixed Platforms" instead of "ReleaseCI|Any CPU". On other projects, I only needed to specify the configuration. For this project, I apparently have to specify the platform as well.
Seems like a pretty obvious question but I haven't been able to find this anywhere online - but what exactly counts as building something manually? As in if I do Ctrl+Shift+B on Visual Studio is that manually building? Then how could I go from that to automated build (running it from command line?). All I know is that I am supposed to use MSBuild to do automated builds on a project that is currently built 'manually'.
What is Manual Build?
Whether you are using Visual Studio or MSBuild command to build is considered to be manual build. That because you need to build your project manually every time no matter you are using Visual Studio or MSBuild command. And the hot key Ctrl+Shift+B is a quick start mode to build project in Visual Studio.
If you want to automated build, you should consider 'continuous integration' For example, TFS(Team Foundation Server), Teamcity, etc. You can easily search those continuous integration info on the internet.
The biggest difference between manual build and automated build is that you should manually build your project every time when source code changes, but automated build will execute the build automatically by continuous integration tool when source code changes, no need to build your project manually.
I started learning TFS Team build. I am having a basic doubt. I referred this
article. I followed the steps exactly and got succeeded. I created a Console Application and pushed in TFS using TeamServices. My doubt is when we build a Console application in visual studio we will get an exe in bin folder.
Same way in this team build how to get the output in my local machine ?
What is the difference between the local build using Visual studio and this team build ?
EDIT :
I added like this. Still I am not able to see the output in the RELEASE folder.
I got the result as success saying
Still I couldn't figure out the output - the exe produced as a result of build.
Am I doing anything wrong ?
Note : I have a requirement like what you explained in the answer. So why I am using TFS team build. Since I am new I am experimenting with a small example.
When to use a build system
Team Build does not replace Visual Studio build. Use Team Build when you have a complex / lengthy build, to easily integrate running unit tests as part of the build or to deploy assemblies to a server after the build is complete.
Most people will setup a TFS build definition to run as "Continous Integration" build, meaning that whenever a commit is checked in, a build occurs. The build would compile and run tests and if it fails all developers can be notified.
How to get to the build output
When using a build system like TFS build, the build is done on a remote machine. If you want to retrieve the output of the build, add a Publish Build Artifacts step to your build definition. Since the build happened on a remote machine, the remote machine does not have access to your local developer machine.
The artifacts (assemblies) will be available for download on the build summary page:
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.