digitecgalaxus/projectsruler

This is a C# Project for architectural governance. It checks the .csproj and .sln files and can be used to implement some rules upon them.

projectsruler's Issues

Run build & test on pull request, require success to complete

To prevent accidents, only safe changes should be incorporated into master. To do this, a pipeline should exist that reacts on pushes on pull requests and verifies that they can be safely merged.

Acceptance criteria

• When a PR is created (and on every push), a build and test step is executed
• A successful run of that pipeline is a requirement to complete the PR

Fluent Builder API for Rules

While it's perfectly fine to create rules using only the constructor, it might be beneficial to allow a more fluent style for creating rules. Something like

Rule.CreateRule("This is a description")
    .For("Package.A")
    .Referencing("Package.A.Contracts")
    .Kind(RuleKind.Forbidden)

Obviously, the names are up to debate. I myself prefer a sentence-like style, e.g. "Check that package X does not reference package Y" translated as

Check("Description")
    .That("Package.A")
    .DoesNotReference("Package.B")

but that is just personal preference.

It is possible to check TargetFramework(s)

Acceptance Criteria

• There is a rule to check one or more TargetFrameworks

New rules for checking .props files usage

Story

As a developer I want to make sure that only the intended .props files are used in the .csproj files.

Acceptance Criteria

• There is a rule that limits the usage of .props files.

isPrivateAssetsAllSet has no effect

Though we have a check in place that checks that references to Deblazer without PrivateAssets=All are forbidden, no reference to Deblazer has PrivateAssets=all set.

AllowedButShouldBeRemoved RuleKind

Acceptance Criteria

• There is another kind of rules for the exceptions that should be cleaned up.
• These rules are generating warnings.
• It is up to the unit test maintainer to decide how to handle warnings.

Add a checker to find duplicates of references

Duplicates can sometimes make a lot of small problems while compiling, if you do a clean compile/rebuild of the solution. This could easily be checked with the ProjectsRuler.

Automatic publish to nuget.org on tag creation

Acceptance criteria

If a tag is created, that commit will be used to build a NuGet package, which will then be published to nuget.org via actions.

Completely fluent style for checking

I dig fluent interfaces. There now is a fluent builder for rules, but I feel like the checking in general could be done via a fluent interface.

In my mind, it'd be like

var violations = ForProject("path/to/sln").Check()
    .That.Project("SomeCoolProject").DoesNotReference("*Test")
    .That.AllProjects.Import("Common.props")
    .That.Project("*.Database").DoesNotReference("*").Except("EF.Core")
    .Result()

This would allow different kinds of checks to weave together... instead of checking "horizontally" - e.g. all references, all duplicates, ... - you could check "vertically" for projects or layers.

Of course, actual names are subject for debate 😉

PackageReference Rules support a minimal version

Current state

It is possible to check an exact version only. e.g. Version=="1.1.1"

Acceptance criteria

• There is a support for a minimal version.
• It is possible to prevent/allow preview/alpha/beta releases.

Remarks

• MinimalVersion = "1.2.3" would mean Version >= 1.2.3
• There are different Version formats:
  ** 1
  ** 1.2
  ** 1.2.3
  ** 1.2.3.4
  ** 1.2.3-asdf

Rules support pattern matching in a reference name

Acceptance Criteria

• It is possible to differentiate between components in the same parent namespace Base.A vs. Base.B
• It is possible to extract a piece of a namespace from a reference.

Base.A -> Base.A.Contracts OK
Base.A.Contracts -> Base.A not OK