Improve StringBuilder interop guidance: warn about allocations, promote ArrayPool

[Copilot]

The "Fixed-length string buffers" section presented StringBuilder as a co-equal alternative to char[]/ArrayPool, with only a mild [!NOTE] about performance. This conflicts with the native interop best practices page, which explicitly recommends avoiding StringBuilder parameters due to excessive allocations.

Changes

• Promoted ArrayPool<char> as the explicitly recommended approach — updated the intro sentence to call it out as such
• De-emphasized StringBuilder — changed "Another solution is..." to "You might also consider..." to signal it's secondary
• Upgraded [!NOTE] → [!CAUTION] with a detailed breakdown of why StringBuilder is costly:
  • Always creates a native buffer copy
  • Generates up to 4 allocations per P/Invoke call (managed buffer → native buffer → managed array copy → ToString())
  • The capacity doesn't include the null terminator, a common source of bugs and wasted allocations
  • Reusing StringBuilder saves only one allocation vs. ArrayPool<char> which reduces it to just ToString()
• Added link to CA1838 (Avoid StringBuilder parameters for P/Invokes) alongside the existing best-practices link

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Efficiency issues with StringBuilder</issue_title>
<issue_description>
The discussion of using StringBuilder makes no mention of the excessive allocations as discussed on the native interop best practices page; the guidance there specifically says to "AVOID StringBuilder parameters." Meanwhile, the recommended best practice ("using char[]s from an ArrayPool") is not mentioned on this page.

I imagine this page has simply fallen out of date, but it'd be nice to present a consistent story about best practices and sample code for guidance.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 25d350b8-a514-6c13-a091-0952a8fc0610
• Version Independent ID: 3ee9bbfd-2060-d97f-c2f1-12867899034a
• Content: Default Marshaling for Strings
• Content Source: docs/framework/interop/default-marshaling-for-strings.md
• Product: dotnet-framework
• GitHub Login: @gewarren
• Microsoft Alias: dotnetcontent</issue_description>

Comments on the Issue (you are @copilot in this section)

@adegeo Thank you for opening this issue. I'll add it to the backlog. If you would like to contribute, you can submit a fix by editing the original article. Click on the **Content Source** link at the bottom of your original comment. To learn how to edit, see the [Editing files in a repository](https://help.github.com/articles/editing-files-in-your-repository) article from GitHub.

Thanks again!</comment_new>

• Fixes Efficiency issues with StringBuilder #19902

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

---

Internal previews

📄 File	🔗 Preview link
docs/framework/interop/default-marshalling-for-strings.md	docs/framework/interop/default-marshalling-for-strings

[BillWagner]

This LGTM once I make one change.

[Copilot]

Pull request overview

Updates the .NET Framework interop documentation for string marshalling to better emphasize modern performance guidance and disclose AI-assisted edits.

Changes:

• Updated frontmatter metadata (ms.date) and added ai-usage: ai-assisted.
• Revised guidance around using ArrayPool<char> for fixed-length buffers.
• Expanded and strengthened the StringBuilder performance guidance, including links to CA1838 and interop best practices.