| refactor: anchor build output paths on the repo instead of $(SolutionDir) Closes the "TODO: Normalize this across solution" on the commented-out OutputPath in Directory.Build.props. $(SolutionDir) is only defined when MSBuild is driven by the .sln. Fourteen projects spelled their output as "$(SolutionDir)..\bin\...", so under a solution build that resolved to bin\, but a lone `dotnet build Foo.csproj` resolved the same text relative to the project and quietly wrote to src\bin\ instead - while the Nuke targets, the installer file list and the CI artifact all look in bin\. Nothing failed; the single-project build just stopped agreeing with everything else. It cost real time during the plugin-hash work, where a lone build looked reproducible only because the file being hashed was a stale leftover. Anchor the paths on $(MSBuildThisFileDirectory) instead and name them once: LogExpertBinRoot / LogExpertBinDirectory / LogExpertPluginsDirectory / LogExpertPluginsX86Directory / LogExpertDocsDirectory Configuration has to be defaulted alongside them: Directory.Build.props is imported before the SDK defaults it, and an empty value silently collapses bin\Debug\ to bin\. The condition leaves an explicit -c or a solution build untouched. Also folded in: - the two DocumentationFile paths, which had the same $(SolutionDir) defect - four test projects that hand-wrote <OutputPath>bin\$(Configuration)</OutputPath>, which is exactly the SDK default once AppendTargetFrameworkToOutputPath=false - PluginHashGenerator.targets now reads the shared properties rather than re-deriving the plugins directory, so the two cannot drift apart The $(SolutionDir) use left in src/SDK/ is deliberate: those samples are built from their own solution by plugin authors, not by ours. Output layout is unchanged - verified byte-for-byte against a pre-change snapshot: same 18 directories under bin/Release, same 65 files at its root, 19 plugins, 10 pluginsx86, both XMLs in bin/Docs. Lone builds of AutoColumnizer, SftpFileSystemx86, ColumnizerLib and LogExpert now land there too and no longer create src\bin. Plugin hash table still 21 entries in both configurations, all matching the shipped binaries. Full suite: 1491 passed, 7 skipped, 0 failed. | 1 个月前 |
| fix: portable mode re-prompting and stray trusted-plugins.json in AppData (#658) Opening the settings dialog while portable mode was active fired the portable-mode CheckedChanged handler during FillDialog, re-running the activation flow (copy-settings question dialog, marker file) on every open. FillPortableMode now detaches the handler while syncing the checkbox from preferences and owns the Activate/Deactivate label. PluginValidator eagerly loaded the trust configuration in its static constructor, creating trusted-plugins.json in %APPDATA%/LogExpert before Initialize could point it at the active (portable) config directory. The configuration is now loaded lazily at Initialize or first use, so the file is only ever written to the active directory. | 1 个月前 |