v0.18 Release

[csharpfritz]

v0.18 Release

Includes all work merged to dev since v0.14:

• BWFC013/014 analyzers, architecture guide, CI docs
• Roslyn Analyzer documentation and samples
• Medium effort fidelity divergences docs, ID rendering tests
• Quick wins - sample pages, docs, and integration tests
• Docs and sample pages for 6 sub-100% components
• Tier 2: Property/event gaps + health detection fixes
• Health scoring accuracy improvements + CI snapshot generation
• Audit gap fixes - ID rendering, RouteData bug, style docs
• 5 remaining AJAX Control Toolkit extenders
• ASHX/AXD middleware handling + deprecation guidance docs
• Cross-platform line ending fix for code fix providers

To fix the problem, remove the useless assignment to root. Since the value of root is never read, we can safely delete the entire line that calls document.GetSyntaxRootAsync(...). There is no need to replace it with anything (such as discarding to _), because the call itself is not needed and has no required side effects.

Concretely, in src/BlazorWebFormsComponents.Analyzers/IsPostBackUsageCodeFixProvider.cs, inside the CommentOutIsPostBackAsync method, delete line 41:

var root = await document.GetSyntaxRootAsync(cancellationToken).ConfigureAwait(false);

No other lines in this file need to change, and no additional imports, methods, or definitions are required. The method will then start directly by locating the StatementSyntax from diagnosticNode, as it already does after the unused root assignment.

To fix the problem, remove the useless assignment to root and the associated call to GetSyntaxRootAsync, since its result is not used anywhere in CommentOutViewStateAsync. This keeps the method’s observable behavior the same while avoiding unnecessary work and eliminating the dead local variable.

Concretely, in src/BlazorWebFormsComponents.Analyzers/ViewStateUsageCodeFixProvider.cs, inside the CommentOutViewStateAsync method, delete the line:

var root = await document.GetSyntaxRootAsync(cancellationToken).ConfigureAwait(false);

No additional imports, methods, or definitions are required. The rest of the method already uses document and diagnosticNode directly and does not depend on root, so functionality remains unchanged.

In general, to fix a “useless assignment to local variable” you either remove the variable (and possibly the whole statement) if it is not needed, or start using it in the logic if it was supposed to be used. Here, the concrete pattern match introduces parentMember but never uses it; only the fact that parent might be a MemberAccessExpressionSyntax appears to have been of interest. The simplest fix that preserves current behavior is to remove the variable from the pattern and keep only a type check, or remove the entire if if that check is also unnecessary.

The single best minimal fix without changing functionality is to change line 72 from a pattern with a bound variable to a plain type check: if (parent is MemberAccessExpressionSyntax). This keeps the structure and comments about “parent is MemberAccessExpressionSyntax” but removes the unused parentMember variable, silencing the CodeQL warning. No new imports, methods, or additional definitions are required. Only the AnalyzeMemberAccess method in src/BlazorWebFormsComponents.Analyzers/SessionUsageAnalyzer.cs needs modification, at the if (parent is MemberAccessExpressionSyntax parentMember) line.

In general, to fix a “Missed 'readonly' opportunity” for a field, you add the readonly modifier to the field declaration when the field is only assigned at declaration or within constructors of the same class. This enforces that the field cannot be reassigned later, while leaving mutation of the object’s internal state (its properties) still possible.

For this specific case, update the field declaration on line 51 in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/NewProperties.razor from private ExampleModel model = new ExampleModel(); to private readonly ExampleModel model = new ExampleModel();. No other changes are required: the tests only read from model via Model="@model" in the EditForm, and the ExampleModel class remains mutable through its Name property. No imports or new methods are needed.

In general, to fix this kind of issue you add the readonly modifier to any field that is only assigned at its declaration or within a constructor of the same class. This guarantees the field reference cannot be changed after object initialization, while not affecting mutations to the object it refers to.

For this specific file, the best fix is to update the declaration of the private ExampleModel model field on line 40 to include the readonly modifier: private readonly ExampleModel model = new ExampleModel();. This does not change any behavior, because the field was never reassigned elsewhere in the shown code. No additional methods, imports, or other definitions are required.

In general, to fix this class of issues you move the filtering predicate from inside the loop body into a LINQ .Where(...) on the sequence you are iterating, so the foreach only runs over already‑filtered elements. This avoids an initial if (!condition) continue; or wrapping the whole body in if (condition).

Here, we should change foreach (var expr in creation.Initializer.Expressions) to iterate only over those expressions that are AssignmentExpressionSyntax with an IdentifierNameSyntax on the left. We can do this with a Where plus pattern matching in the lambda. The rest of the method (result.Add(...), returning the set) remains unchanged, so behavior is preserved.

Concretely, in src/BlazorWebFormsComponents.Analyzers/RequiredAttributeAnalyzer.cs, within GetInitializerAssignments, replace:

• the foreach (var expr in creation.Initializer.Expressions) header, and
• the inner if (expr is AssignmentExpressionSyntax ... ) { ... }

with a foreach that iterates over creation.Initializer.Expressions.Where(expr => expr is AssignmentExpressionSyntax { Left: IdentifierNameSyntax }), and a simplified pattern match inside the loop. No new imports are needed because System.Linq is already included.

In general, to fix this kind of issue you identify the foreach loop that conditionally processes elements based on an if inside the loop, and refactor it to iterate over a filtered sequence using Where. That is, instead of looping over all items and skipping those that fail the condition, you pre-filter the enumerable and then loop over only the relevant items.

For this specific code, we should change the loop:

foreach (var required in requiredProps)
{
    if (!assignedProperties.Contains(required))
    {
        var diagnostic = Diagnostic.Create(Rule, creation.GetLocation(), baseTypeName, required);
        context.ReportDiagnostic(diagnostic);
    }
}

to instead iterate only over those required properties that are not in assignedProperties. Since requiredProps is an array of strings and System.Linq is already imported (line 7), we can use:

foreach (var required in requiredProps.Where(required => !assignedProperties.Contains(required)))
{
    var diagnostic = Diagnostic.Create(Rule, creation.GetLocation(), baseTypeName, required);
    context.ReportDiagnostic(diagnostic);
}

This preserves the existing behavior exactly: diagnostics are still reported for each missing required property, but the filter is expressed with Where instead of an if inside the loop. No additional imports, methods, or type changes are needed; the change is localized to the foreach loop around line 90 in RequiredAttributeAnalyzer.cs.

To fix the problem, replace the if statement that assigns to commentedLines[i] in both branches with a single assignment using the conditional (?:) operator. This keeps the logic identical while making the code more concise and clearly expressing that only the value assigned changes based on the condition.

Concretely, in src/BlazorWebFormsComponents.Analyzers/IsPostBackUsageCodeFixProvider.cs, within the loop that builds commentedLines, replace lines 80–83:

• Remove the multi-line if (i == 0) ... else ... block.
• Add a single line: commentedLines[i] = i == 0 ? "// " + lineCode : lineIndent + "// " + lineCode;

No new methods, imports, or definitions are needed; this is a pure expression-level refactor.

Generally, to fix this kind of issue, replace a foreach loop that immediately filters inside the loop body with a LINQ query such as .Where(...), potentially combined with .FirstOrDefault()/.First() if only the first matching element is needed. This moves the filter predicate into the sequence definition instead of being embedded in loop control logic.

In this specific case, lines 64–71 iterate over method.GetLeadingTrivia(), look for the first trivia whose kind is SyntaxKind.WhitespaceTrivia, append that trivia to newLeadingTrivia, then break. To keep the behavior identical, we can compute the first whitespace trivia via LINQ, then append it if present:

var indentationTrivia = method.GetLeadingTrivia()
    .FirstOrDefault(t => t.IsKind(SyntaxKind.WhitespaceTrivia));

if (!indentationTrivia.Equals(default(SyntaxTrivia)))
{
    newLeadingTrivia = newLeadingTrivia.Add(indentationTrivia);
}

This removes the implicit filtering foreach entirely, replacing it with explicit filtering using LINQ (FirstOrDefault with a predicate, which is equivalent to Where(...).FirstOrDefault()). No new imports are required because System.Linq is already imported at the top of the file. The rest of the method and file remain unchanged.

In general, to fix a “missed opportunity to use Where” in a foreach, convert the pattern:

foreach (var x in sequence)
{
    if (!predicate(x))
        continue;

    // use x
}

into something that filters first and then operates, e.g.:

foreach (var x in sequence.Where(predicate))
{
    // use x
}

or, if the body only returns or breaks, use Any/FirstOrDefault with a predicate.

In this specific code, the loop only checks whether any leading trivia is a single-line comment containing "TODO: Convert to EventCallback" and, if found, returns the document early. This is more idiomatically written using Any with a predicate on the trivia sequence, eliminating the explicit loop. We already have using System.Linq;, so we can write:

if (method.GetLeadingTrivia().Any(trivia =>
        trivia.IsKind(SyntaxKind.SingleLineCommentTrivia) &&
        trivia.ToString().Contains("TODO: Convert to EventCallback")))
{
    return document;
}

This preserves the existing behavior: if such a TODO comment exists anywhere in the leading trivia, we return the original document; otherwise we proceed to build and insert the TODO comment. The change is localized to the loop in AddTodoCommentAsync (lines 47–54); no additional imports or helper methods are required.