Skip to content

[Code Quality] Logger.cs hardcodes 'logs' subdirectory in 3 places (lines 91, 120, 349) #1051

@Christophe-Rogiers

Description

@Christophe-Rogiers

Severity: Info

File: src/Servy.Core/Logging/Logger.cs

Lines: 91, 120, 349

Issue:
The literal string "logs" (the subdirectory under AppConfig.ProgramDataPath) is hardcoded in three separate places in Logger.cs:

// Line 91 — InternalInitialize main path
var logDir = Path.Combine(AppConfig.ProgramDataPath, "logs");

// Line 120 — InternalInitialize fallback (init failure)
var logDir = Path.Combine(AppConfig.ProgramDataPath, "logs");

// Line 349 — Log() catch block fallback
var logDir = Path.Combine(AppConfig.ProgramDataPath, "logs");

Why this matters:

  1. If anyone ever wants to relocate the log directory (e.g. for portable installs, custom deployments, or compliance-driven layout changes), three sites must be updated in lockstep. Forgetting one creates "ghost" files in the wrong place — and the third site only fires on logger errors, so the bug would only surface during incidents.
  2. Inconsistent with the rest of the codebase, where path constants live in AppConfig (e.g. ServyServiceUIExe, ServyServiceCLIExe, GetHandleExePath()).
  3. Same DRY pattern as [Code Quality] AppConfig — TFM 'net10.0-windows' hardcoded into three path constants (silently stale on TFM upgrade) #1027/[Code Quality] AppConfig — three near-identical Get*ServicePath / GetHandleExePath methods (DRY) #1028 (TFM and service paths in AppConfig).

Suggested fix:
Add a constant to AppConfig:

public static readonly string LogsPath = Path.Combine(ProgramDataPath, \"logs\");

Replace the three call sites with AppConfig.LogsPath. (LogTailer/LogsViewModel and any other consumer of the same directory should also be updated to use this constant.)

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions