Replace "non-.NET" phrasing across docs

[davidfowl]

Multiple docs use "non-.NET" to describe multi-language scenarios (e.g., "Using with non-.NET applications"). This framing is exclusionary and should be replaced with positive language like "multi-language" or "TypeScript, Python, and JavaScript."

Files affected

Integration host docs (section headings "Using with non-.NET applications"):

• integrations/databases/mongodb/mongodb-host.mdx
• integrations/databases/milvus/milvus-host.mdx
• integrations/databases/sql-server/sql-server-host.mdx
• integrations/databases/sqlite/sqlite-host.mdx
• integrations/databases/elasticsearch/elasticsearch-host.mdx
• integrations/databases/postgres/postgres-host.mdx (5 occurrences)
• integrations/databases/qdrant/qdrant-host.mdx
• integrations/databases/efcore/oracle/oracle-host.mdx
• integrations/caching/redis/redis-host.mdx

Other docs:

• whats-new/aspire-13.mdx (2 occurrences)
• whats-new/aspire-13-2.mdx
• community/videos.mdx
• app-host/executable-resources.mdx

[davidfowl]

Follow-up from a rendered-site audit of generic Getting Started pages (using the local docs site, not just source grep). These pages are still in generic nav sections, but the content often reads as if the default reader/project is C# / .NET.

Pages I’d add to the issue scope:

• /get-started/app-host/

  • This page sits under Fundamentals -> Core concepts, so it reads as a general concept page, but the narrative and examples still skew heavily toward .NET and C#.
  • Rendered examples include phrases like:
    • This architecture demonstrates a .NET API connecting to a PostgreSQL database...
    • repeated AddProject<Projects.Api> / .csproj / C# references in a page that explains the AppHost conceptually.
  • Why it feels slanted: the core AppHost concept is broader than a C# project walkthrough, but the examples and framing still imply a .NET API + C# AppHost as the default mental model.

• /get-started/deploy-first-app/

  • This page is the generic Deploy your first app overview/tutorial entry in nav, but the current rendered content still centers the ASP.NET/Blazor starter shape.
  • Rendered examples include:
    • The ASP.NET Core Blazor & Minimal API starter template...
    • C# AddProject<...>-style deployment examples.
  • Why it feels slanted: for a generic deployment overview, it still behaves like the C# starter deployment walkthrough.

• /get-started/prerequisites/

  • This page is a generic setup page, but the runtime/tooling story still starts from the C# AppHost as the default.
  • Rendered wording includes:
    • Aspire's C# AppHost is built on .NET...
    • .NET 10.0 SDK is required for C# ...
  • Why it feels slanted: even when technically true for some flows, the page establishes .NET/C# as the primary frame instead of leading with AppHost choices and language-specific prerequisites more neutrally.

• /get-started/dev-containers/

  • This page is under Setup and tooling, not a .NET subsection, but the scenarios and language still lean heavily into .NET + Visual Studio workflows.
  • Rendered headings/snippets include:
    • Stateless .NET apps only
    • many Visual Studio references.
  • Why it feels slanted: the setup guidance reads more like .NET dev container guidance with extras than a broader Aspire setup page.

• /get-started/github-codespaces/

  • Same nav problem as Dev Containers: generic setup page, but the wording still leans on ASP.NET/Visual Studio defaults.
  • Rendered content includes:
    • the ASP.NET Core development certificate has been created and trusted inside the Codespace
    • repeated Visual Studio Code / Visual Studio-oriented setup framing.
  • Why it feels slanted: the page is broader than ASP.NET setup, but it still uses that as the default example and mental model.

• /get-started/aspire-vscode-extension/

  • This is a generic VS Code extension page, but it still carries a lot of .NET and C# weight in prerequisites/examples.
  • Rendered wording includes:
    • .NET 10 or later
    • multiple C# and .csproj references.
  • Why it feels slanted: the extension is useful beyond a C#-first reader journey, but the page still feels optimized for .NET project workflows.

• /get-started/aspire-sdk-templates/

  • This is a broad templates page in Getting Started, but it still presents the Aspire starter/app template story primarily through ASP.NET, Blazor, solution, and Visual Studio language.
  • Rendered wording includes:
    • AspireSample.ApiService: An ASP.NET Core Minimal API project...
    • AspireSample.Web: An ASP.NET Core Blazor App...
    • To create an Aspire solution or project, use Visual Studio, Visual Studio Code, or the Aspire CLI...
  • Why it feels slanted: it reads like the .NET starter template story rather than a neutral overview of Aspire templates and starter options.

What not to include in this follow-up:

• Pages that are already explicitly scoped in nav to C# / .NET should not be treated as issue-559 problems just because they mention .NET heavily.
• The remaining issue is specifically about generic pages that still present .NET / C# as the default frame.

Also noting for the eventual PR: this issue likely needs follow-up work beyond the first pass, so the PR should not use Fixes #559. Instead it should reference the issue without auto-closing it.

[alistairmatthews]

I asked Copilot to report on the prioritization of C# over other programming languages: Programming Language Usage Report