-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
editorconfig c# language rules doesn't trigger build failure #33558
Comments
Currently IDE code style rules do not apply during builds. We are actively working to make these analyzer available during compilation scenarios, at which point errors would cause the build to fail. |
Suppose this work would enable usage of IDE analyzers from MsBuild alone. Is that right? I am using ruleset file with IDE analyzer settings and I was just trying to enable this scenario and it was really messy experience.
|
@kindermannhubert Analyzers are not allowed to reference |
And is there (will be) any way to enable IDE analyzers while building with MsBuild? |
@kindermannhubert see dotnet/roslyn-sdk
This is will give you several templates that will allow you to get started This template can create a nuget package that can be installed and run via 'msbuild' |
You can find some examples here |
You probably misunderstand me. I know how to create and use custom analyzers (even from msbuild). |
@kindermannhubert there is no difference. Those analyzers have Id that start with "IDE" by convention but there is nothing special about most of them. Can you be more specific about what you are trying to do? |
@kindermannhubert Correct, if you want analyzers to fail your commandline build they need to be given to the commandline compiler. As you pointed out, once way to do this is to reference the dll directly <Analyzer Include="somePathToAnalyzer\CustomAnalyzer.dll" /> Another alternative is to create an analyzer nuget package and reference it in your project file <PackageReference Include="CustomAnalyzer" Version="1.0.0" /> However if you reference IDE assemblies in an analyzer that is run by the commandline compiler it will not work. This is by design. The compiler does not load all of Visual Studios dlls in order to build. If this scenario is important to you I would file a new issue on this repo. |
I've tried <PackageReference Include="Microsoft.CodeAnalysis.CSharp.Features" Version="3.0.0" /> it doesn't do anything. |
|
@jmarolf Don't think so. It's full of analyzers.. |
@kindermannhubert It contains analyzer types but they are not setup to be consumed in any fashion other than being installed into the Visual Studio IDE. |
upvote! We added a |
@jmarolf I believe @kindermannhubert is requesting that we move all the in-built IDE analyzers into a separate assembly which can be consumed via a NuGet package, just like regular third party analyzers. Currently, the analyzers in the IDE layer (i.e. MS.CA.Features.dll) have lot of internal dependencies, primary ones being the options infrastructure which is tied to the Workspace. Hence these cannot be consumed through any NuGet package or even referencing MS.CA.Features.dll directly as an Analyzer item group in your project. @sharwell has created a separate CodeStyle project and NuGet package within Roslyn.sln, which currently only has the formatting analyzer, but is consumable as an analyzer NuGet package. He is also working on porting individual IDE style analyzers into this package, so then can be consumed as a NuGet package and enabled in CI - .editorconfig support in compiler is a critical step, and now that it is in place, we hope to start tackling one analyzer at a time to move it into this package. |
So it should work? I tried the following code, but I don't get any build errors when running
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;
namespace ELJ
{
public static class Program
{
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>();
}
} |
Hey folks, any progress on this? This would be extremely useful |
There are some design issues that need to be tackled to lay the foundation before the analyzers can be moved to a NuGet package: #38480 |
EDIT: For people arriving in the future, before doing anything with this comment, be sure to read the one directly below it. @klausenbusk A comment under a related issue indicated that you also need a
With that, my build has started to fail on code formatting errors. You could of course also configure it as
Then it would not affect the build. EDIT: By that I mean, it only shows the error level defined in the |
@ElteHupkes That comment is outdated. Starting with the 16.3 release, can now set the severity of IDE0055 (or any other rule) via a .editorconfig file.
|
Yes, see official documentation with screenshots on how to do the same using lightbulb: https://docs.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#set-rule-severity-in-an-editorconfig-file |
CodeStyle analyzer assemblies are now directly inserted into the .NET5 SDK (will need VS2019 16.8 Preview4 or later and .NET5 RC2 SDK or later, once both of these are released). You will not need to install any special analyzer NuGet package to enable code style enforcement in build if you are on the required .NET SDK and VS. Also note that you don't need your project TargetFramework to be Official documentation with the steps to enable build time code style enforcement is at https://docs.microsoft.com/dotnet/fundamentals/productivity/code-analysis#code-style-analysis. I am going to close this issue as no further feature work is required, please file separate Rolsyn issue(s) for anything that does not work as expected and doc issues at the above page if you need more clarity on documentation. |
- Invalid Property Naming convention will now throw an error instead of a warning, which will make it impossible to build locally (usage as a Linter). However the build will still succeed on the GitHub workflow due to [this issue that has to be resolved by Microsoft](dotnet/roslyn#33558) - Disabled the XML comments, it's handy but not always needed at this point. Co-authored-by: Benjamin Vertonghen <[email protected]>
This thread mentions I've raised https://github.com/dotnet/roslyn-analyzers/issues/4429 to document the categories of rules that we can set a severity for and also to ask if we can set a default severity for all categories. |
@RehanSaeed Setting default severity for all analyzer diagnostics is documented here: https://docs.microsoft.com/dotnet/fundamentals/code-analysis/configuration-options#scope |
Maybe I misunderstand, but with SDK
Until, that is, I add this package reference: <PackageReference Include="Microsoft.CodeAnalysis.CSharp.CodeStyle" Version="3.8.0" /> |
@chucker You have 2 options to enforce code style analyzers on build:
|
I have configured some Code Style / Naming rules (configured as warning/error) within the Option dialog from Visual Studio. As described I added a nuget reference to Mircosoft.CodeAnalysis.CSharp.CodeStyle (3.8.0) for all projects. The build still does not fail. I also exported the editorconfig from Visual Studio and placed it in the solution folder. I have Visual Studio 16.8.5 installed and the project (old style: sln/csproj) is using .net framework 4.7.2 What am I doing wrong? |
@mavasani, I have the same issue as @ChristianHoe. I'm targeting |
@ChristianHoe I believe the core issue for you is that you are setting the IDExxxx rule severities in the Options Dialog in VS. The settings in this dialog are user specific, not something that gets enforced on build (repo specific). For setting repo specific severities that get enforced in build, you need to create a .editorconfig file and add entries to this file to escalate IDE diagnostics to warning/error severity. See https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files for creating repo-specific configuration files @ryanbuening That project file seems correct way to enable code style enforcemet on build. Again, does your repo/project actually have an .editorconfig file with IDE0011 entry with severity warning/error? Basically, did you folks follow the step 2 at https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview#enable-on-build? |
@mavasani I see now. I had the following in my .editorconfig file:
which showed the
the build does fail. Thanks for explaining. |
In my case with .net5 I was forced to remove |
@rafalschmidt97 are you still using the SDK version? I have the same problem but would really want to use the NuGet so it's consistent across all environments, regardless of the .NET version being installed. |
any solution for Target Framework 4.x.x or earlier? |
Try adding the package: #33558 (comment) |
i did.
|
do you have a list of the Nuget needed for the Analyzer? i keep getting more and more errors on dependent Nugets (using private ADO artifactory) |
Just gave it another try: VS 16.11.2 & .net framework 4.7.2 & old project style files (csproj, sln) Added nuget: Microsoft.CodeAnalysis.CSharp.CodeStyle 4.0.1 Like liranelisha only lots of warnings:
|
- Invalid Property Naming convention will now throw an error instead of a warning, which will make it impossible to build locally (usage as a Linter). However the build will still succeed on the GitHub workflow due to [this issue that has to be resolved by Microsoft](dotnet/roslyn#33558) - Disabled the XML comments, it's handy but not always needed at this point. Co-authored-by: Benjamin Vertonghen <[email protected]>
- Invalid Property Naming convention will now throw an error instead of a warning, which will make it impossible to build locally (usage as a Linter). However the build will still succeed on the GitHub workflow due to [this issue that has to be resolved by Microsoft](dotnet/roslyn#33558) - Disabled the XML comments, it's handy but not always needed at this point. Co-authored-by: Benjamin Vertonghen <[email protected]>
This still does not work in 2022: https://stackoverflow.com/q/78951936/480982 |
I have the following C# document
when I apply the following rules to it:
non of the rules marked with "error" action is triggered during the build in Visual Studio.
Only if I change action to error" for dotnet_style_predefined_type_for_locals_parameters_members the build fails
This issue has been moved from https://developercommunity.visualstudio.com/content/problem/433321/editorconfig-c-language-rules-doesnt-trigger-build.html
VSTS ticketId: 775762
These are the original issue comments:
Visual Studio Feedback System on 2/17/2019, 04:12 AM (4 days ago):
This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
These are the original issue solutions:
(no solutions)
The text was updated successfully, but these errors were encountered: