Hello,
I'm using Visual Studio Enterprise 2017 Preview Version 15.3.0 Preview 4.0 (VisualStudio.15.Preview/15.3.0-pre.4.0+26711.1)
When I try to run code analysis using MSBuild for any .NET Core 2.0 or .NET Standard 2.0 projects using a command like this:
msbuild /p:RunCodeAnalysis=true netcore2ClassLibrary1.csproj
I'm getting the following errors:
Running Code Analysis...
MSBUILD : error : CA0055 : Could not identify platform for 'E:\Source\Temp\NetS
tandardClassLibrary1\netcore2ClassLibrary1\bin\Debug\netcoreapp2.0\netcore2Clas
sLibrary1.dll'. [E:\Source\Temp\NetStandardClassLibrary1\netcore2ClassLibrary1\
netcore2ClassLibrary1.csproj]
MSBUILD : error : CA0052 : No targets were selected. [E:\Source\Temp\NetStandar
dClassLibrary1\netcore2ClassLibrary1\netcore2ClassLibrary1.csproj]
Code Analysis Complete -- 2 error(s), 0 warning(s)
Is this an expected behaviour? If yes, is there any other way to run code analysis for .NET Core/Standard 2.0 projects from a command line and produce the same kind of CodeAnalysisLog.xml file which is produced by MSBuild for .NET Framework projects? (I need it for our CI, for a solution which consists of a large set of old .NET Framework projects and some new .NET Standard projects as well)
Thanks
Max
@mizbrodin I have this problem, too,but I think you can use jetbrains rider instead。did you solved the problem?
@mokeyish I don't have a solution for this problem yet.
Our company doesn't have a license for JetBrains Rider and, at the moment, I don't know anything about this IDE and its build tools. We have Visual Studio Enterprise licenses as part of our MSDN Subscription and I'd prefer to be able to use MSBuild for running code analysis in our CI build configuration as we do it for other projects.
Hi All, We are facing similar issue. Any workaround or solution, Also I additional observation, while compile with "netstandard2.0" as "TargetFramework", generated assembly Platform Target coming as Unknown while with "netstandard1.4" its coming as "Windows Runtime".
Same issue here.
It seems to me static code analysis is very fuzzy, or I just used to the existing full framework FxCop solution
Same issue here.
Same problem.
same issue here.
I have Visual Studio 2017 (15.2) and a .NetStandard core library project.
Are there any plans to address this? Any other options for running FxCop against .NET core projects?
I have a feeling that Microsoft will not continue to support FxCop. Rather, it's expected that you install Microsoft.CodeAnalysis.FxCopAnalyzers NuGet package to your solution and it will run the code analysis via Roslyn API. Actually, they are cooler than FxCop as they:
See more detail here: https://github.com/dotnet/roslyn-analyzers.
Notice, not all the analyzers have been already ported, so it might still make sense to run code analysis for the supported frameworks (e.g. net 452).
@zvirja Do you know if the Nuget package respects the CodeAnalysis MSBuild configuration settings like <RunCodeAnalysis>false</RunCodeAnalysis>, CodeAnalysis dictionarys and the ruleset files?
I've used this package in the AutoFixture project and it seems to respect everything you mentioned.
@zvirja is correct. The path forward is the Microsoft.CodeAnalysis.FxCopAnalyzers NuGet package. A large portion of the rules have been moved over to analyzers. FXCop was a solution implemented before the richness of the new C# compiler existed.
Thanks all I'll give the package a try today.
Sounds good. I'm going to close this for now but we can re-open this if it doesn't work.
Please let me know Is this CA0055 and CA0052 issues got resolved for .Net Core 2.0 (netcoreapp2.0) projects?
Asking this because I'm still getting these errors when enabled our .Net Core 2.0 projects to use code analysis ruleset which are defined for our projects and trying to build from Visual Studio 2017 (updated to 15.3.5 version) and by using MSBuild command.
As per this conversion thread, I've installed Nuget package of Microsoft.CodeAnalysis.FxCopAnalyzers to our .net core 2.0 projects, but still getting CA0055 and CA0052 errors. Please help me out to resolve these issues which are blocking our builds.
@dvm-2k1 I opened an issue for you here: https://github.com/dotnet/roslyn-analyzers/issues/1313
Thats is the best place to get help for that specific issue.
same here.
@Petermarcu has anyone committed to fixing this issue?
Why is this issue closed? It's still a problem.
The other closed issue says that we need to install a NuGet package and compile at the command line.
Is anyone actually bothering to fix the problem inside Visual Studio?
This is still an issue.
@AlexanderJ-ULabs Your version of Visual Sdtudio and dotnet core might not be latest enough.
I came across the same problem when having a solution mixed with .NET Full (non-SDK style projects) and .NET Standard projects (SDK style projects).
I fixed it by adding following _custom_ target at the end of the project (I actually created a shared targets file which I imports in each SDK style project):
<Target Name="IgnoreRunCodeAnalysis" Condition=" '$(RunCodeAnalysis)' == 'true' " BeforeTargets="RunCodeAnalysis">
<Message Importance="normal" Text="Set RunCodeAnalysisOnThisProject to false" />
<PropertyGroup>
<RunCodeAnalysisOnThisProject>false</RunCodeAnalysisOnThisProject>
</PropertyGroup>
</Target>
If you want code analysis, you can include the (nuget) package Microsoft.CodeAnalysis.FxCopAnalyzers. I did it like below (in my project files), so I can still leverage the global property RunCodeAnalysis:
<ItemGroup Condition=" '$(RunCodeAnalysis)' == 'true' ">
<PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.6.1" />
</ItemGroup>
The idea of replacing the legacy FXCop tooling built into Visual Studio with the NuGet package makes good sense to me. That said, ideally, developers wouldn’t need to Google this error and find this thread to understand the problem. Instead, the tooing should detect the incompatibility and suggest the upgrade path to the user. (Fully recognizing that this level of tooling is likely outside the scope of the team maintaining this repository.)
This article seems pretty relevant:
https://docs.microsoft.com/en-us/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2017
@Petermarcu
I just added the FX Cop Analyzers NuGet package to my project, and I can see that it does add new errors to the build output. So, I promoted warning to errors, and I get similar errors to those that used to exist in the Visual Studio code rules in the old csproj format, but the issue at first glance is that I can't choose which errors to turn on or off. I have to type them in the suppress field. That's pretty fiddly. Using a suppress puts a pragma in the code which isn't so nice.
Can we get some kind of explanation and history for why Visual Studio has gone down this path? Is it so that code rules could be supported on other platforms like Visual Studio for Mac?
I've written a blog article on how to use the code rules here: https://christianfindlay.wordpress.com/2019/02/11/c-code-rules-part-1/ . I'd really appreciate some feedback, and if someone would write up why FxCop as a command line app is not the recommended approach anymore, I'd be glad to append it to the blog post.
@MelbourneDeveloper I recommend to ask on the https://github.com/dotnet/roslyn-analyzers repo
Regarding VS for Mac - that's a good question, I'd ask them on their feedback channel.
@karelz yep, that's already been asked here:
https://github.com/dotnet/roslyn-analyzers/issues/2026
@MelbourneDeveloper ok, so you should be all set then, right?
@karelz when they answer the question, yeah.
@MelbourneDeveloper understood - my point is that the discussion over here is "finished" and all is properly routed / addressed. If not, please let me know.
@karelz , I understand that there is a path from migrating from the FxCop tool, to the Roslyn Analyzer NuGet package. Basically, it's not finished, and it's not completely integrated in to Visual Studio, but for now, people have some level of code rules. The issue is already closed, so I don't think there's anything to be said for this particular question.
Most helpful comment
I came across the same problem when having a solution mixed with .NET Full (non-SDK style projects) and .NET Standard projects (SDK style projects).
I fixed it by adding following _custom_ target at the end of the project (I actually created a shared targets file which I imports in each SDK style project):
If you want code analysis, you can include the (nuget) package Microsoft.CodeAnalysis.FxCopAnalyzers. I did it like below (in my project files), so I can still leverage the global property RunCodeAnalysis: