Use .NET project files analyzers #145

Corniel · 2024-12-23T19:20:19Z

Including the use of the SDK.

Note that the solution file (and Directory.Build.props) have been move a dir up, so that all things inlcuded are not below the specfied root level).

sungam3r · 2024-12-24T12:49:31Z

Thanks, @Corniel . I will try to formulate my questions regardless of numerous changes, leading (in my opinion) to clogging projects with excessive settings.

I see new (pseudo) project without any code. As you said

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.

So am I understand correctly that the whole purpose of that container/pseudo project is to be available to your analyzer/sdk?

I see you added <NoWarn>$(NoWarn);NU1504</NoWarn> in .net.csproj. Without it I see Duplicate 'PackageReference' items found. Remove the duplicate items or use the Update functionality to ensure a consistent restore behavior. The duplicate 'PackageReference' items are: DotNetProjectFile.Analyzers 1.5.3, DotNetProjectFile.Analyzers 1.5.3. Why so? How to organize references correctly so that you do not have to write NoWarn?
I see Define usings explicit. (https://dotnet-project-file-analyzers.github.io/rules/Proj0003.html) regardless of dotnet_diagnostic.Proj0003.severity = none configured in .globalconfig. Why?
I see This <TargetFramework> will be ignored due to the earlier use of <TargetFrameworks>. (https://dotnet-project-file-analyzers.github.io/rules/Proj0027.html) because of

<PropertyGroup Condition="'$(OS)' != 'Windows_NT'">
  <TargetFramework>net9.0</TargetFramework>
</PropertyGroup>

But when I change it to TargetFrameworks then I see Use the <TargetFramework> node instead. (https://dotnet-project-file-analyzers.github.io/rules/Proj0009.html). Is this a bug?

Also I see 1>\attributed\src\.vs\destructurama-attributed\config\applicationhost.config(1,1,1,2): warning Proj3000: This file is using UTF-8 encoding with BOM. (https://dotnet-project-file-analyzers.github.io/rules/Proj3000.html). As I understand such files should not be analyzed at all, right?

Corniel · 2024-12-25T11:09:02Z

@sungam3r

Yes, in a nutshell that is the reason. It allows to define files that should be analyzed for multiple projects without to have to do it twice. As bonus, it shows files (such has markdown files, .githhub files and such, without to explicitly having to add it.
That is a bug/issue with the SDK project. It always includes the analyzer reference, even it that is already done by the Directory.Build.props. I have to find a way still to not to include if it already has been added.
I'm not sure why that happens, it should not be the case. I had it too.
FP's due to the fact that those rules do not take Condition into account.
Proj3000 checks aims to check all files, not only additional files. The goal is to ignore files that are excluded by .gitignore if possible, and files under bin/ and obj/ are already excluded.

Thanks for looking into this! It is a challenge to come with suggestions/rules that fit all project setups. It helps to further improve .NET project file analyzers.

As mentioned, 4 is a FP. But what is your reasoning to solve it like this? It might give inside in how to solve these kind of things? (I considered a rule that states that TargetFramework should not be conditional in the first place)

sungam3r · 2024-12-25T17:33:07Z

Proj3000 checks aims to check all files, not only additional files. The goal is to ignore files that are excluded by .gitignore if possible, and files under bin/ and obj/ are already excluded.

.gitignore contains .vs/, I got it, it was my old local folder after you have moved sln.

I considered a rule that states that TargetFramework should not be conditional in the first place

It is conditional rather often.

But what is your reasoning to solve it like this?

Like how? What do you mean? I just follow warning from analyzer.

Corniel · 2024-12-25T17:51:53Z

I considered a rule that states that TargetFramework should not be conditional in the first place

It is conditional rather often.

I can't recall to see it before. But that might have to do with working on projects with different characteristics.

But what is your reasoning to solve it like this?

Like how? What do you mean? I just follow warning from analyzer.

Purely out of interest: what is the reasoning to have different targets based on the OS?

The reasoning about having conditionals only on level 1 is that it should improve readability; when defined on level 2, the value of what is conditional tends to be harder to read. Although I admit that in case of TargetFramework/TragetFrameworks, that is not per se the case.

sungam3r · 2024-12-25T19:38:48Z

what is the reasoning to have different targets based on the OS?

It's simple - packaging and/or testing on available OS'es from GitHub Actions os matrix. You can't run tests in .NET Framework runtime on Ubuntu but on Windows you can.

Corniel · 2024-12-25T20:42:31Z

It's simple - packaging and/or testing on available OS'es from GitHub Actions os matrix. You can't run tests in .NET Framework runtime on Ubuntu but on Windows you can.

Fair point.

I'm still not sure what the best solution should be (recommended by the rule):

<PropertyGroup Condition="'$(OS)' == 'Windows_NT'">
    <TargetFrameworks>net8.0;netstandard</TargetFrameworks>
<PropertyGroup>
<PropertyGroup Condition="'$(OS)' != 'Windows_NT'">
    <TargetFramework>net8.0</TargetFramework>
</PropertyGroup>

Using a choose when:

<Choose>
  <When Condition="'$(OS)' == 'Windows_NT'">
    <PropertyGroup>
        <TargetFrameworks>net8.0;netstandard</TargetFrameworks>
    </PropertyGroup>
  </When>
  <Otherwise>
    <PropertyGroup>
        <TargetFramework Condition="'$(OS)'  != 'Windows_NT'">net8.0</TargetFramework>
    </PropertyGroup>
  </Otherwise>
 </Choose>

Or as you did:

<PropertyGroup>
    <TargetFrameworks Condition="'$(OS)' == 'Windows_NT'">net8.0;netstandard</TargetFrameworks>
    <TargetFramework Condition="'$(OS)'  != 'Windows_NT'">net8.0</TargetFramework>
</PropertyGroup>

In this case it seems the lesser of the evils. But should I take that into account in the rule, and how?

sungam3r · 2024-12-26T06:36:54Z

All variants are too verbose - less or more. I would completely ignore targetframework|s tags for this rule. I do not believe that anyone will bother changing well known simple approach living in codebases for ages.

Corniel · 2024-12-27T20:21:45Z

All variants are too verbose - less or more. I would completely ignore targetframework|s tags for this rule. I do not believe that anyone will bother changing well known simple approach living in codebases for ages.

I agree, I've made a proposal to solve this FP: dotnet-project-file-analyzers/dotnet-project-file-analyzers#257

github-actions · 2025-01-27T01:03:45Z

This pull request was marked as stale since it has not been active for a long time

Corniel · 2025-02-23T08:11:53Z

@sungam3r I think this should be okay to merge. There are some warnings left that I think are valid, but should not be merged with this PR (like that the package icon is advised to be 256x256).

sungam3r · 2025-03-03T09:24:11Z

src/Destructurama.Attributed/Destructurama.Attributed.csproj

    <RootNamespace>Destructurama</RootNamespace>
+    <IsPackable>true</IsPackable>
    <PolySharpIncludeRuntimeSupportedAttributes>true</PolySharpIncludeRuntimeSupportedAttributes>
+    <PackageId>Destructurama.Attributed</PackageId>


Suggested change

<PackageId>Destructurama.Attributed</PackageId>

The vast majority of the projects which I work on avoid this property.

dotnet-project-file-analyzers/dotnet-project-file-analyzers#389

sungam3r · 2025-03-03T09:25:17Z

src/Destructurama.Attributed/Destructurama.Attributed.csproj

+    <PackageReleaseNotes>
+      <![CDATA[
+v1.0
+- Migrated from Serilog.Extras.Attributed at serilog/serilog.
+]]>
+    </PackageReleaseNotes>


no, no, please, let's not clog configuration

@sungam3r How would you like to solve your release notes?

All release notes are in releases: https://github.com/destructurama/attributed/releases

They are generated/formatted automatically via GitHub when I publish release. Simply speaking it is not the best solution to put the history of releases inside the package itself (at least when you use GitHub releases expirience).

Do you know if it ignores the <ReleaseNotes> tag completealy? In that case, just adding a single statement there works perfectly as explanation on how it is solved. It should also be added to our documentation obviously.

What "it"? GitHub releases feature?

yep. SO bu just having <PackageReleaseNotes>Handled by GitHub release</PackageReleaseNotes> you should be fine.

Github release experience knows nothing about nuget/project structure.

Handled by GitHub release

It is nothing more that stub just to satisfy opionated rule, but OK, in such form it may have value, a little.

sungam3r · 2025-03-03T09:28:43Z

Directory.Packages.props

@@ -0,0 +1,30 @@
+<Project>
+  <PropertyGroup>
+    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>


All that file and things around central package management feature are too verbose and honestly excessive for small projects. I won't bring anything regarding central package management in repo.

I'm under the impression that MS is heading in that direction. That being said, I agree that it can feel as overhead for small projects (although I'm happy that I switched myself for some of my small projects).

I think the main issue with some of the more opinionated rules is that due to some crappy support by MS, it is less trivial to disable (or enable) rules in a .globalconfig or .editorconfig file. For rules about C# code this works perfectly.

I'm fine disabling rules by NoWarn as I did here #143.

Having it in a .globalconfig file is way more readable: https://github.com/Qowaiv/Qowaiv/blob/master/.globalconfig

In a <NoWarn> tag, you can not easily see which rules are disabled. I still have to take some action to report this to MS with a simple analyzer that makes it easy for them to reproduce the issue and hopefully fix it (or show me another way other than <NoWarn>).

is way more readable

I don't want to speculate around what way is more readable or not. Experience varies.

sungam3r · 2025-03-03T09:41:37Z

@Corniel Thanks for you work. I want to make clarity here. When I saw project analyzer repo, I expected to get useful tips from it that would allow me to improve the project structure without destructive actions like you demonstrated in that PR. Compare it to #143 - / and \ slashes - OK, some changes in ItemGroup grouping - OK. Maybe something else - OK, but not completely changing configuration design not to mention the introduction of secondary features like central package management that absolutely should not be forceble.

Also I would like to solve dotnet-project-file-analyzers/dotnet-project-file-analyzers#257 first.

I see many analyzer rules are so opionated that my development experience does not allow me to force such rules, because in my opinion, such forcing only harms. Nevertheless, having read documentation to all the rules, I found some really useful there.

Corniel · 2025-03-03T19:43:25Z

@Corniel Thanks for you work. I want to make clarity here (..)

I see many analyzer rules are so opionated that my development experience does not allow me to force such rules, because in my opinion, such forcing only harms. Nevertheless, having read documentation to all the rules, I found some really useful there.

Thanks for your feedback, I'm really happy you take the time to give it. As mentioned in an other response. When I started I was under the impression that disable rules you don't like is easy, so that should not be a problem. As it turns out, that now seems not even close to as easy to do, as it should, which makes that we should potentially reconsider some rules. I'm thinking of ways to make this easier. The use of <NoWarn> is something I don't like as it really hard to read which rules have been disabled, and it does not allow to only change the severity, but it sometimes feels being the only option.

sungam3r · 2025-03-03T20:56:32Z

The use of is something I don't like as it really hard to read which rules have been disabled

Really? What is complicated there?

Corniel · 2025-03-04T07:39:21Z

The use of is something I don't like as it really hard to read which rules have been disabled

Really? What is complicated there?

Well, as mentioned, you can use <NoWarn> to disable a rule, but there is not way around: you can not enable a rule that has not been enabled by default. You also can not increase or reduce it's severity, nor can you add comments so that you can see what the rule is about. Things that all can be achieved by using the .globalconfig

sungam3r · 2025-03-12T08:53:07Z

you can not enable a rule that has not been enabled by default. You also can not increase or reduce it's severity, nor can you add comments so that you can see what the rule is about.

Not applicable. I know what I do and why. I just disable rules that I do not need. That's all.

github-actions · 2025-04-13T02:37:49Z

This pull request was marked as stale since it has not been active for a long time

github-actions · 2025-06-06T01:14:46Z

This pull request was marked as stale since it has not been active for a long time

github-actions · 2025-11-09T01:16:50Z

This pull request was marked as stale since it has not been active for a long time

github-actions bot added performance Issue or pull request about performance problems tests Pull request that adds new or changes existing tests labels Dec 23, 2024

Corniel mentioned this pull request Dec 27, 2024

Proj0028: Conditional TargetFrameworks should not be reported on dotnet-project-file-analyzers/dotnet-project-file-analyzers#257

Closed

Corniel mentioned this pull request Dec 27, 2024

Proj0009: Take conditionals into account dotnet-project-file-analyzers/dotnet-project-file-analyzers#258

Closed

github-actions bot added the stale label Jan 27, 2025

sungam3r removed the stale label Jan 27, 2025

Corniel force-pushed the corniel/dotnet-sdk branch from bc496ac to 2ac01b1 Compare January 27, 2025 10:59

Corniel added 2 commits February 23, 2025 08:30

Use .NET project files analyzers

31b0daf

Use CPM

43d0ffa

Corniel force-pushed the corniel/dotnet-sdk branch from 2ac01b1 to 43d0ffa Compare February 23, 2025 07:31

Update pakcages

5ebbced

Corniel force-pushed the corniel/dotnet-sdk branch from 280d784 to 5ebbced Compare February 23, 2025 08:00

Generate SBOM

1b89754

remove additional file regestry

f258114

sungam3r reviewed Mar 3, 2025

View reviewed changes

github-actions bot added the stale label Apr 13, 2025

sungam3r removed the stale label May 6, 2025

github-actions bot added the stale label Jun 6, 2025

github-actions bot closed this Aug 5, 2025

sungam3r reopened this Oct 9, 2025

sungam3r removed the stale label Oct 9, 2025

github-actions bot added the stale label Nov 9, 2025

sungam3r removed the stale label Nov 9, 2025

Use .NET project files analyzers #145

Are you sure you want to change the base?

Use .NET project files analyzers #145

Uh oh!

Conversation

Corniel commented Dec 23, 2024

Uh oh!

sungam3r commented Dec 24, 2024

Uh oh!

Corniel commented Dec 25, 2024

Uh oh!

sungam3r commented Dec 25, 2024

Uh oh!

Corniel commented Dec 25, 2024

Uh oh!

sungam3r commented Dec 25, 2024

Uh oh!

Corniel commented Dec 25, 2024

Uh oh!

sungam3r commented Dec 26, 2024

Uh oh!

Corniel commented Dec 27, 2024

Uh oh!

github-actions bot commented Jan 27, 2025

Uh oh!

Corniel commented Feb 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sungam3r commented Mar 3, 2025

Uh oh!

Corniel commented Mar 3, 2025

Uh oh!

sungam3r commented Mar 3, 2025

Uh oh!

Corniel commented Mar 4, 2025

Uh oh!

sungam3r commented Mar 12, 2025

Uh oh!

github-actions bot commented Apr 13, 2025

Uh oh!

github-actions bot commented Jun 6, 2025

Uh oh!

github-actions bot commented Nov 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!