Change CLI flag --LogLevel to --log-level

[RubenCerna2079]

Why make this change?

• This solves issue [Bug]: --LogLevel should be --loglevel (and case insensitive) like all the other CLI flags #3257

What is this change?

We changed the dab start --LogLevel flag to --log-level in order to have it follow the conventions we already have. We also allow for the CLI to still use the previous --LogLevel flag but add a warning sign to ensure the user knows it is deprecated. Lastly, also changed all of the comments that mention the previous --LogLevel and updated it to use the new --log-level.
Added new isLogLevelLegacy value that is passed into the DynamicLogLevelProvider.cs which would then be used to add the log in case the deprecated flag is used in an Aspire scenario. In which the flag is passed to the dll directly and not through CLI

How was this tested?

• Integration Tests
• Unit Tests
  Changed the tests that were for --LogLevel so they now use --log-level and added a few extra cases to ensure the --LogLevel flag still works

Sample Request(s)

dab start --log-level information
dab start --LogLevel warning

[Copilot]

Pull request overview

This PR standardizes the dab start logging flag to --log-level to align with the CLI’s kebab-case conventions, while retaining the legacy --LogLevel as a deprecated alias and updating internal documentation/tests accordingly.

Changes:

• Renamed the dab start flag from --LogLevel to --log-level and introduced a hidden legacy option (--LogLevel) with a deprecation warning.
• Updated CLI/service log-level plumbing to pass --log-level through to the engine and refreshed comments/docs to match.
• Updated unit/end-to-end tests to use --log-level, adding coverage for the legacy flag still functioning.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Service/Startup.cs	Updates comments to reference the new --log-level startup argument.
src/Service/Program.cs	Updates service-side CLI arg parsing/docs to use --log-level for log level initialization.
src/Service.Tests/UnitTests/DynamicLogLevelProviderTests.cs	Updates test docs to reference --log-level.
src/Core/Telemetry/ILogLevelController.cs	Updates interface docs for precedence to reference --log-level.
src/Cli/Utils.cs	Updates CLI state/docs to reference --log-level.
src/Cli/Properties/launchSettings.json	Modifies CLI debug profile arguments (currently includes a machine-specific path).
src/Cli/Program.cs	Updates early flag parsing to detect --log-level before logger creation.
src/Cli/Exporter.cs	Updates StartOptions construction to include new legacy parameter.
src/Cli/CustomLoggerProvider.cs	Updates comments to reference --log-level behavior in MCP stdio mode.
src/Cli/ConfigGenerator.cs	Implements legacy --LogLevel handling with a deprecation warning and forwards --log-level to the engine.
src/Cli/Commands/StartOptions.cs	Adds --log-level option and a hidden legacy --LogLevel option.
src/Cli.Tests/EndToEndTests.cs	Updates E2E tests to use --log-level and adds legacy --LogLevel cases.
src/Cli.Tests/CustomLoggerTests.cs	Updates test docs to reference --log-level.
src/Azure.DataApiBuilder.Mcp/Core/McpStdioServer.cs	Updates MCP docs/comments to reference --log-level.

Comments suppressed due to low confidence (1)

src/Cli/Program.cs:67

• ParseEarlyFlags only detects the new --log-level flag. If a user uses the legacy --LogLevel flag (which this PR intends to keep working), the early logging state (Utils.IsCliOverriding/Utils.CliLogLevel) won’t be set, which can keep CLI logs suppressed in MCP stdio mode despite the user explicitly opting in to logging.

                else if (string.Equals(arg, "--log-level", StringComparison.OrdinalIgnoreCase) && i + 1 < args.Length)
                {
                    Utils.IsCliOverriding = true;
                    if (Enum.TryParse<LogLevel>(args[i + 1], ignoreCase: true, out LogLevel cliLogLevel))
                    {

[souvikghosh04]

Posting comments so far. rethink if we really need the legacy flag or should error out on unsupported format as we generally do and document these.

[souvikghosh04]

do we really need this branch logic? since the new naming convention will be part of new release and documented anyways. instead, the unsupported format should ideally error out instead of a warning or silent fallback.

[RubenCerna2079]

I think it should throw a warning right now since we are not sure if there are any users that are currently using the old flag. We need to give them time to adapt to the new flag before it is completely deprecated.

[souvikghosh04]

supporting multiple flag options for same functionality would be confusing and erroneous in future. The docs are essentially the single source of truth and users must follow that. If you really want to keep this for now, please create a task to clean this up sometime later and update the docs. also, its only recently this was introduced and this might not be used much. so it shouldn't be a problem to deprecate this.

[souvikghosh04]

Looks good. Just make sure to cleanup the deprecated flag as supporting both would create confusion.