Use .NET project files analyzers

[Corniel]

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]

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

1. 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?

2. 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?

3. 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?

4. 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?

5. 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]

@sungam3r

1. 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.
2. 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.
3. I'm not sure why that happens, it should not be the case. I had it too.
4. FP's due to the fact that those rules do not take Condition into account.
5. 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]

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]

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]

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]

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]

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]

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]

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

[Corniel]

@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]

Suggested change

<PackageId>Destructurama.Attributed</PackageId>

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

[Corniel]

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

[sungam3r]

thanks

[sungam3r]

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

[Corniel]

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

[sungam3r]

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).

[Corniel]

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.

[sungam3r]

What "it"? GitHub releases feature?

[Corniel]

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

[sungam3r]

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]

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.

[Corniel]

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.

[sungam3r]

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

[Corniel]

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>).

[sungam3r]

is way more readable

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

[sungam3r]

@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]

@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]

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]

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]

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]

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

[github-actions]

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

[github-actions]

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

[github-actions]

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

[sungam3r]

@Corniel thanks for this demo one more time. I created #209 with a fresh mind after migrating repo to NET10 and slnx. I see that you have added a lot of new rules over the year. Good job. I evaluated every rule that was thrown in this project and suppressed irrelevant ones.