dohertj2/wwtools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mbproxy: strip historical phase/wave/plan references from source comments

Browse Source 
Comments described the *history* of how the code arrived (phase numbers,
wave IDs, review IDs, dated TODOs) instead of what it does today. That
scaffolding rotted as the codebase evolved. Cleaned 60 source files +
.gitignore; behaviour unchanged (387/387 tests still pass).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-05-14 13:04:30 -04:00
parent b3b8313e9c
commit 1a2856526a
60 changed files with 750 additions and 811 deletions
Download Patch File Download Diff File Expand all files Collapse all files
mbproxy/src/Mbproxy/Mbproxy.csproj
+12 -14
View File
@@ -8,16 +8,15 @@
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<RootNamespace>Mbproxy</RootNamespace>
<AssemblyName>Mbproxy</AssemblyName>
<!-- Phase 08: Assembly version. CI can override via /p:InformationalVersion=... -->
<!-- Assembly version. CI can override via /p:InformationalVersion=... -->
<InformationalVersion>1.0.0</InformationalVersion>
</PropertyGroup>
<!-- Phase 08: single-file self-contained publish (Release only; Debug stays normal for fast iteration).
NOTE: the resulting Mbproxy.exe is ~100 MB because the self-contained publish bundles the full
.NET 10 + ASP.NET Core runtime. This exceeds the original 50 MB target in the phase spec;
the runtime size is a fixed cost of self-contained deployment on .NET 10 with ASP.NET Core.
Operators who need a smaller footprint can use a framework-dependent publish
(dotnet publish -c Release -r win-x64 - -self-contained false /p:PublishSingleFile=true)
<!-- Single-file self-contained publish (Release only; Debug stays normal for fast iteration).
The resulting Mbproxy.exe is ~100 MB because the self-contained publish bundles the full
.NET 10 + ASP.NET Core runtime — fixed cost of self-contained deployment on .NET 10 with
ASP.NET Core. Operators who need a smaller footprint can use a framework-dependent publish
(dotnet publish -c Release -r win-x64 -p:SelfContained=false -p:PublishSingleFile=true)
if the target machine has .NET 10 installed. -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<PublishSingleFile>true</PublishSingleFile>
@@ -27,7 +26,7 @@
</PropertyGroup>
<ItemGroup>
<!-- ASP.NET Core for the Phase 07 Kestrel-hosted admin endpoint. -->
<!-- ASP.NET Core for the Kestrel-hosted admin endpoint. -->
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
@@ -50,12 +49,11 @@
</ItemGroup>
<ItemGroup>
<!-- Phase 12 (W2.21) — link the install template as the published appsettings.json
so the binary ships with a fully-commented, usable example config (one PLC, one
BCD tag, all sections present) instead of an empty stub. The .NET configuration
loader supports JSONC (comments) under the default Host.CreateApplicationBuilder
path, so the comments in the template are valid at runtime.
A fresh `dotnet run` from src/Mbproxy is no longer a no-op service. -->
<!-- Link the install template as the published appsettings.json so the binary ships
with a fully-commented, usable example config (one PLC, one BCD tag, all sections
present) instead of an empty stub. The .NET configuration loader supports JSONC
(comments) under the default Host.CreateApplicationBuilder path, so the comments
in the template are valid at runtime. -->
<None Remove="appsettings.json" />
<Content Include="..\..\install\mbproxy.config.template.json"
Link="appsettings.json">