Solution.Parser 6.0.2

Solution.Parser

Quick start

A code rule is a query over the solution and an assertion that it finds nothing:

using Solution.Parser.Core;     // ShouldBeEmpty
using Solution.Parser.CSharp;   // the C# model and its queries
using Solution.Parser.Sln;      // SolutionFile

var solution = SolutionFile.Find("MySolution.sln");   // searched upwards from the running test

var findings = from type in solution.ProductionTrees.AllTypes()
               from property in type.Properties
               where !property.IsReadOnly
               select $"{property.Location}: {type.FullyQualifiedName}.{property.Name} is mutable";

findings.ShouldBeEmpty("Properties must be immutable");

A failing rule lists every finding on its own line, as path(line,column): message, which test runners and IDEs turn into a link:

Properties must be immutable. 2 findings:
  D:\repo\src\Person.cs(12,5): My.Sample.Person.Name is mutable
  D:\repo\src\Order.cs(8,5): My.Sample.Order.Total is mutable

Packages

One package ships: Solution.Parser. It contains everything, so an existing reference needs no change. The split below is how the source is organised; the assemblies all travel inside that one package and none of them is published on its own.

Solution.Parser.Project deliberately knows no language: ProjectFile.SourceFiles is a plain file list, and the typed views come from the language assembly you use.

project.SourceFiles.GetCSharpFiles()   // Solution.Parser.CSharp
project.SourceFiles.GetXamlFiles()     // Solution.Parser.Xaml

Should the parts ever be published separately, that boundary is what lets a C# only consumer skip XAML and the other way round. Today it is a source boundary, not a packaging one.

Solution formats

Both the classic .sln and the new xml based .slnx format are supported:

SolutionFile.Find("MySolution.sln")    // exactly that file
SolutionFile.Find("MySolution.slnx")   // exactly that file
SolutionFile.Find("MySolution")        // either of both, '.slnx' wins when both exist side by side

SolutionFile.Find("MySolution.sln", startDirectory: new DirectoryInfo(@"D:\repo"))   // search from elsewhere

solution.FileInfo.Extension tells which format was found. Everything behind it is format agnostic. A solution whose path is already known is parsed with SolutionFile.Parse(path).

Solution, projects and code

solution.Projects                       // every project
solution.ProductionProjects             // the ones that are not test projects
solution.UnitTestProjects
solution.Project("My.Sample")           // by name; an unknown name lists the ones there are

solution.AllTrees                       // the C# code of every project, parsed once and cached
solution.ProductionTrees
solution.UnitTestTrees
project.Trees

project.Name                            // "My.Sample"
project.Path                            // D:\repo\src\My.Sample\My.Sample.csproj
project.PackageReferences               // Include and Version

A file is a plain FileInfo: solution.FileInfo, project.FileInfo, project.SourceFiles. What kind of file it is shows in the type parsing it returns, so each of them parses with a static Parse that takes a path or a FileInfo: SolutionFile.Parse, ProjectFile.Parse, CSharpSyntaxTree.Parse, XamlSyntaxTree.Parse, NuspecFile.Parse.

A base class for a rule suite

[TestClass]
public abstract class CodeRuleBase
{
    protected static SolutionFile Solution { get; private set; } = null!;

    [AssemblyInitialize]
    public static void Init(TestContext _) => Solution = SolutionFile.Find("MySolution.sln");
}

[TestClass]
public class Records : CodeRuleBase
{
    [TestMethod]
    public void Record_Properties_Have_To_Be_Immutable()
    {
        var findings = from tree in Solution.ProductionTrees
                       from record in tree.Records
                       from property in record.Properties
                       where !property.IsReadOnly
                       select $"{property.Location}: {record.FullyQualifiedName}.{property.Name} should be {{ get; init; }}";

        findings.ShouldBeEmpty("Record properties must be immutable");
    }
}

What the model gives you

Every declaration carries a Location, so a finding points at the source instead of only naming the type. Location.ToString() renders path(line,column), which test runners and IDEs turn into a link:

var findings = from type in solution.ProductionTrees.AllTypes()
               from property in type.Properties
               where !property.IsReadOnly
               select $"{property.Location}: {type.FullyQualifiedName}.{property.Name} is mutable";

// D:\repo\src\Person.cs(12,5): My.Sample.Person.Name is mutable

Beyond that, a declaration reports its Accessibility (including the default that applies when no modifier is written), its Documentation (the XML comment), its Modifiers (now complete, including sealed, virtual, override, new, async and readonly), its TypeParameters with their constraints, and its Attributes split into positional and named arguments. HasAttribute("Obsolete") matches [Obsolete], [ObsoleteAttribute] and [System.ObsoleteAttribute] alike.

Types also report Indexers, Operators, Delegates and Finalizers, and TypeKind tells a record from a record struct. tree.Diagnostics surfaces what Roslyn reported while parsing, so a rule can assert that no file has a syntax error rather than silently trusting an incomplete model.

Nesting

A member belongs to the type that declares it. type.Methods holds the methods of that type, and the methods of a nested type belong to the nested type:

tree.Types              // the types declared at file level
type.NestedTypes        // the types declared directly inside this type
type.Methods            // the methods declared directly in this type

To walk everything, ask for it:

tree.AllTypes()               // every type of the file, nested ones included
tree.AllMethods()             // every method of the file
type.DescendantTypes()        // every type declared inside this one, at any depth
type.AllMethods()             // this type and every type nested in it
solution.AllTrees.AllTypes()  // the same across a whole solution

Predicates that read the way a rule means: IsPublic(), IsStatic(), IsSealed(), IsAbstract(), IsPartial(), IsOverride(), IsVirtual(), HasAttribute(name), Implements(name), InheritsFrom(name).

Every member with a body reports the method calls in it, lambdas included, a local function on its own:

method.Invocations                         // Client.AssertPostAsync("..", "..", true)
tree.AllInvocations().Named("AssertPostAsync")   // Named works on any declaration list
call.Target                                // "Client"
call.Arguments                             // as written, in source order
call.NamedArgument("writeResponse")        // only what is written as writeResponse: true
call.ArgumentFor("writeResponse")          // by position, by name or by default; needs symbols, see below

Symbols

The syntax alone cannot tell that true in Client.AssertPostAsync("..", "..", true) is the parameter writeResponse, least of all when the method comes from a NuGet package. The compiler can. The parse mode of the solution decides which of the two you get, over the same records:

var solution = SolutionFile.Find("MySolution.sln", ParseMode.SyntaxOnly);   // syntax only, parsed once and cached
var solution = SolutionFile.Find("MySolution.sln", ParseMode.WithSymbols);  // plus a Roslyn compilation per project, built on first use

var findings = from call in solution.UnitTestTrees.AllInvocations().Named("AssertPostAsync")
               where call.Passes("writeResponse", true)
               select $"{call.Location}: writeResponse is true";

The code hangs on the solution and its projects: solution.AllTrees, solution.ProductionTrees, solution.UnitTestTrees, project.Trees, solution.CompilationDiagnostics() and project.CompilationDiagnostics(). A solution parsed without a mode gets the syntax on first use.

What a resolved call tells, in the vocabulary of the syntax model:

call.Resolution            // Resolved | Ambiguous | Unresolved
call.Method                // a Method record; for code of the solution the very record the tree holds
call.Method.Origin         // Source | Package("AspNetCore.Simple.MsTest.Sdk", "9.5.15") | Framework
call.BoundArguments        // every parameter with what is passed for it, in parameter order
call.ArgumentFor("writeResponse").Expression    // "true", by position or by name alike
call.ArgumentFor("writeResponse").IsExplicit    // false when left out and the default applies
call.ArgumentFor("writeResponse").Is(true)      // literal, const or default value alike
call.Passes("writeResponse", true)              // the same in one go, false for an unresolved call
call.Candidates            // the competing overloads of an ambiguous call
call.Roslyn                // node, semantic model, symbol and operation, for anything not covered

The compilation is built from what restore and build left on disk: package assemblies from obj/project.assets.json, the framework reference packs, project references as compilations, the generated global usings and XAML output from obj, and the source generators of frameworks and packages. The solution therefore has to be restored, which it is whenever its tests run. project.CompilationDiagnostics() shows what the compiler could not resolve.

With ParseMode.SyntaxOnly a symbol access throws instead of guessing, so the cost of a rule stays visible: nothing is compiled unless a rule asks for symbols. CodeBase.FromSource(code).WithSymbols() gives the same API for code in memory, which is handy for trying a rule out; CodeBase.FromSources(("A.cs", a), ("B.cs", b)) takes several files.

XAML

.xaml files parse into the same shape of model, so a rule can reach across markup and code behind:

var tree = XamlSyntaxTree.Parse(@"D:\repo\src\MainWindow.xaml");

tree.FullyQualifiedName          // "My.Sample.MainWindow", the x:Class
tree.Root                       // a Window, UserControl, Page, Application,
                                // ResourceDictionaryRoot or ControlRoot
tree.Diagnostics                // what could not be read, instead of a lost file

For markup that is not on disk, for example in a test:

var tree = xamlContent.ParseXaml(@"D:\repo\src\MainWindow.xaml");

Children holds what an element declares itself, and a property element such as <Grid.RowDefinitions> is a property of the Grid rather than a child of it, which is what XAML means by it:

element.Children                // the elements written directly inside this one
element.Properties              // attributes, attached properties and property elements
element.Resources               // what <X.Resources> declares
element["Grid.Row"]             // an attached property, by the name it is written with
element.Content                 // the text of <Button>Click me</Button>
element.Parent                  // the element this one is written in
element.Location                // path(line,column), clickable in a test runner

To walk everything, ask for it, the same way as on the C# side:

tree.AllElements()              // every element of the file
tree.AllStyles()                // every Style, however deep in the resource dictionaries
tree.AllTemplates()             // DataTemplate, ControlTemplate, ItemsPanelTemplate, …
tree.AllBindings()              // every Binding, nested ones included
tree.AllMarkupExtensions()      // every {…}, nested ones included
tree.FindByName("Save")         // by x:Name
tree.FindByKey("OkButton")      // by x:Key
tree.OfTypeName("Button")       // every element written as <Button>
element.Ancestors()             // up the tree, nearest first

Values keep the shape they were written in, so a rule reads the part it cares about rather than the raw string:

var binding = textBlock["Text"]?.PropertyValue as Binding;

binding.Path?.ValueText                          // "Total"
(binding.Converter as StaticResource)?.ResourceKey   // "MoneyConverter"
binding.RelativeSource?.AncestorType             // "Window"
binding.StringFormat?.ValueText                  // "{0:#,##0.00} EUR"

Binding, MultiBinding, StaticResource, DynamicResource, TemplateBinding, RelativeSource, XTypeMarkupExtension, XStaticMarkupExtension and NullExtension are all MarkupExtension, and an extension the parser has no model for keeps its name and arguments instead of being reduced to text. A value is markup only when it starts with an unescaped { followed by a name, so a pack URI, a caption with a colon and a {}{0:N2} escape are all plain text.

Style, Setter, Trigger, Template, ResourceDictionaryElement and Control are siblings below ElementBase with an ElementKind; Window, UserControl, Page, Application, ResourceDictionaryRoot and ControlRoot are siblings below Root with a RootKind.

Sample application

src/SampleApp.Wpf is a small but real WPF application: a window, a user control, a theme dictionary, view models and bindings. It is a fixture rather than a demo. Because it is a real UseWPF project, markup that WPF would reject cannot get in, so the parser tests always run against XAML that actually compiles. Nothing in the library references it.

src/SampleApp.Wpf.Test is what a consumer of the packages looks like: it references Solution.Parser.Xaml, .CSharp and .Sln, finds the application through the solution, and runs code rules over it. Two of them are worth reading as examples:

• BindingRule - every {Binding Path=X} has to name a property that exists on the view model the view declares through d:DataContext. A typo there compiles, renders nothing and is caught by no compiler.
• ResourceRule - every {StaticResource Key} used anywhere has to be declared somewhere, across files.

Each rule is also run against a deliberately broken view parsed from memory, because a rule that never fails proves nothing.

Migrating

Upgrading from an older major? See MIGRATION.md — it covers the mechanical renames and, more importantly, the changes that still compile but report something different. It is written so you can hand it to an AI assistant along with your rule suite.

The short version for 6.0, all of it caught by the compiler:

And for 5.0:

Classes, Records, Interfaces, Structs and Enums still exist on the tree, and NestedClasses, NestedStructs, NestedInterfaces and NestedEnums still exist on a type; they are now filtered views over Types and NestedTypes. Method.MethodValue and Method.MethodBody are kept as the previous names for SyntaxTree and Body.

Packaging and projects

XAML

License

Copyright 2022-2026 (c) Rene Peuser.

Licensed under the Apache License 2.0.