[Feature] .gcmon Config File

[workgroupengineering]

Allow dotnet-gcmon to recursively crawling the configuration file like .editorconfig

[MokoSan]

@workgroupengineering, could you please clarify what you mean by "recursively crawling configuration"? From my understanding, .editorconfig allows to override behavior based on the folder you are in. I am missing how adding different config files to different directories will help override the logic. Unless you meant: if changes are dynamically added, the process should automatically pick it up using an abstraction like the FileWatcher?

[workgroupengineering]

dotnet-gcmon first checks the current directory if .gcmon exists, if not found it recursively searches the parent folder until it is found or arrived to the root of the volume. If no .gcmon was found, default configuration is used.

[Maoni0]

can you please explain what would be the value of providing this? we already have the option to allow the user to specify a config of their choice.

[workgroupengineering]

• less verbose command line arguments
• multilevel configuration example:

  solution            
    └.gcmon
    └Prj1
         └.gcmon
         └Prj1.csproj
         └....
    └Prj2
         └Prj2.csproj
         └...
  

  in the example above if you run dotnet-gcmon in the Prj1 folder, dotnet-gcmon using config preset in the current directory, otherwise dotnet-gcmon will use the configuration present at the solution level.

[Maoni0]

we already have a default config file so you don't need to specify a config on the commandline unless you want to change it. most users would use that config file. the scenario you illustrated is only for folks who actually do development on the tool which is a very small percentage. so introducing yet another config doesn't seem warranted. it's another config for the tool to maintain/care about.