[CosmonautJones]

Fixes #1173
Fixes #1096

Problem

When a VB string contains only a newline, or uses lone CR/LF characters, the converter chooses a regular C# string but copies physical line breaks into it. The output does not compile. The same problem affects newline-only text between interpolations.

Solution

Use Roslyn's C# literal formatter on the string's semantic value in the shared nonverbatim escaping path, then escape quotation marks explicitly. This preserves the existing verbatim-selection rule and emits escapes such as \r\n that compile to the original characters. Both ordinary and interpolated strings use the corrected helper.

• Add a regression for the reported newline-only string.
• Compile generated C# and verify exact constant/runtime values for CRLF, LF, CR, repeated newlines, quotes, backslashes, and interpolation braces.
• Review attention: shared escaping behavior, especially exact character preservation and regular versus verbatim output.

Validation

Tested commit: afe981e96d00597af675e1380eb1b899669ad251.

• Regression evidence: 13 new cases failed before the fix; all 36 string tests passed afterward.
• Local .NET 8: focused string tests 36 passed, 0 failed; bounded expression, VB-to-C# behavior, and newline suite 507 passed, 0 failed, 3 pre-existing skips. This used SDK 9 with the installed Visual Studio Roslyn 4.14 preview compiler.
• Local .NET 10, Windows x64: official SDK 10.0.402 / runtime 10.0.13, installed in an isolated tool directory after checksum verification. A fresh build of the library, CLI, and tests succeeded with 0 warnings and 0 errors, using normal project/compiler settings. Focused string tests: 36 passed, 0 failed, 0 skipped (8 seconds). The same bounded broader suite: 507 passed, 0 failed, 3 pre-existing skips (3 min 10 sec). Logs identify net10.0; the active runtime was verified as 10.0.13.
• Existing skips: DeeplyNestedBinaryExpressionShouldNotStackOverflowAsync (marked too slow), LinqAggregateSumAsync, and LinqGroupJoinAsync (unsupported conversions tracked by VB -> C#: Query Expression Syntax not fully implemented #29).

The .NET 10 validation used separate dotnet clean and dotnet build Tests/Tests.csproj -c Release -f net10.0 --no-restore, followed by filtered dotnet test Tests/Tests.csproj -c Release -f net10.0 --no-build --no-restore runs. An initial combined rebuild using --no-incremental failed before tests because compatibility-package source files were omitted; separate clean/build succeeded without source changes.

Upstream CI run 39945459112 still awaits maintainer approval and has executed no jobs. These are successful local .NET 10 results, not a claim that the full upstream build/publish/VSIX/web/VS2026 pipeline passed.

Process

• This patch, tests, and this explanation were prepared with OpenAI Codex. This explanation is AI-written.
• Human understanding/review: I reviewed the delivered patch, tests, and explanation, confirmed that I understand the change, and approved publishing this contribution.
• Attachment level: low; alternative approaches are welcome if they preserve the same characters and compilation behavior.
• LLM primarily used: OpenAI Codex. Exact model variant was not exposed to this session and is not guessed.
• Prompt summary: reproduce VB -> C#: Multi line strings #1173 with a failing regression test, inspect the contribution rules and related VB -> C#: multiline interpolated string with just format-blocks doesn't convert correctly (missing @) #1096, make the smallest correct fix, verify escaping and line-ending behavior through existing compilation tests, and prepare it for human review before publication.