The validation approach here is inconsistent with the pattern used in the base class BaseCsvWritingCommand.BeginProcessing(). Similar parameter conflict validations (lines 116-128) use MyInvocation.BoundParameters.ContainsKey() to check if parameters were explicitly bound, while this code uses .IsPresent on SwitchParameter properties.

Using .IsPresent can produce different behavior because it returns true if the switch is explicitly set to $true or $false, whereas BoundParameters.ContainsKey() only returns true when the parameter was actually specified by the user.

For consistency with the existing validation pattern, consider using:

if (this.MyInvocation.BoundParameters.ContainsKey(nameof(Append)) && this.MyInvocation.BoundParameters.ContainsKey(nameof(NoHeader)))

@yotsuda I think we should follow a pattern which we now use for all switches in your recent PRs.

@iSazonov Thank you for the guidance. I understand I should change line 274 to follow the pattern from my recent PRs.

After reviewing the parameter types, I found:

Switch parameters (can use direct property check):

• IncludeTypeInformation (line 52)
• NoTypeInformation (line 59)
• NoHeader (line 79)
• Append (line 244)

Non-switch parameters (should keep BoundParameters.ContainsKey()):

• QuoteFields (line 66) - string[]
• UseQuotes (line 73) - QuoteKind enum

Proposed changes:

1. Line 274 (new code):

// Change from:
if (Append.IsPresent && NoHeader.IsPresent)
// To:
if (Append && NoHeader)

1. Line 123 (existing code, also switch parameters):

// Change from:
if (this.MyInvocation.BoundParameters.ContainsKey(nameof(IncludeTypeInformation)) && 
    this.MyInvocation.BoundParameters.ContainsKey(nameof(NoTypeInformation)))
// To:
if (IncludeTypeInformation && NoTypeInformation)

1. Line 116 (keep as-is, non-switch parameters):

// Keep unchanged (QuoteFields and UseQuotes are not switch parameters):
if (this.MyInvocation.BoundParameters.ContainsKey(nameof(QuoteFields)) && 
    this.MyInvocation.BoundParameters.ContainsKey(nameof(UseQuotes)))

Should I update both line 123 and line 274 to use the new pattern in this PR?

I'd prefer to keep the PR as small as possible (fix only new code) and fix other lines in new PR.

Understood. I've updated only the new code in commit 061a6fc to simplify the condition to if (Append && NoHeader).

The ErrorCategory used here (InvalidArgument) is inconsistent with similar parameter validation errors in this codebase. Lines 119, 126, and 269 all use ErrorCategory.InvalidData for parameter conflict validations.

For consistency, this should use ErrorCategory.InvalidData instead of ErrorCategory.InvalidArgument.

If InvalidArgument is more appropriate we should fix all lines.

Investigation Results

I investigated the ErrorCategory usage for parameter conflict validation across the codebase.

Current Implementation in CsvCommands.cs

Comparison with Other Cmdlets

Analysis

ErrorCategory Semantics:

• InvalidArgument: The argument value itself is invalid (wrong type, out of range, etc.)
• InvalidData: The data content or state is invalid (corrupted file, invalid combination, etc.)

Current State:

• CsvCommands.cs: 4 existing validations use InvalidData
• Format- cmdlets*: Use InvalidArgument for parameter conflicts
• My PR: Line 277 uses InvalidArgument (inconsistent with this file)

Proposal

I see three possible approaches:

Option A: Change line 277 to InvalidData (maintain consistency within this file)

• ✅ File-level consistency: All validations in CsvCommands.cs use InvalidData
• ✅ Minimal change: Only affects the new code, reducing risk
• ✅ Backward compatibility: No changes to existing error handling
• ✅ Semantic validity: Parameter combinations can be considered "invalid data"

Option B: Change all 5 validations in CsvCommands.cs to InvalidArgument (align with Format-* cmdlets)

• ✅ Consistency with Format-* cmdlets across the codebase
• ✅ Semantically more accurate: "argument conflicts" rather than "data conflicts"
• ⚠️ Changes existing code with potential impact on error handling scripts
• ⚠️ Broader scope and testing required

Option C: Keep InvalidArgument for line 277 and file a separate issue

• ⚠️ Leaves inconsistency within CsvCommands.cs
• ✅ Defers broader discussion to dedicated issue

Recommendation

I lean toward Option A for this PR to minimize scope and risk.

Future consideration: A separate issue/PR could be created to unify all parameter conflict validations across the codebase to use InvalidArgument, which would align with Format-* cmdlets.

Which approach would you prefer?

I agree with Option A.

Both InvalidArgument and InvalidData are not good. We could think about InvalidParameter. But this will require approval by PowerShell Committee since it is change in public API. I'm afraid it will take a long time. But if you want, then create a new issue. There we could discuss whether we can consider a parameter as an argument of cmdlet.

Thank you for the explanation. I've updated to InvalidData in commit 061a6fc to keep this PR focused.