For instance, download and extract the attached zip file, then run dotnet build in the root.
The code analysers should only be run for the project to which they've been added.
Running dotnet build in the root of the attached MCVE project should produce no FxCop warnings from the test project.
Warnings are generated by the code analyser for the second project.
In the attached example, we get three FxCop advisories (as build warnings) from the test project. This is despite the test project having no references to the FxCop nuget package.
dotnet msbuild -version
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.15.7.179.6572
And I'm running the dotnet CLI on Windows 10.
msbuild /version
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.15.9.20.62856
He's running it in Visual Studio 17 on Windows 10
@tmat @jinujoseph I believe this is more about how roslyn analyzers work than msbuild proper.
Could you provide some guidance here or maybe a more appropriate repo recommendation?
@livarcocc Apologies if this isn't quite the right place. I umm-ed and ah-ed about it. Happy to migrate it if appropriate.
to cross-link, this is the related SO question: https://stackoverflow.com/questions/53585175/any-idea-why-msbuild-would-suddenly-start-performing-code-analysis-on-other-proj
@livarcocc Reckon it's worth me cross-posting to the roslyn-analyzers repo?
~I think this is a NuGet question; I'll move it there.~
The NuGet docs indicate that packages should have PrivateAssets="contentfiles;analyzers;build" by default, which I interpret as meaning that analyzers shouldn't flow to projects that ProjectReference a project that references a package with analyzers. But I see Microsoft.CodeAnalysis.FxCopAnalyzers and its dependencies in Tests\obj\project.assets.json in the repro project. Its presence there is why it's getting used at build time.
Duplicate of https://github.com/dotnet/sdk/issues/968
@tdwright There's a workaround that will probably work for you in https://github.com/dotnet/sdk/issues/968#issuecomment-410319090.
@rainersigwald Thanks! Just tried that workaround and it did the job. 馃榿