fix: splash screen and log output routing based on delivertostdout setting

[Copilot]

The ASCII art splash screen and help hint were incorrectly written to stderr regardless of the delivertostdout setting. This caused the splash screen to appear in stderr even during normal operation. Additionally, when --delivertostdout is enabled, stdout needs to be kept clean for raw message content only.

Changes

• Program.cs:
  • Added IsDeliverToStdoutEnabled() helper method to detect the --delivertostdout flag
  • Conditional routing of splash screen based on the flag (stdout when not set, stderr when set)
  • Color detection updated to check the appropriate stream based on the flag
  • Updated SetupStaticLogger to use custom ConsoleStreamSink for proper stream routing
  • Fixed error logging in catch block to respect the delivertostdout setting
• CommandLineParser.cs: Conditional routing of help hint message based on the flag
• ConsoleStreamSink.cs: Created new custom Serilog sink to write to stderr or stdout based on configuration

Before/After

Before:

$ smtp4dev 2> stderr.log 1> stdout.log
# stderr.log contains ASCII art banner (incorrect)
# stdout.log contains [INF] log messages

$ smtp4dev --delivertostdout="*" 2> stderr.log 1> stdout.log
# stdout.log contains ASCII art banner AND message content (contaminated)
# stderr.log contains [INF] log messages

After:

$ smtp4dev 2> stderr.log 1> stdout.log
# stderr.log is empty
# stdout.log contains both ASCII art banner and [INF] log messages

$ smtp4dev --delivertostdout="*" 2> stderr.log 1> stdout.log
# stdout.log is clean (only message content)
# stderr.log contains ASCII art banner and [INF] log messages

This fix ensures that when --delivertostdout is used, stdout remains clean for message content capture, while all diagnostic output (splash screen and logs) goes to stderr. When the flag is not used, everything goes to stdout as expected for normal operation.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Splash screen is delivered to stderr</issue_title>
<issue_description>I understand that when delivertostdout is used, log output is delivered to stderr. However, with v3.12.0, the "splash screen" part of the log output is delivered to stderr even if delivertostdout is not used. I.e.:

Or in text form, this goes to stderr:

┌────────────.
|\          / \    version 3.12.0+ab82ab4df8311e0896fca87c868677073a997eaa
| \        /   \   https://github.com/rnwood/smtp4dev
|  smtp4dev    /  .NET 8.0.22
|             /
└────────────'

 > For help use argument --help

This goes to stdout:

[INF] smtp4dev version 3.12.0+ab82ab4df8311e0896fca87c868677073a997eaa
[INF] https://github.com/rnwood/smtp4dev
[INF] .NET Core runtime version: .NET 8.0.22
[INF] Install location: E:\ShortPath\OSOCE2\test\Lombiq.OSOCE.Tests.UI\bin\Debug\net8.0
[INF] DataDir: C:\Users\lehoc\AppData\Roaming\smtp4dev
[INF] Default settings file: C:\Users\lehoc\.nuget\packages\rnwood.smtp4dev\3.12.0\tools\net8.0\any\appsettings.json
[INF] User settings file: C:\Users\lehoc\AppData\Roaming\smtp4dev\appsettings.json
[INF] Using in-memory database for message storage
[INF] Creating mailbox Default
[INF] Creating INBOX folder for mailbox Default
[INF] Creating Sent folder for mailbox Default
[INF] TLS mode: "None" Pop3TlsMode: "None"
[INF] SMTP Server is listening on port 11319 (::) with TLS mode ("None").
[INF] Keeping last 100 messages per mailbox and 100 sessions.
[INF] IMAP Server is listening on port 16306 (::)
[INF] IMAP Server is listening on port 16306 (0.0.0.0)
[INF] POP3 Server is listening on port 17303 (::) with TLS mode None
[INF] Now listening on: http://localhost:12361

I suppose this isn't intended and all of this should go to stdout.</issue_description>

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

• Fixes Splash screen is delivered to stderr #1996

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[rnwood]

📊 Code Coverage Report

Coverage Type	Percentage	Status
Line Coverage	14.3%	🔴
Branch Coverage	4.8%	🔴
Method Coverage	17.6%	🔴

📁 Coverage by Namespace

Namespace	Line Coverage	Branch Coverage	Method Coverage	Classes
LumiSoft.Net	0% 🔴	0% 🔴	0% 🔴	23
LumiSoft.Net.AUTH	0% 🔴	0% 🔴	0% 🔴	18
LumiSoft.Net.IMAP	1.7% 🔴	0.4% 🔴	3.9% 🔴	122
LumiSoft.Net.IMAP.Client	0% 🔴	0% 🔴	0% 🔴	8
LumiSoft.Net.IMAP.Server	0% 🔴	0% 🔴	0% 🔴	25
LumiSoft.Net.IO	0% 🔴	0% 🔴	0% 🔴	13
LumiSoft.Net.Log	0% 🔴	0% 🔴	0% 🔴	3
LumiSoft.Net.Mail	0% 🔴	0% 🔴	0% 🔴	14
LumiSoft.Net.MIME	0% 🔴	0% 🔴	0% 🔴	41
LumiSoft.Net.TCP	0% 🔴	0% 🔴	0% 🔴	6
LumiSoft.Net.UDP	0% 🔴	0% 🔴	0% 🔴	3
Rnwood.Smtp4dev	1.9% 🔴	3.5% 🔴	11.9% 🔴	14
Rnwood.Smtp4dev.ApiModel	58.5% 🔴	54.5% 🔴	44.3% 🔴	17
Rnwood.Smtp4dev.Controllers	3.5% 🔴	4.7% 🔴	9.2% 🔴	11
Rnwood.Smtp4dev.Data	55.6% 🔴	40.9% 🔴	60% 🟡	3
Rnwood.Smtp4dev.DbModel	72.1% 🟡	0% 🔴	67.3% 🟡	6
Rnwood.Smtp4dev.DbModel.Projections	100% 🟢	0% 🔴	100% 🟢	1
Rnwood.Smtp4dev.Hubs	0% 🔴	0% 🔴	0% 🔴	1
Rnwood.Smtp4dev.Migrations	90.2% 🟢	0% 🔴	71.7% 🟡	23
Rnwood.Smtp4dev.Server	15.4% 🔴	14% 🔴	20.3% 🔴	15
Rnwood.Smtp4dev.Server.Imap	84.8% 🟢	85.3% 🟢	78.9% 🟡	2
Rnwood.Smtp4dev.Server.Pop3	77.3% 🟡	67% 🟡	96.8% 🟢	2
Rnwood.Smtp4dev.Server.Pop3.CommandHandlers	48.3% 🔴	26.1% 🔴	84.6% 🟢	12
Rnwood.Smtp4dev.Server.Settings	67.1% 🟡	16.7% 🔴	72.1% 🟡	10
Rnwood.Smtp4dev.Service	0% 🔴	0% 🔴	0% 🔴	6
Rnwood.Smtp4dev.TUI	0% 🔴	0% 🔴	0% 🔴	9
Rnwood.SmtpServer	72.1% 🟡	63.2% 🟡	68.3% 🟡	36
Rnwood.SmtpServer.Extensions	67.9% 🟡	25% 🔴	91.3% 🟢	6
Rnwood.SmtpServer.Extensions.Auth	59% 🔴	47.6% 🔴	57.5% 🔴	23
Rnwood.SmtpServer.Verbs	92.9% 🟢	92% 🟢	100% 🟢	12

Overall Coverage Details:

• Covered Lines: 5984 / 41736
• Covered Branches: 587 / 11981
• Covered Methods: 701 / 3976
• Assemblies Tested: 3
• Total Classes: 485

📈 View Full Coverage Report

Enhanced coverage report with namespace breakdown - Azure DevOps Build #3.12.0-ci20251228107_pr1999 20251228.8

[rnwood]

@copilot when delivertostdout is enabled, we need to make sure there's no unwanted output to stdout.

[Copilot]

@copilot when delivertostdout is enabled, we need to make sure there's no unwanted output to stdout.

Fixed in commit de1c410. When --delivertostdout is enabled, the splash screen and all logs now go to stderr, keeping stdout clean for message content only. Without the flag, everything goes to stdout as expected.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

❌ PR Title Validation Failed

Your pull request title doesn't follow the
Conventional Commits
specification.

Required format: type(optional-scope): description

Valid types: feat, fix, docs, style, refactor,
perf, test, build, ci, chore, revert

Examples:

• feat: add email template support
• fix(smtp): resolve connection timeout issue
• docs: update installation guide
• chore(deps): update dependencies

Your current title: Fix splash screen and log output routing based on delivertostdout setting

Please update your PR title to match the conventional commit
format. You can edit the title by clicking the "Edit" button
next to the title at the top of this PR.

For more details, see our
Contributing Guidelines.

[github-actions]

❌ PR Title Validation Failed

Your pull request title doesn't follow the
Conventional Commits
specification.

Required format: type(optional-scope): description

Valid types: feat, fix, docs, style, refactor,
perf, test, build, ci, chore, revert

Examples:

• feat: add email template support
• fix(smtp): resolve connection timeout issue
• docs: update installation guide
• chore(deps): update dependencies

Your current title: Fix splash screen output to stdout instead of stderr

Please update your PR title to match the conventional commit
format. You can edit the title by clicking the "Edit" button
next to the title at the top of this PR.

For more details, see our
Contributing Guidelines.

[rnwood]

@copilot The build triggered by this PR has failed. Please use the Azure DevOps REST API to investigate and fix the issues.

🚨 IMPORTANT: Only proceed if this is the most recent commit on your branch. If a newer commit exists, ignore this notification.

Build Details:

• Build ID: 5438
• Build URL: https://dev.azure.com/rnwood/smtp4dev/_build/results?buildId=5438 (for reference)
• Commit: 71c1717
• Build Status: FAILED

Instructions for @copilot:

1. First verify this is the latest commit - If 71c1717 is not the most recent commit in this PR branch, ignore this notification

2. Use Azure DevOps REST API to get build details and failures:
   `�ash

   Get build overview

   curl -s "https://dev.azure.com/rnwood/smtp4dev/_apis/build/builds/-version=6.0" | jq '{status: .status, result: .result, sourceVersion: .sourceVersion}'

   Get failed tasks and their logs

   curl -s "https://dev.azure.com/rnwood/smtp4dev/_apis/build/builds/5438/timeline?api-version=6.0" | jq '.records[] | select(.result == "failed") | {name: .name, task: .task.name, errorCount: .errorCount, logId: .log.id}'

   Get specific error details from a failed task log (replace LOG_ID)

   curl -s "https://dev.azure.com/rnwood/smtp4dev/_apis/build/builds/5438/logs/LOG_ID" | grep -i "error|failed"
   `

3. Analyze the error messages from the API responses to identify compilation errors, test failures, or other issues

4. Make targeted fixes based on the specific error messages found

5. Build locally after making fixes to verify the solution

The Azure DevOps REST API provides comprehensive build failure information without requiring browser access.