Add upgrade-assistant support

[bryceatmoderne]

What's changed?

Added UpgradeAssistant to execute recipes based on .NET's upgrade-assistant. Only upgrade subcommand is supported with this recipe.

Added UpgradeAssistantAnalyze to execute recipes based on .NET's upgrade-assistant. Only analyze subcommand is supported with this recipe. This recipe does not produce any change results but will generate an org.openrewrite.dotnet.UpgradeAssistantAnalysis data table that somewhat resembles what you'd see in Visual Studio's Upgrade Assistant tool: https://devblogs.microsoft.com/visualstudio/code-assessment-with-net-upgrade-assistant/#interpret-results

For both recipes, there is a single required option targetFramework. This maps directly to the values supplied to upgrade-assistant's --targetFramework flag such as net9.0.

What's your motivation?

upgrade-assistant is a tool used to migrate projects to current versions of .NET.

Anything in particular you'd like reviewers to focus on?

No.

Anyone you would like to review specifically?

@timtebeek @knutwannheden @sambsnyd

Have you considered any alternatives or workarounds?

No.

Any additional context

Requires https://github.com/moderneinc/moderne-cli/pull/2117 and openrewrite/rewrite#4518

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[knutwannheden]

Very nice!

[timtebeek]

I don't know this tool well enough, but would it make sense to limit the values here?
Would also be safer in terms of validation & passing arguments into execution.

Suggested change

	example = "net9.0")
	valid = {"net5.0", "net6.0", "net7.0", "net8.0", "net9.0"})

[timtebeek]

In parallel I'm wondering if it makes sense to add a declarative recipe that helps discoverability. Assuming there's no need to chain recipes that would look something like this:

src/main/resources/META-INF/rewrite/dotnet.yml:

---
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.dotnet.MigrateToNet5
recipeList:
  - org.openrewrite.dotnet.UpgradeAssistant:
      targetFramework: net5.0
---
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.dotnet.MigrateToNet6
recipeList:
  - org.openrewrite.dotnet.UpgradeAssistant:
      targetFramework: net6.0
---
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.dotnet.MigrateToNet7
recipeList:
  - org.openrewrite.dotnet.UpgradeAssistant:
      targetFramework: net7.0
---
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.dotnet.MigrateToNet8
recipeList:
  - org.openrewrite.dotnet.UpgradeAssistant:
      targetFramework: net8.0
---
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.dotnet.MigrateToNet9
recipeList:
  - org.openrewrite.dotnet.UpgradeAssistant:
      targetFramework: net9.0

[bryceatmoderne]

Regarding pre-defined target framework values, I'm hesitant to do this ATM because they are not well defined. I haven't been able to find such a list and aliases such as LTS and PREVIEW didn't work for me despite being referenced in upgrade-assistant upgrade.

When supplying an invalid version to upgrade-assistant upgrade you'll get an "Unknown target version" error logged to the terminal. The UpgradeAssistant recipe will look for this and will create a row for each project (.csproj file) in the org.openrewrite.table.SourcesFileErrors data table.

When a supplying an invalid version to upgrade-assistant analyze the command will generate a report with recommendations such as "No supported version found".

The pre-defined declarative recipes make sense. I'll add those. Thanks again for the feedback!