How do you disable Roslyn Analyzers when using msbuild through the command line? - msbuild

The Roslyn Analyzers are installed as nuget packages, which are dependencies of the FxCop Analyzers (also installed as nuget packages).
I have enabled full solution analysis as instructed here: How to Enable and disable full solution analysis for managed code.
I have a fairly large solution with most of the projects using the FxCop/Roslyn Analyzers and Visual Studio builds fine, usually in under a minute.
However, when running msbuild through the command line using:
"C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe" "C:\Source\MySolution\MySmartClient.sln" /p:Configuration=Develop;Platform="Any CPU" /
t:Build
Building the solution takes anywhere from 4-15 minutes. The same is true on the build server which uses the same command.
I've tried /p:RunCodeAnalysis=False and that has no effect. I've also used process monitor to emulate the msbuild command that VS sends to msbuild with no change.
And, according to this doc: How to: Enable and disable automatic code analysis for managed code
The Enable Code Analysis on Build check box only affects static code analysis. It doesn't affect Roslyn code analyzers, which always execute at build if you installed them as a NuGet package.
These excessive build times are not practical. Is there any way to disable when using msbuild through the command line?

It's not really supported, but there is a workaround:
Create a Directory.Build.targets (msbuild >= v15.0), After.{SolutionName}.sln.targets (msbuild < 15.0) file in your solution root folder and add:
<Project>
<Target Name="DisableAnalyzers"
BeforeTargets="CoreCompile"
Condition="'$(UseRoslynAnalyzers)' == 'false'">
<!--
Disable analyzers via an MSBuild property settable on the command line.
-->
<ItemGroup>
<Analyzer Remove="#(Analyzer)" />
</ItemGroup>
</Target>
</Project>
You can pass in /p:UseRoslynAnalyzers=false now to remove all analyzers configured in the project.
See also:
https://github.com/dotnet/roslyn/issues/23591#issuecomment-507802134
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019#directorybuildprops-and-directorybuildtargets
You can edit the condition to also trigger on RunCodeAnalysis=False or Never.
<Target Name="DisableAnalyzers"
BeforeTargets="CoreCompile"
Condition="
'$(UseRoslynAnalyzers)' == 'false'
or '$(RunCodeAnalysis)' == 'false'
or '$(RunCodeAnalysis)' == 'never'" >
To disable a specific analyzer, use this trick:
We just spent 2 hours figuring out how to disable an analyzer based on an MSBuild property, AMA.
https://twitter.com/Nick_Craver/status/1173996405276467202?s=09

The documentation has changed since the original answers. There is now this page documenting how to disable code analysis from analyzers:
There are 3 MSBuild properties you can use to control analyzer behavior (all default to true):
RunAnalyzersDuringBuild Controls whether analyzers run at build time.
RunAnalyzersDuringLiveAnalysis Controls whether analyzers analyze code live at design time.
RunAnalyzers Disables analyzers at both build and design time. This property takes precedence over RunAnalyzersDuringBuild and RunAnalyzersDuringLiveAnalysis.
Edit: it looks like there is an issue being tracked where these props don't work unless your project has Microsoft.CodeAnalysis.targets included. So your mileage may vary until this is fixed.

In case anyone else happens to find themselves here, I came across this issue on the dotnet/roslyn project on Github:
Feature: MSBuild switch for turning on/off analysis #23591
The preceding issue describes a work-around:
Substitute for old MSBuild properties? #1431
<PropertyGroup>
<RunCodeAnalysis Condition="'$(RunCodeAnalysis)' == ''">true</RunCodeAnalysis>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="<whatever analyzers package you are depending on>" Condition="'$(RunCodeAnalysis)' == 'true'" />
</ItemGroup>
# You'll need to run a restore when changing this value
msbuild /p:RunCodeAnalysis=false
Although, I had a couple of differences though since I'm not using package references. This worked for me.
<ItemGroup>
<Analyzer Include="<whatever analyzers package you are depending on>" Condition="'$(RunCodeAnalysis)' == 'true'" />
</ItemGroup>
<!-- I added the condition to the EnsureNugetPackageBuildImports too. -->
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="'$(RunCodeAnalysis)' == 'true' AND !Exists('<relative path to the prop of whatever analyzers you are depending on>')" Text="$([System.String]::Format('$(ErrorText)', '<relative path to the prop of whatever analyzers you are depending on>'))" />
</Target>

Related

Set msbuild OutputPath conditioned on project name

I'm trying to improve a build-server setup for .NET solutions. The build is done using msbuild solution.sln /p:OutputPath="$pwd/build" and an additional Directory.Solution.targets to work around a quirk of msbuild (from related question, see its content below). Now we've decided to move our tests to separate projects so that the test dlls and their dependencies don't land in the OutputPath. Usually this wouldn't be a problem, but for historical reasons every single project in the solution has its OutputPath set to ..\..\. This is why I'm overriding it when calling msbuild. But now I need to only override it for some of the projects - and I can't figure out how.
The project structure right now looks like this.
app/
sources/
Complete.sln
Proj1/
proj1.csproj
Proj1.Test/
proj1.test.csproj
Building the solution from Visual Studio by a developer results in this (only showing new files), which is fine.
app/
proj1.exe
sources/Proj1.Tests/bin/Release/
proj1.exe
proj1.tests.dll
But building it with msbuild Complete.sln /p:OutputPath="$pwd/build" /t:BuildAll results in following.
app/build/
proj1.exe
proj1.tests.dll
Is there a way without changing solution or project files to get the following?
app/build/
proj1.exe
app/tests/
proj1.exe
proj1.tests.dll
I.e. I want to set the OutputPath for every *.Tests.csproj to /tests, and for every other project to /build.
Alternatively, is there a way to call msbuild Complete.sln in such a way it builds either all the projects from that solution with names that don't end with "Tests" or only those that do?
The Directory.Solution.targets mentioned above (using it for reasons) looks like following.
<Project>
<Target Name="SetSkip">
<ItemGroup>
<ProjectReference Update="*">
<SkipNonexistentProjects>Build</SkipNonexistentProjects>
</ProjectReference>
</ItemGroup>
</Target>
<Target Name="BuildAll" DependsOnTargets="SetSkip">
<CallTarget Targets="Build"/>
</Target>
</Project>
UPDATE since the number of files grows, for easier testing I've created a repository.
You could try adding the following to Directory.Build.targets (I have not tested it, but it should work):
<PropertyGroup>
<OutputPath Condition="'$(BuildOutputPath)' != ''
and !$(MSBuildProjectName.EndsWith('.Test'))">$(BuildOutputPath)</OutputPath>
<OutputPath Condition="'$(TestOutputPath)' == ''
and $(MSBuildProjectName.EndsWith('.Test'))">$(TestOutputPath)</OutputPath>
</PropertyGroup>
Then invoke msbuild like so:
msbuild Complete.sln /p:TestOutputPath="$pwd\tests" /p:BuildOutputPath="$pwd\build"
There would be other options, like putting the required build or tests paths directly in the properties.

MSbuild style cop extensions task to run on solution

I need help in running stylecop task on all cs files included in solution.
Please let me know if its possible and how?
Right now I can run it on a file, but not on solution.
<CreateItem Include="$(RootPath)\**\*.cs">
<Output TaskParameter="Include" ItemName="StyleCopFiles"/>
</CreateItem>
<MSBuild.ExtensionPack.CodeQuality.StyleCop
TaskAction="Scan"
ShowOutput="true"
ForceFullAnalysis="true"
CacheResults="false"
SourceFiles="#(StyleCopFiles)"
logFile="$(OutDir)\StyleCopLog.txt"
SettingsFile="$(MSBuildStartupDirectory)\..\Settings.StyleCop"
ContinueOnError="false">
<Output TaskParameter="Succeeded" PropertyName="AllPassed"/>
<Output TaskParameter="ViolationCount" PropertyName="Violations"/>
<Output TaskParameter="FailedFiles" ItemName="Failures"/>
</MSBuild.ExtensionPack.CodeQuality.StyleCop>
Have you considered automatically running StyleCop rules as a part of your project build process? This won't run all rules at the solution level but at a project level. I prefer this approach because the rules will run whenever you build your project/solution and will display as Warnings in the Error List panel (double click to navigate to the offending line of code). Configuring this on a project by project basis may seem like a pain but we have a different set of StyleCop rules for our Unit Test projects, and this allows us to configure them individually.
Also, You won't have to explicitly add a MSBuild task to your build script because building the projects will automatically execute the StyleCop rules.
It's also worth noting that I'm using the NuGet Package: StyleCop.MSBuild (version 4.7.17.1) and using a relative path to reference the package from within my .csproj file like this:
<Project>
<Import Project="..\Packages\StyleCop.MSBuild.4.7.17.1\tools\StyleCop.targets" />
</Project>
http://stylecop.codeplex.com/wikipage?title=Running%20StyleCop%20in%20VS2005%20or%20VS%20Express&referringTitle=Documentation
You can also set conditions on when you want the rules to run. If the condition evaluates to false StyleCop will not run. We use the condition to suppress StyleCop when running Unit Tests
<Project>
<Import Project="..\Packages\StyleCop.MSBuild.4.7.17.1\tools\StyleCop.targets" Condition="'$(NCrunch)'!='1'" />
</Project>
In order to configure StyleCop rules, you will need to install StyleCop_v4.7.17.0.msi. We only define a single Settings.StyleCop file (Parent Settings File) for our entire codebase.
http://stylecop.codeplex.com/wikipage?title=Sharing%20StyleCop%20Settings%20Across%20Projects&referringTitle=Documentation

Changing EXE name based on compilation constant

I have a project in VB.NET 2010 (compiling to x86, .NET 2.0 runtime) that I want to compile into two separate EXEs - a "lite" version and a "full" version.
Unfortunately I cannot make two separate projects as it uses the Adobe Reader COM control - and sharing a form using that control between two projects seems to confuse the IDE (something to do with COM Interop, I assume - if someone knows how to share a form hosting the adobe reader control, that would solve my problem too).
I have found this thread:
Change name of exe depending on conditional compilation symbol however I don't have any MSBuild experience so I need more explicit instructions.
On the "My Project>Compile" tab there is a "Build Events..." button. I was wondering if anyone knows how to set a conditional compilation constant and use that to determine the EXE name (or change it after build).
If all else fails I can rename the EXE manually I suppose, but I'd prefer it to be automated.
If having two separate projects within your solution isn't acceptable, you'll want to look into creating your own MSBuild script.
Here is an example of a custom MSBuild script that will allow you to define your custom compilation constants at build time, and then build your two versions of your application ("Full" and "Lite"):
<Project DefaultTargets="BuildAll" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<BuildVersionFull>FULL</BuildVersionFull>
<BuildVersionLite>LITE</BuildVersionLite>
</PropertyGroup>
<ItemGroup>
<Projects Include="$(MSBuildProjectDirectory)\MyApp.vbproj" />
</ItemGroup>
<Target Name="BuildAll" DependsOnTargets="BuildFull;BuildLite" />
<Target Name="BuildFull">
<MSBuild Projects="#(Projects)" Properties="DefineConstants=$(BuildVersionFull);OutputPath=binFull\;BaseIntermediateOutputPath=objFull\;AssemblyName=MyApp_Full" />
</Target>
<Target Name="BuildLite">
<MSBuild Projects="#(Projects)" Properties="DefineConstants=$(BuildVersionLite);OutputPath=binLite\;BaseIntermediateOutputPath=objLite\;AssemblyName=MyApp_Lite" />
</Target>
</Project>
What you'll need to do:
Create a new file and save it the same directory as your application's project file as "MyBuild.xml".
Change to reflect the name of your application's project file.
Open the Visual Studio Command Prompt and run "msbuild ".
Within your project, you can use the "FULL" and "LITE" conditional compilation constants to determine whether to compile certain statements:
#If FULL Then
' Compile code for the "Full" version.
#End If

Preventing MSBuild from building a project in a .sln without using Solution Configurations

I want to inhibit the building of certain projects within a solution from building (within a TeamCity Build Configuration in order to optimize the speed of my Commit Build feedback if you must know).
I'm aware of the Solution Configurations mechanism but don't want to have to force lots of .sln files to end up with every permutation of things I want to be able to switch off. I have Convention based rule where I want to say "If I'm doing the Commit Build, I dont want to do the final installer packaging". (And I don't want to break it out into a separate solution).
I'd prefer not to use a solution involving find and replace in the .sln file or in a .proj file created via [MsBuildEmitSolution][1]. I'm aware of questions here which cover the out of the box solution and this slightly related question.
I see MSBuild /v:diag is saying:
2>Target "Build" in file "Z.sln.metaproj" from project "Z.sln" (entry point):
Using "MSBuild" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "MSBuild"
Global Properties:
BuildingSolutionFile=true
CurrentSolutionConfigurationContents=<SolutionConfiguration>
<ProjectConfiguration Project="{C83D035D-169B-4023-9BEE-1790C9FE22AB}" AbsolutePath="X.csproj" BuildProjectInSolution="True">Debug|AnyCPU</ProjectConfiguration>
<ProjectConfiguration Project="{15E7887D-F1DB-4D85-8454-E4EF5CBDE6D5}" AbsolutePath="Y.csproj" BuildProjectInSolution="True">Debug|AnyCPU</ProjectConfiguration>
</SolutionConfiguration>
So the question is:
Is there a neat way of me getting to do an XPath replace or similar to have the effect of changing BuildProjectInSolution="True" to BuildProjectInSolution="False" for Project Y above
Failing that, is there a relatively simple edit I can do within a .ccproj (An Azure 1.4 Package) or a .csproj (a general project) file to cause the effects (including triggering of dependent projects) of the project being enabled within a commandline msbuild Z.sln solution build to be nullified?
Not sure it qualifies as neat, but you can set CustomAfterMicrosoftCommonTargets to import an msbuild file to over-ride the BuildDependsOn property, pointing it to your own custom build task. Basically, by setting CustomAfterMicrosoftCommonTargets you get msbuild to import an msbuild file containing the following:
<PropertyGroup>
<OldBuildDependsOn>$(BuildDependsOn)</OldBuildDependsOn>
<BuildDependsOn>MyBuild</BuildDependsOn>
</PropertyGroup>
<Target Name="OldBuild" DependsOnTargets="$(OldBuildDependsOn)" />
<Target Name="MyBuild">
<CallTarget Targets="OldBuild" Condition="<IfIWantThis>" />
</Target>
Edit
You can use the following MyBuild target to Include/Exclude projects based on regular expressions passed in as IncludeInBuild and ExcludeFromBuild properties. (If you want complex regexes, you may fall foul of MSBuild special character escaping, but this works well enough for simple matching)
> msbuild /p:ExcludeFromBuild="Tests|Install|Azure"
<Target Name="MyBuild">
<CallTarget Targets="OldBuild" Condition="('$(IncludeInBuild)'=='' OR
'$([System.Text.RegularExpressions.Regex]::IsMatch($(MSBuildProjectFullPath),
$(IncludeInBuild),
System.Text.RegularExpressions.RegexOptions.IgnoreCase))'=='True') AND
('$(ExcludeFromBuild)'=='' OR
'$([System.Text.RegularExpressions.Regex]::IsMatch($(MSBuildProjectFullPath),
$(ExcludeFromBuild),
System.Text.RegularExpressions.RegexOptions.IgnoreCase))'=='False')" />
</Target>
You could always pass the particular projects you want to build as parameters to the MSBuild.
The MSBuild command line would look like this:
MSBuild /t:<Project Name>:Rebuild;<Another Project Name>:Rebuild
In TeamCity, you would put <Project Name>:<Target Action> in the target field in the MSBuild runner.
I add a system parameter under Parameters
Name: system.ExcludeFromBuild
Kind: System property (system.)
Value: path to your csproj

How to always execute a target in MSBuild

I have an MSBuild file that manipulates the AssemblyInfo file before the application is compiled. At the end of the build, it restores the AssemblyInfo file. It does this by backing up the file, manipulating it, and then after build time, restoring the file.
This works fairly well except when an error occurs during the build. It then does not restore the original file. Is there a way I can tell MSBuild to execute a target at the end of a build no matter if it succeeded or failed?
Based on your last comment to the original question I would take another approach, and forget the approach you are currently taking. You should know that your version info doesn't have to be in the AssemblyInfo.cs file. It can be in any code file, just as long as you only have attributes AssemblyVersion and AssemblyFileVersion defined once each. With that being said what I would do is follow these steps:
Remove AssemblyVersion & AssemblyFileVersion from AssemblyInfo.cs
Create a new file, name it whatever you want want in my case I put it at Properties\VersionInfo.cs. Do not add this file to the project.
Edit the project file to include that file into the list of file to be compiled only when you want it
Let's expand a bit on #3. When you build a .NET project, the project itself is an MSBuild file. Inside that file you will find an item declared Compile. This is the list of files that will be sent to the compiler to be compiled. You can dynamically include/exclude files from that list. In you case you want to include the VersionInfo.cs file only if you are building on the build server (or whatever other condition you define). For this example I defined that condition to be if the project was building in Release mode. So for Release mode VersionInfo.cs would be sent to the compiler, and for other builds not. Here are the contents of VersionInfo.cs
VersionInfo.cs
[assembly: System.Reflection.AssemblyVersion("1.2.3.4")]
[assembly: System.Reflection.AssemblyFileVersion("1.2.3.4")]
In order to hook this into the build process you have to edit the project file. In that file you will find an element (maybe more than 1 depending on project type). You should add a target similar to the following there.
<Target Name="BeforeCompile">
<ItemGroup Condition=" '$(Configuration)'=='Release' ">
<Compile Include="Properties\VersionInfo.cs" />
</ItemGroup>
</Target>
Here what I've done here is to define a target, BeforeCompile, which is a well-known target that you can override. See this MSDN article about other similar targets. Basically this is a target which will always be called before the compiler is invoked. In this target I add the VersionInfo.cs to the Compile item only if the Configuration property is set to release. You could define that property to be whatever you wanted. For instance if you have TFS as your build server then it could be,
<Target Name="BeforeCompile">
<ItemGroup Condition=" '$(TeamFoundationServerUrl)'!='' ">
<Compile Include="Properties\VersionInfo.cs" />
</ItemGroup>
</Target>
Because we know that TeamFoundationServerUrl is only defined when building through TFS.
If you are building form the command line then something like this
<Target Name="BeforeCompile">
<ItemGroup Condition=" '$(IncludeVersionInfo)'=='true' ">
<Compile Include="Properties\VersionInfo.cs" />
</ItemGroup>
</Target>
And when you build the project just do msbuild.exe YourProject.proj /p:IncludeVersion=true. Note: this will not work when building a solution.
What about changing the problem:
Add a "template" AssemblyInfo.cs.template to version control that represents your "ideal" AssemblyInfo.cs with regex hooks in there
Before build, copy the template to the real and apply your regexes
Add some kind of subversion ignore for AssemblyInfo.cs (I'm no svn expert, but I'm pretty sure there is a way you can tell it to ignore certain files)
In the event that your devs need to add some kind of customization that would normally appear in an AssemblyInfo.cs (eg InternalsVisibleTo), then get them to add it to a different .cs file that IS checked in.
As a further refinement, combine Sayed's solution with mine and remove version info stuff from the actual AssemblyInfo.cs and have a VersionInfo.cs.template that is checked in, that creates a VersionInfo.cs in BeforeBuild.
I never used it, but from the documentation it seems that the OnError Element is useful to what you're trying to achieve.
Causes one or more targets to execute,
if the ContinueOnError attribute is
false for a failed task.