Try dotnet-project-file-analyzers by sungam3r · Pull Request #143 · destructurama/attributed

sungam3r · 2024-12-23T13:18:43Z

No description provided.

Corniel · 2024-12-23T14:06:31Z

Nice that you want to use the .NET project file analyzers!

Two tips:

Those rules should be applied on on MS build project files, not only those who are publisable.
Consider using our SDK as a replacement for Solution Items in your solution file.

Corniel · 2024-12-23T14:07:17Z

    <ImplicitUsings>enable</ImplicitUsings>
    <SignAssembly>true</SignAssembly>
    <AssemblyOriginatorKeyFile>../../assets/Destructurama.snk</AssemblyOriginatorKeyFile>
+    <NoWarn>$(NoWarn);Proj0003;Proj0010;Proj0028;Proj0200;Proj0201;Proj0205;Proj0206;Proj0208;Proj0213;Proj0214;Proj0215;Proj0216;Proj0240;Proj0243;Proj0400;Proj0800;Proj1001;Proj1003;</NoWarn>


If you want to disable these, you better use a .globalconfig file.

I prefer to use editorconfig for all projects I participate of. For now it's just a first attempt to use analyzer. I evaluate pros and cons. My goal is to find reasonable set of diagnostics and those ones that have a little value.

I prefer to use editorconfig for all projects I participate of. For now it's just a first attempt to use analyzer. I evaluate pros and cons. My goal is to find reasonable set of diagnostics and those ones that have a little value.

That is true. However, MS itself states that the configuration of files should be specified in the .globalconfig instead of the .editorconfig. Some rules (including the of .NET project file analyzers) can not be configured in .editorconfig, but can be configured in .globalconfig.

MS itself states that the configuration of files should be specified in the .globalconfig instead of the .editorconfig

Could you please point to the relevant documentation?

The link can be found here:

https://dotnet-project-file-analyzers.github.io/general/configuration.html

sungam3r · 2024-12-23T15:49:37Z

@Corniel regarding

Those rules should be applied on on MS build project files, not only those who are publisable.

What do you mean? I added analyzer into Directory.Build.props applying it to all projects.

Consider using our SDK as a replacement for Solution Items in your solution file.

I've read about it. For now it looks like rather invasive solution. I would not want to lose the usual structure of many projects without good reason.

Corniel · 2024-12-23T16:20:02Z

What do you mean? I added analyzer into Directory.Build.props applying it to all projects.

<ItemGroup Condition="'$(IsPackable)' == 'true'">
    <PackageReference Include="DotNetProjectFile.Analyzers" Version="1.5.2" PrivateAssets="all" />
    <PackageReference Include="Microsoft.SourceLink.GitHub" Version="8.0.0" PrivateAssets="All" />
    <PackageReference Include="MinVer" Version="6.0.0" PrivateAssets="All" />
  </ItemGroup>

So, the DotNetProjectFile.Analyzers are now only applied on projects that are packable.

I've read about it. For now it looks like rather invasive solution. I would not want to lose the usual structure of many projects without good reason.

I have to admit that is the response I got quite often when suggesting it. And when I came up with the idea, it really felt like it. But in practice, you get a way less cumbersome solution file, and an easy to maintain container project just for files shared by the solution. That being said, if you want to give it a try, you probably should do it in a separate PR.

sungam3r · 2024-12-23T16:42:58Z

So, the DotNetProjectFile.Analyzers are now only applied on projects that are packable.

ooops, my oversight

sungam3r · 2024-12-23T16:48:13Z

But in practice, you get a way less cumbersome solution file, and an easy to maintain container project just for files shared by the solution.

I doubt it very much, especially in the words less cumbersome solution file. I do not see difficulty in the current project format. What cumbersome solution file are you talking about?

That being said, if you want to give it a try, you probably should do it in a separate PR.

Could you please provide PR to demonstrate so I can evaluate?

sungam3r · 2024-12-23T16:49:00Z

I have to admit that is the response I got quite often when suggesting it.

Yep, I expected such an answer.

Co-authored-by: Corniel Nobel <corniel@gmail.com>

# Conflicts: # src/Directory.Build.props

sungam3r · 2024-12-23T16:56:50Z

That being said, if you want to give it a try, you probably should do it in a separate PR.

Honestly I do not understand what I will get.

github-actions · 2025-01-23T01:02:34Z