feat: added dotnet aspire support

[kimpenhaus]

closes #926

[msexxeta]

I tested this locally against the current Aspire stack and a local Podman-backed Kubernetes cluster.

Environment:

• .NET SDK 10.0.108
• Aspire CLI 13.3.5
• PR branch feature/926-support-aspire / pr-1132-aspire
• Podman-backed kind cluster kind-kubeops-aspire with Kubernetes v1.35.0

What worked:

• dotnet restore succeeded.
• Full solution build succeeded with 0 errors. I only saw unrelated transitive TFM warnings from Microsoft.NET.StringTools / Microsoft.Build.Framework for the multi-targeted CLI project.
• New Aspire tests passed:
  • KubeOps.Aspire.Test: 3/3
  • KubeOps.Aspire.Hosting.Test: 2/2
• After providing the expected Aspire dashboard launch environment, aspire run --project examples/AspireAppHost/AspireAppHost.csproj --non-interactive started successfully.
• The AppHost started the operator resource, the operator installed the testentitys.testing.dev CRD, and applying examples/Operator/test_entity.yaml worked. The resource received the expected finalizer, so the operator was watching/reconciling the local cluster.

Two things I noticed:

• examples/AspireAppHost is missing the modern Aspire Properties/launchSettings.json. With Aspire CLI / packages 13.3.5, running the AppHost as-is fails first because ASPNETCORE_URLS and ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL / ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL are missing. The current dotnet new aspire-apphost template includes these settings.
• The sample AppHost exercises KubeOps.Aspire.Hosting / AddKubeOps, but the sample operator does not reference KubeOps.Aspire or call AddKubeOpsServiceDefaults(). So the operator-side service defaults / OTLP integration are not demonstrated by the sample yet.

I will try to improve these two points.

[kimpenhaus]

not to bad 😄 thanks for your effort!

The sample AppHost exercises KubeOps.Aspire.Hosting / AddKubeOps, but the sample operator does not reference KubeOps.Aspire or call AddKubeOpsServiceDefaults(). So the operator-side service defaults / OTLP integration are not demonstrated by the sample yet.

ah - yes that's my fault - I didn't wanted to tie both samples together and messed it up 🙈 may be we can have an extra aspire operator calling AddKubeOpsServiceDefaults then instead of extending the simple operator sample?

[msexxeta]

I could not push directly to dotnet/feature/926-support-aspire, so I pushed the proposed follow-up changes to a fork branch here:

https://github.com/msexxeta/dotnet-operator-sdk/tree/pr-1132-aspire-kubeops-publish

The branch contains commit cb7a720 (feat: publish KubeOps resources with Aspire Kubernetes). It wires AddKubeOps<TProject> into Aspire's Kubernetes publishing path so aspire publish emits a full chart with the Aspire-owned operator Deployment plus KubeOps-generated CRDs/RBAC. The KubeOps-generated Deployment is not emitted as a duplicate; its operator-specific settings are merged into the Aspire Deployment.

To pull it into this PR branch:

git fetch https://github.com/msexxeta/dotnet-operator-sdk.git pr-1132-aspire-kubeops-publish
git cherry-pick cb7a720

I verified this locally with:

• dotnet test test/KubeOps.Aspire.Hosting.Test/KubeOps.Aspire.Hosting.Test.csproj --no-restore
• dotnet test test/KubeOps.Aspire.Test/KubeOps.Aspire.Test.csproj --no-restore
• aspire publish --apphost examples/AspireAppHost/AspireAppHost.csproj --output-path ./aspire-output-test --non-interactive --nologo --include-exception-details
• kubectl apply --dry-run=server --recursive ... against a local Podman/kind cluster

The solution build also passes, with the existing net8/net9 package TFM warnings from Microsoft.NET.StringTools / Microsoft.Build.Framework.

[msexxeta]

I think there are even more implications to consider here: the operating model of aspire is to run .net services locally. I don't think the #IF DEBUG path here is the correct path for aspire. I'll think about this a bit more.

[kimpenhaus]

@msexxeta thanks for the pull request - but that one has exactly what I didn't want to do. see: #1132 (comment)

I didn't wanted to tie both samples together and messed it up 🙈 may be we can have an extra aspire operator calling AddKubeOpsServiceDefaults then instead of extending the simple operator sample?

the "normal" operator sample now has a reference to aspire - I wanted to avoid that as we have different scenarios to serve. I think it would be a better approach to have an extra aspire.operator for the aspire sample.

[kimpenhaus]

I think there are even more implications to consider here: the operating model of aspire is to run .net services locally. I don't think the #IF DEBUG path here is the correct path for aspire. I'll think about this a bit more.

if you're referring to the examples operator #if DEBUG I've added - this was just purely cosmetics as the crd installer is also added with a preprocessor directive and the using statement becomes unused when switching to debug mode.

I think this won't be an issue once the aspire operator is separated

[msexxeta]

#1135
it was becoming a whole other beast so I made a different PR, but I kept you ask co-author.
https://github.com/msexxeta/dotnet-operator-sdk/blob/bcc5a367419b22689a9a740c20aaedca9bb2b620/docs/docs/operator/aspire.mdx
and
See https://github.com/msexxeta/dotnet-operator-sdk/blob/bcc5a367419b22689a9a740c20aaedca9bb2b620/docs/docs/operator/aspire-kubernetes-model.mdx
for the whole documentation.

In short: This supports the operating model with a local and a cloud kubernetes environment, as well as without a kubernetes environment, just directly generating manifests. It also has the usual methods of configuring such as found with other azure models, such as Run... Publish... with specific configuration overrides inside.

[kimpenhaus]

closed in favor of #1135