Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[file-diet] Refactor oversized NamedPipeServer.cs (565 lines) into focused files

Abierto
  • ¿Algo no está bien?
#11,933 0 comentarios 1 reacción 2 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Evangelink ya está trabajando en esto.

Desde el 15/10/2026.

  • #11948 de @copilot-swe-agent — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp
Área
testing-qa

Línea de trabajo

Start with src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs and read the static pipe-naming helpers (GetPipeName, ResolvePipeDirectory, EnsurePathLengthWithinLimit) before the connection loop. Check every project that compiles this file via shared sources, and confirm the class can become partial without breaking them. Done means the split files each stay under 300 lines, behavior is unchanged, and the relevant MTP tests and builds pass.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

type/automation type/tech-debt
Overview

The file src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs has grown to 565 lines, making it harder to navigate and maintain. This task involves refactoring it into smaller, more focused files.

Current State
  • File: src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs
  • Size: 565 lines
  • Language: C#
Structural Analysis

The file defines a single internal sealed class NamedPipeServer : NamedPipeConnectionBase, IServer, mixing several distinct responsibilities:

  • Construction / stream creation: multiple public constructor overloads, RequiresExplicitSecurity, and CreateServerStream, which build the underlying NamedPipeServerStream, optionally hardening it with security identities on Windows.
  • Connection lifecycle: WaitConnectionAsync, InternalLoopAsync (the read/dispatch/write request loop), WaitForDisconnectAsync, and the small TryLogDebugAsync logging helper used during graceful shutdown.
  • Pipe path resolution (static, OS-specific): GetPipeName, ResolvePipeDirectory (both overloads), EnsureDirectoryIsWritable, and EnsurePathLengthWithinLimit — this cluster deals with computing/validating the Unix domain socket or Windows pipe name, including the TESTINGPLATFORM_PIPE_DIRECTORY override and the sun_path byte-length limit.
  • Disposal: Dispose() and DisposeAsync() at the end of the file (not fully inspected in this bounded sample, but visibly part of the instance lifecycle group).
Refactoring Strategy
Proposed File Splits

Based on the bounded structural sample, investigate these proposed splits. Confirm their safety during implementation preflight before moving code. Because the class is sealed and not currently partial, each new file would need NamedPipeServer to be declared partial — verify this does not conflict with source generation, reflection-based name lookups, or other partial declarations elsewhere.

  1. NamedPipeServer.cs (retained core)

    • Contents: class declaration, constants/fields, all public constructors, RequiresExplicitSecurity, CreateServerStream, PipeName property, WasConnected, WaitConnectionAsync, InternalLoopAsync, TryLogDebugAsync
    • Responsibility: instance construction and the core connect/read/dispatch/write request loop

  2. NamedPipeServer.PipeNaming.cs

    • Contents: GetPipeName, ResolvePipeDirectory (both overloads), EnsureDirectoryIsWritable, EnsurePathLengthWithinLimit
    • Responsibility: static, OS-specific pipe name/path computation and validation (Windows naming vs. Unix domain socket directory resolution, TESTINGPLATFORM_PIPE_DIRECTORY override, writability probe, sun_path length limit)

  3. NamedPipeServer.Lifecycle.cs (if needed)

    • Contents: WaitForDisconnectAsync, Dispose(), DisposeAsync()
    • Responsibility: connection-disconnection waiting and resource disposal
Implementation Guidelines
  1. Establish Equivalence: Follow .github/skills/behavior-preserving-refactor/SKILL.md. Before editing, read the complete affected bodies, inventory baseline behavior and relevant tests, and identify distinguishing cases.
  2. Preserve Selection and Evaluation: Keep iteration order, short-circuit evaluation, exact type selection, first/last-match semantics, defaults, exceptions, and side effects. Cover reachable duplicate and malformed inputs; similar-looking helpers are not automatically interchangeable.
  3. Trace All Consumers: Check partial declarations, source-linked consumers, owning/consuming project includes, target-framework guards, and tracked public/internal API surfaces. Keep names, accessibility, attributes, and native interop contracts unchanged. Note this file is referenced from multiple platform/extension projects via shared compilation (#if MTP_MSBUILD_TASKS, etc.) — confirm every consuming project's includes/links are updated for any new file.
  4. Move Before Modernizing: Move bodies unchanged first, one coherent responsibility at a time. Preserve allocation and performance behavior on hot paths (this type is on the IPC hot path); do not mix adjacent modernization or bug fixes into the split.
  5. Use Focused Checks: Run the smallest affected project/TFM builds and relevant tests before and after each coherent split. Add distinguishing equivalence cases where coverage is missing; a pure file move does not require the full solution. Report exact checks and outcomes, including unavailable checks.
  6. Surface Constraints: Measure resulting line counts. If a safe structural split cannot meet the size goal without changing semantics, report the remaining size and blocker rather than forcing behavior changes.
Acceptance Criteria
  • Original file is split into focused modules
  • Each new file is under 300 lines, or a concrete behavior-preservation blocker and remaining size are reported
  • Baseline semantics, including reachable duplicate/malformed cases and evaluation order, are preserved by focused equivalence checks
  • Relevant builds and tests pass for affected consumers/TFMs; exact checks and any validation gaps are reported
  • Public and tracked internal API contracts, attributes, and conditional compilation are preserved
  • Project includes, source links, and package layout still include the moved code for every affected consumer

Priority: Medium
Effort: Medium
Expected Impact: Improved code navigability, easier testing, reduced merge conflicts

🤖 Automated content by GitHub Copilot. Generated by the Daily File Diet workflow. · copilot · auto · 41.7 AIC · ⌖ 6.61 AIC · ⊞ 13.1K · [◷]( · ◷)

  • expires on Oct 16, 2026, 6:59 PM UTC
Lenguaje dominante
C#
Estrellas
1k
Forks
314
Merge medio
9 h 30 min
PR fusionados (30 d)
424

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/testfx

Todos los issues de microsoft/testfx

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.