enhancement: C# and VB .NET Format Fixes

[TommyE123]

C# and VB .NET Format Fixes

Issues Identified

1. Performance: Scanning operations often take hours or timeout instead of completing within minutes.
   a. Redundant scanning: Both C# and VB linters scan for both file types if either exists, leading to duplicate scans and unnecessary processing.
   b. Overzealous linting: The dotnet format linter runs the command for every .cs and .vb file, causing thousands of duplicate logs and severely impacting performance.

2. Inaccurate Error Count: The summary results and logs show incorrect error amounts.

3. Multiple Solution Files: The linter fails to run if there's more than one .sln file in the root directory.

4. Subdirectory Solution Files: Neither language can run if the .sln file is in a subdirectory.

5. Project File Specification: Unable to specify a list of .csproj or .vbproj files to lint.

Note: While some of these issues might be circumvented using configuration overrides, this approach would require in-depth knowledge of MegaLinter and how to achieve better outcomes. The proposed changes aim to address these issues more systematically.

Proposed Changes

1. Performance Improvement:

   • Changed linters to use cli_lint_mode: project instead of list_of_files.
     • Pro: Massive speed improvement.
     • Con: Displays N/A for files linted (minor drawback).
   • Added language-specific file inclusion:
     • C#: --include **/*.cs
     • VB: --include **/*.vb
     • Reduces issue duplication and prevents cross-language linting errors.

2. Error Count Fix: Implemented correct regex to accurately count errors across all files for each language.

3. Solution File Handling:

   • Removed {{WORKSPACE}} argument to allow specifying a single .sln file.
   • Addresses issues with multiple .sln files and subdirectory locations.

4. Command Structure:

   • Moved --verify-no-changes and new include arguments to extra args.
   • Allows for overriding .sln or .proj files in the correct command position.

These changes aim to significantly improve performance, accuracy, and flexibility of the dotnet format linter for both C# and VB.NET projects, without requiring extensive MegaLinter configuration knowledge.

[echoix]

Do you mean the tool when called on a workspace gets launched multiple times?

[echoix]

I took a look, but I don't know what to think very much about it.

Does dotnet format run on files that are more in their web-based environment (not exactly aspnet, but the ones where there is html and csharp)? If so, is using the glob limited to .cs prevent users from configuring it?

[TommyE123]

I've attached the results showing the before and after effects of the changes I've made. This is a basic test solution with multiple projects and minimal code.

As you can see, the current MegaLinter version duplicates the complete error list for every file, significantly increasing the processing time as it's running the command for each file found, which isn't necessary. For more complex solutions, this approach could take hours to complete, potentially timing out before finishing.

The revised changes eliminate these repetitive error listings, improving efficiency.
Additionally, I've resolved an issue where the C# linter was processing VB files and vice versa. Now, each linter only processes its respective language files.

Regarding file types, I couldn't find any evidence through searching or my testing to suggest that the dotnet format command would process file types other than .cs and .vb, which I'm setting the include path to find for each.

Current logs.txt
New logs.txt

As always, if there are any issues or concerns, please let me know.
Tom

[nvuillam]

Looks great to me, but as I have no experience about vb or dotnet, I prefer to let @echoix or @bdovaz validate :)

[nvuillam]

thanks @echoix :)

& thanks @TommyE123 for the PR :)