Fix DisposeAsync hang by ensuring SetDisconnected after CleanupAsync

StreamClientSessionTransport.DisposeAsync could hang indefinitely when
awaiting Completion because the channel writer was never completed.

Root cause: ReadMessagesAsync and DisposeAsync race to call CleanupAsync.
The _cleanedUp Interlocked guard ensures only one runs the full body
(which calls SetDisconnected to complete the channel). The loser calls
CancelShutdown() and returns immediately — without waiting for the winner
to finish. If DisposeAsync then does 'await Completion', it blocks on a
channel that the still-running cleanup hasn't completed yet.

Fix: call SetDisconnected() after CleanupAsync in DisposeAsync as a
safety net. SetDisconnected is idempotent (uses Interlocked.Exchange),
so a duplicate call is a no-op.

Also removes the instrumented xUnit DLLs and MSBuild target that were
added to test a disproven GC-collection hypothesis.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: ericstj

src/ModelContextProtocol.Core/Client/StreamClientSessionTransport.cs

@@ -97,8 +97,16 @@ public override async Task SendMessageAsync(JsonRpcMessage message, Cancellation
     }
 
     /// <inheritdoc/>
-    public override ValueTask DisposeAsync() =>
-        CleanupAsync(cancellationToken: CancellationToken.None);
+    public override async ValueTask DisposeAsync()
+    {
+        await CleanupAsync(cancellationToken: CancellationToken.None).ConfigureAwait(false);
+
+        // Ensure the channel is always completed after disposal, even if CleanupAsync
+        // returned early because another caller (e.g. ReadMessagesAsync) was already
+        // running cleanup. SetDisconnected is idempotent—if the channel was already
+        // completed by the other cleanup path, this is a no-op.
+        SetDisconnected();
+    }
 
     private async Task ReadMessagesAsync(CancellationToken cancellationToken)
     {

tests/Common/InstrumentedXunit/xunit.v3.common.dll

@@ -8,21 +8,4 @@
     <!-- Suppress the obsolete SSE warning in test projects that need to test legacy SSE -->
     <NoWarn>$(NoWarn);MCP9004</NoWarn>
   </PropertyGroup>
-
-  <!--
-    Replace xUnit v3 DLLs with instrumented builds that fix a GC-collectibility bug
-    in TestRunner.RunTest's async void state machine. The instrumented build extracts
-    the async void body into an async Task method and holds a reference to the returned
-    Task, preventing the entire async chain from being garbage-collected when the only
-    references form a cycle.
-    See: https://github.com/modelcontextprotocol/csharp-sdk/pull/1449
-    TODO: Remove once xUnit ships a fix upstream.
-  -->
-  <PropertyGroup>
-    <InstrumentedXunitDir>$(MSBuildThisFileDirectory)Common\InstrumentedXunit\</InstrumentedXunitDir>
-  </PropertyGroup>
-  <Target Name="ReplaceXunitWithInstrumented" AfterTargets="Build" Condition="Exists('$(InstrumentedXunitDir)xunit.v3.core.dll')">
-    <Copy SourceFiles="$(InstrumentedXunitDir)xunit.v3.core.dll" DestinationFolder="$(OutputPath)" OverwriteReadOnlyFiles="true" />
-    <Copy SourceFiles="$(InstrumentedXunitDir)xunit.v3.common.dll" DestinationFolder="$(OutputPath)" OverwriteReadOnlyFiles="true" />
-  </Target>
 </Project>