I've worked on improvements for a 2.3 release. This includes some stability, performance and usability side. A full list of known changes are provided below, as described in the README.md. It has been thoroughly tested in both Console and Windows App versions.
CLI changes
--console --help doesn't hang AND displays console-based help
Incomplete CLI parameters will now generate a --help section.
Help messages shown when any file locations specified don't exist, e.g. imported results files or target directories
Added extra CLI messages on guidance not to interfere with the CLI when the tool is running.
CLI will not process anything unless you specify an output file type (XML, CSV or Flat File).
Logging has been enhanced showing the following messages:
[+] - Informational (normal output)
[*] - Verbose, using -v flag
[!] - Errors
Windows Application changes
UI redesign includes:
Target Directory box is now auto-complete
Language selection is via dropdown instead of menu
Press Enter when both Target Directory and Language is chosen, and it will run a Target Scan
Various new MsgBox's to confirm your actions where results need to be re-generated
Progress bars are now more informative on file counts
Visual Styles have been enabled, making the UI look more modern.
Running this app from the console with just --help and without --console will display a UI-based help both (a la SysInternals).
Removed popup to remind you to select a language when starting up.
Progress bar window allows aborting when running scans
Fixed UI form bug that prevented the app being closed.
Fixed other UI bug relating to the progress bar's being displayed.
Fixed bug where the GUI-version crashed, if a user loaded it from the Console, and was not in the working directory of the .exe
Fixed bug where file-level line numbers were being accumulated as a total, instead of per-file.
Development-relevant changes
Project updated to .NET Framework 4.8.1
Installer has new pre-requisite of .NET 4.8.1
Centralised logging for the CLI, honouring any --console and --verbose flags provided.
Code tidied up to remove inline asAppSettings.IsConsole = True, as these are honoured when printing.
Moved COM call for AttachProcess() to a NativeMethods module, per MS guidance
Removed unused Imports across the solution
Added a --debug flag debugging the CLI. When in DEBUG mode, you can attach the debuger using --console --debug
Other project changes
README.txt is now README.md
Docs updated to reflect new UI
.ASP filter now only applies to VB.
Known issues
The CLI isn't locked from user input when using the --console mode.
In short, VCG runs natively as a Windows Application. By its nature, it releases control back to the console when started. VCG is therefore writing to a console session thats already ended.
From a development side, VS 2022 (and earlier) generates scaffold code for Windows Applications, though the Application.Designer.vb class. It gets re-generated on every build, so any direct modifications to it will be wiped out. If the project type is switched to a Console Application, it modifies this auto-generated file to the point it no longer builds at all. Consider also, that if this was possible, the console window will remain open for the duration of the GUI session as well.
Also explored was creating entirely new projects but reflecting a Console build type. Trials included:
Adding VisualCodeGrepper.vbproj as a project reference. This doesn't work , as the referenced project generates an .exe. Its can't reference assemblies that result in .exe's
Modifying the settings with the .vbproj file to create a console output. As mentioned, the scaffolding file will generated an incompatible file, resulting in dozens of build errors relating to variable scoping.
Creating new compilation profiles, but these only change the Configuration/Platform. The settings for the most part are consistent throughout all builds.
The overall resolution to cleanly separate the GUI from the Console is a re-architecture of the application. For a minor release anyway, this isn't possible. Perhaps look to implement an MVP-style app?
I've worked on improvements for a 2.3 release. This includes some stability, performance and usability side. A full list of known changes are provided below, as described in the README.md. It has been thoroughly tested in both Console and Windows App versions.
CLI changes
--console --helpdoesn't hang AND displays console-based help--helpsection.[+]- Informational (normal output)[*]- Verbose, using-vflag[!]- ErrorsWindows Application changes
--helpand without--consolewill display a UI-based help both (a la SysInternals).Development-relevant changes
--consoleand--verboseflags provided.asAppSettings.IsConsole = True, as these are honoured when printing.AttachProcess()to a NativeMethods module, per MS guidanceImportsacross the solution--debugflag debugging the CLI. When in DEBUG mode, you can attach the debuger using--console --debugOther project changes
Known issues
The CLI isn't locked from user input when using the
--consolemode.In short, VCG runs natively as a Windows Application. By its nature, it releases control back to the console when started. VCG is therefore writing to a console session thats already ended.
From a development side, VS 2022 (and earlier) generates scaffold code for Windows Applications, though the
Application.Designer.vbclass. It gets re-generated on every build, so any direct modifications to it will be wiped out. If the project type is switched to a Console Application, it modifies this auto-generated file to the point it no longer builds at all. Consider also, that if this was possible, the console window will remain open for the duration of the GUI session as well.Also explored was creating entirely new projects but reflecting a Console build type. Trials included:
VisualCodeGrepper.vbprojas a project reference. This doesn't work , as the referenced project generates an .exe. Its can't reference assemblies that result in .exe'sCreating new compilation profiles, but these only change the Configuration/Platform. The settings for the most part are consistent throughout all builds.
The overall resolution to cleanly separate the GUI from the Console is a re-architecture of the application. For a minor release anyway, this isn't possible. Perhaps look to implement an MVP-style app?
-- Jan 2023