GGitHubUpdate TabControllerTests.cs
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
removed ..svnbridge folders | 8 年前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
wrong amount of dlls in the setup, hidden exception and no longer a follow tail possible | 2 个月前 | |
refactor: inject IPluginRegistry into LogWindow Replaces the 12 static PluginRegistry.Instance reaches in LogWindow with a constructor-injected IPluginRegistry, mirroring the IConfigManager pattern. Widens IPluginRegistry with RegisteredContextMenuPlugins and FindKeywordActionPluginByName (both already on the concrete registry) so the keyword-action trigger lookup and context-menu population go through the seam. | 1 个月前 | |
refactor: address code review of the encoding dropdown fix - Move FallbackEncoding into the Properties region, where the file keeps its other properties. - Use pattern matching instead of `as` + null check on the rewritten SavePreferences line. - Stop seeding Preferences.DefaultEncoding from Encoding.Default in ConfigManager. Identical text on .NET, but it named the one instance the dropdown no longer offers. - Rename the ComboBox round-trip test to the file's subject-first convention, and record why it is kept alongside the non-STA assertion. - Fix a doc comment still pointing at Encoding.Default as the degrade target. | 1 个月前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 | |
fix: degrade malformed legacy XML Session Files instead of throwing A legacy XML .lxp whose <file> element has no <options> child threw NullReferenceException out of PersisterXML.ReadOptions. Persister.Load calls the XML reader from inside its JSON catch block, so the NRE replaced the original exception and propagated up the synchronous file-open path, where nothing handles it. ReadOptions now skips the options section when it is absent, leaving those settings at their PersistenceData defaults. The tab, columnizer and highlightGroup elements are siblings of <options>, not children, so they moved out of the guarded region and are still read — an early return would have cost the user their columnizer for a file that merely lacks options. The body that does need the node moved to ReadOptionsNode. ReadPersistenceDataFromNode now honours its own documented contract and returns defaults for a node that is not an element, which is what a comment among the filterTab children produces. PersisterXML.Load is documented to return null on unparseable input, but only caught malformed markup. This is a read-only fallback for a format LogExpert no longer writes, and its readers assume a well-formed document, so the catch now also covers the exceptions malformed *content* raises: FormatException, OverflowException, ArgumentException and NullReferenceException. Each is pinned by a test case. Closes #680 | 1 个月前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 | |
Update TabControllerTests.cs Spaces fix (again) and other requests. | 14 天前 | |
Update TabController.cs Spaces alignment | 14 天前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
Organize solution and project files to be more streamlined | 1 年前 | |
Add Chinese Multilingual | 7 个月前 | |
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 个月前 | |
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 个月前 | |
chore: update usedComponents.json for v1.42.0 [skip ci] (#690) Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 1 个月前 | |
update for gitversion | 6 个月前 | |
refactor: generate built-in plugin hashes at build time instead of committing them PluginValidator's hash table was a committed file regenerated after the build that produced it, then committed as a new commit. That ordering could never be right: the table described the previous build's binaries, and committing it changed HEAD, which changed the binaries again. CI papered over it by auto-committing the churn on Development and by gating fork PRs on a diff that could not come out clean. Generate it during the build instead. PluginHashGenerator.targets hashes the plugin DLLs before PluginRegistry compiles and writes the table into obj/, so every build's table matches that build's own binaries by construction. The plugins are guaranteed to exist first via build-order-only ProjectReferences (ReferenceOutputAssembly=false) from PluginRegistry to each plugin project - making explicit a dependency PluginRegistry already had, since it hardcoded their hashes. Hashing now uses MSBuild's built-in GetFileHash rather than a separate console project, which also breaks the cycle that project would otherwise create: it referenced PluginRegistry, which now needs the table before it compiles. Removed as a result: - src/PluginHashGenerator.Tool (the console generator) - the committed PluginHashGenerator.Generated.cs - Nuke's GeneratePluginHashes target, including the PluginRegistry rebuild it needed and the version-stamping hazard that rebuild carried - the Generate / Verify / Commit steps in build_dotnet.yml, and that job's write permissions - the plugin-hash half of release.yml's generated-files PR This also makes commit-to-commit reproducibility unnecessary, so EnableSourceControlManagerQueries=false is reverted and SourceLink is restored. Verified on a clean Release build: all 21 table entries match the SHA256 of the DLLs shipped in bin/Release/plugins and pluginsx86, with the commit sha back in InformationalVersion. Debug and Release both generate 21 entries. Full suite passes: 1491 passed, 7 skipped, 0 failed. | 1 个月前 | |
update plugins | 9 个月前 | |
wrong amount of dlls in the setup, hidden exception and no longer a follow tail possible | 2 个月前 | |
missing sln for the LogRotator | 3 个月前 | |
update settings, should now no longer be lost added old xml persister, so if the new json one fails, it tries the old one new files are still saved in the json format, but old ones are converted | 9 个月前 | |
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 个月前 | |
wrong amount of dlls in the setup, hidden exception and no longer a follow tail possible | 2 个月前 | |
refactor: generate built-in plugin hashes at build time instead of committing them PluginValidator's hash table was a committed file regenerated after the build that produced it, then committed as a new commit. That ordering could never be right: the table described the previous build's binaries, and committing it changed HEAD, which changed the binaries again. CI papered over it by auto-committing the churn on Development and by gating fork PRs on a diff that could not come out clean. Generate it during the build instead. PluginHashGenerator.targets hashes the plugin DLLs before PluginRegistry compiles and writes the table into obj/, so every build's table matches that build's own binaries by construction. The plugins are guaranteed to exist first via build-order-only ProjectReferences (ReferenceOutputAssembly=false) from PluginRegistry to each plugin project - making explicit a dependency PluginRegistry already had, since it hardcoded their hashes. Hashing now uses MSBuild's built-in GetFileHash rather than a separate console project, which also breaks the cycle that project would otherwise create: it referenced PluginRegistry, which now needs the table before it compiles. Removed as a result: - src/PluginHashGenerator.Tool (the console generator) - the committed PluginHashGenerator.Generated.cs - Nuke's GeneratePluginHashes target, including the PluginRegistry rebuild it needed and the version-stamping hazard that rebuild carried - the Generate / Verify / Commit steps in build_dotnet.yml, and that job's write permissions - the plugin-hash half of release.yml's generated-files PR This also makes commit-to-commit reproducibility unnecessary, so EnableSourceControlManagerQueries=false is reverted and SourceLink is restored. Verified on a clean Release build: all 21 table entries match the SHA256 of the DLLs shipped in bin/Release/plugins and pluginsx86, with the commit sha back in InformationalVersion. Debug and Release both generate 21 entries. Full suite passes: 1491 passed, 7 skipped, 0 failed. | 1 个月前 | |
add gitignore and json stuff also umbiquitous language for better understanding of logexpert | 4 个月前 |