corgibytes / freshli-agent-dotnet Goto Github PK

We should be able to detect and process any of the project file formats that the CycloneDX dotnet tool is able to work with.

Model this after they way the linting is set up for the Freshli-CLI project.

Per the Nuget documentation for versions, a version expression in the form of 1.0 is actually specifying that any version >= 1.0 is valid. That means that we need to update our version pinning logic to treat all version expressions in the form of 1.0 to be [1.0, latest] which would pin the upper bound of the resolution to be the latest version that was published before (or on) the asOf date/time.

• Set up pull request integration
• Publish code coverage information

Version ranges in the form of [1.0, 2.0] permit the use of pre-release versions. However, that's not typically what people want when considering what the latest version is.

The semantics that we'll implement for version pinning is to only consider a pre-release package to be the latest version if the lower bound of the range is referencing a pre-release version.

Some examples:

Sample.Package Release History

For the examples below, we'll assume that there's a package named Sample.Package with the following release history:

• 1.0.0
• 1.0.1
• 1.2.0-alpha
• 1.2.0-beta
• 1.2.0
• 1.3.0-alpha

Package reference with a stable version number

Assume that a package reference looks like:

<PackageReference Include="Sample.Package" Version="1.0.0" />

In this case, the pinned version range would be set to use the latest version as 1.2.0. So the pinned expression would be:

<PackageReference Include="Sample.Package" Version="[1.0.0, 1.2.0]" />

Package reference with a pre-release version number

Assume that a package reference looks like:

<PackageReference Include="Sample.Package" Version="1.2.0-alpha" />

In this case, the pinned version range would be set to use the latest version as 1.3.0-alpha. The pinned expression would read:

<PackageReference Include="Sample.Package" Version="[1.2.0-alpha, 1.3.0-alpha]" />

Building on macOS should be enabled in CI, and any issues that are discovered should be fixed.

The .NET agent needs to be packaged into a Dockerfile.

Use Dependabot to update dependencies in

• .config/dotnet-tools.json
• *.csproj
• Gemfile.lock

It is not uncommon for a package version to be removed from the NuGet repository. We should have a way to detect and mitigate that scenario.

When the versions are not available, then BOM generation is likely to fail.

One possible solution that is worth investigating:

• scan package versions before BOM generation is attempted
• if an unlisted version is found,
  • select the next oldest package and update the manifest file to reference that version instead
  • write out a warning message indicating that the version has been changed from X to Y
• if no such version is available, then give up

We a language agent (used by the analyze command) for dotnet projects. Similar to the Java one, it should be called freshli-agent-dotnet

• Create Github report for freshli-agent-dotnet
• Create skeleton solution and project
• Create initial Action Workflow for building agent
• Implement commands:
  • validating-package-urls
  • retrieve-release-history
  • validating-repositories
  • detect-manifests
  • process-manifest
  • start-server

See also corgibytes/freshli-cli#4

Repositories and provide a Directory.Packages.props file to specify the version numbers that should be used for dependencies that appear in multiple project files. When such a file is in place, the Version attribute is omitted from the <PackageReference/> element in a .csproj file.

In addition to using the central file to lookup version numbers and ranges that are in use, those entries must be where version ranges are pinned. Attempting to pin the version by adding a Version attribute causes an error when the CycloneDX dotnet tool attempts to generate the BOM file.

Building on Windows in CI currently fails, and it has been disabled. It should be added back, and any issues preventing it from running should be fixed.

There are a lot of linter violations that need to be cleaned up, and linting needs to be added to the CI process.

Search for solution and project files when detecting manifest files. If a project file is returned as part of the results, then it means that it is not listed in one of the solution files.

This approach is possible because the CycloneDX dotnet tool supports processing solution files.

The agent should provide a shell script (for all platforms) for installing itself. This would be massively useful for including it in the freshli-cli docker image.