Clarify non-Microsoft path for generating COM tooling artifacts in modern .NET COM docs

[Copilot]

The COM exposure article left a practical gap for VBA/Office consumers who need a TLB-generation workflow comparable to .NET Framework-era tooling. This update adds explicit guidance to a community CLI option when built-in modern .NET tooling does not provide that path.

• Problem clarification

  • The article already states that .NET Core/.NET 5+ does not generate TLBs from assemblies and points to manual IDL/C++ header workflows.
  • Users still lacked a concrete pointer to CLI tooling analogous to legacy framework tools.

• Documentation update

  • Added a focused note in docs/core/native-interop/expose-components-to-com.md under Additional notes linking to the dscom project.
  • Clarified support boundary: dscom is community-maintained, not a Microsoft-supported tool.

• Metadata compliance

  • Added ai-usage: ai-assisted frontmatter to the edited Markdown file.

For scenarios where you need command-line COM tools similar to tools that .NET Framework provided, see the community project [`dscom`](https://github.com/dspace-group/dscom). This project isn't a Microsoft tool, so support comes from the project maintainers.

• Fixes Resulting DLL Cannot be added as reference in VBA #27996

---

Internal previews

📄 File	🔗 Preview link
docs/core/native-interop/expose-components-to-com.md	docs/core/native-interop/expose-components-to-com

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.