| Added cstoolkit to extensions in devcontainer | 1 年前 |
| 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 个月前 |
| nuke parameters.json | 5 个月前 |
| session file composer | 1 个月前 |
| add licenses of nuget packages | 8 个月前 |
| 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 chocolatey/logexpert.portable.nuspec.template Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> | 1 年前 |
| update link | 1 年前 |
| Update TabControllerTests.cs Spaces fix (again) and other requests. | 8 天前 |
| removed a lot off no longer necessary dependency checks | 2 个月前 |
| Handle all line endings exactly in Direct stream reader PositionAwareStreamReaderDirect now detects the actual terminator per line instead of guessing one constant for the whole file. It scans with IndexOfAny(SearchValues.Create("\r\n")) and classifies each hit as \n, \r\n, or a bare \r (classic-Mac), including the \r-at-block-boundary straddle. Byte Position advances by the content bytes plus the real terminator's bytes, so it stays exact on files that interleave line endings. This folds the two capabilities that previously only System/Legacy had into the default reader: - bare \r no longer renders a classic-Mac file as one giant line - Position no longer drifts on mixed \n/\r\n files, keeping seeks into flushed buffers correct The guessed _newLineSequenceLength field and GuessNewLineSequenceLength (with its seek-reset-reread) are replaced by a lazy EnsureInitialized that fills the first block from the current stream position, plus a ResetReader override that resets scan state on a mid-stream seek (also fixing a latent stale-block scan after a Position change). Tests: 11 new TDD cases covering bare \r, mixed endings, repeated terminators, trailing \r and \r\n, \n\r, multibyte exact positions, and \r / \r\n landing exactly on the 32 KB block boundary. Full reader suite green (97 tests); Direct throughput benchmark shows no regression. Adds byte-exact manual/GUI fixtures (LF, CRLF, CR, Mixed) under TestData with a regenerator and README, pinned `binary` in .gitattributes so core.autocrlf cannot corrupt their terminators. | 2 个月前 |
| fixing a possible Exception when opening LXPs with table layout xml | 2 个月前 |
| switched over to nuke build added powershell scripts for debug and release added signing key | 7 年前 |
| switched over to nuke build added powershell scripts for debug and release added signing key | 7 年前 |
| Inno Setup Script added Change log template added Setup can now be created | 7 年前 |
| fix: store the window's own filter in Session Files, not the global list A Session File used to save a copy of the whole global filter list (Settings.FilterList) as its FilterParamsList, while load only ever restored [0]. Sessions were therefore not self-contained: what an .lxp "remembered" as its filter was whatever the global list happened to hold at save time, and the window's actual filter was restored only if it happened to be that list's first entry. The copy was shallow too, so the pre-save IsFilterTail write aliased into the shared global entry. The snapshot now carries the window's own _filterParams. The on-disk shape is unchanged - FilterParamsList stays a list, holding exactly one entry - and load still reads [0], so existing Session Files (JSON and legacy XML alike) keep loading exactly as before; their trailing entries, which nothing ever restored, are dropped on the next save. Adds Window Filter / Saved Filter List to the glossary, since the change turns on exactly that distinction. Closes #666 | 1 个月前 |
| update gitversion | 5 个月前 |
| Update ISSUE_TEMPLATE.md | 8 年前 |
| Modify LICENSE with year update and badge Updated license year and added badge. | 3 个月前 |
| Update README.md release badge | 2 个月前 |
| update version, removed autoscalemode | 1 年前 |
| add gitversion.yml | 4 年前 |
| Updated the nuke build system to version 9. appveyor.yml image updated to vs2022. appveyor-release.yml removed the image. The build changes were done with the help of: TheNicker Hirogen | 1 年前 |
| Updated the nuke build system to version 9. appveyor.yml image updated to vs2022. appveyor-release.yml removed the image. The build changes were done with the help of: TheNicker Hirogen | 1 年前 |
| Merge branch 'Development' into dot-net-8 # Conflicts: # .gitignore # .nuke/build.schema.json # .nuke/parameters.json # build.ps1 # build/Build.cs # build/_build.csproj # src/AutoColumnizer/AutoColumnizer.csproj # src/ColumnizerLib.UnitTests/ColumnizerLib.UnitTests.csproj # src/ColumnizerLib/ColumnizerLib.csproj # src/CsvColumnizer/CsvColumnizer.csproj # src/DefaultPlugins/DefaultPlugins.csproj # src/FlashIconHighlighter/FlashIconHighlighter.csproj # src/GlassfishColumnizer/GlassfishColumnizer.csproj # src/JsonColumnizer/JsonColumnizer.csproj # src/JsonCompactColumnizer/JsonCompactColumnizer.csproj # src/Log4jXmlColumnizer/Log4jXmlColumnizer.csproj # src/LogExpert.Tests/DateFormatParserTest.cs # src/LogExpert.Tests/Extensions/EnumerableTests.cs # src/LogExpert.Tests/JSONSaveTest.cs # src/LogExpert.Tests/JsonColumnizerTest.cs # src/LogExpert.Tests/LogExpert.Tests.csproj # src/LogExpert.Tests/LogStreamReaderTest.cs # src/LogExpert.Tests/LogWindowTest.cs # src/LogExpert/Controls/LogTabWindow/LogTabWindow.cs # src/LogExpert/Controls/LogTabWindow/LogTabWindow.designer.cs # src/LogExpert/Controls/LogWindow/LogWindow.designer.cs # src/LogExpert/Controls/LogWindow/LogWindowEventHandlers.cs # src/LogExpert/Controls/LogWindow/LogWindowsPublic.cs # src/LogExpert/Dialogs/BufferedDataGridView.cs # src/LogExpert/Dialogs/DateTimeDragControl.cs # src/LogExpert/Dialogs/SettingsDialog.cs # src/LogExpert/LogExpert.csproj # src/LogExpert/Program.cs # src/RegexColumnizer.UnitTests/RegexColumnizer.UnitTests.csproj # src/RegexColumnizer.UnitTests/RegexColumnizerTests.cs # src/RegexColumnizer/RegexColumnizer.csproj # src/SftpFileSystemx64/SftpFileSystemx64.csproj # src/SftpFileSystemx64/SftpLogFileInfo.cs # src/SftpFileSystemx86/SftpFileSystemx86.csproj # src/Solution Items/AssemblyVersion.cs # src/WinFormsUI/WinFormsUI.csproj | 1 年前 |
| Plan initial research and copilot instructions development Co-authored-by: Hirogen <8225398+Hirogen@users.noreply.github.com> | 11 个月前 |
| change to 10.0.100 because 10.0.202 needs ms build 18.4 which for some reason does not work | 4 个月前 |
