About
Purview Development
Making development easier. Purview is where I build open-source tools focused on improving the .NET developer experience — removing repetitive work, catching problems earlier, and automating the things that shouldn't need continual attention.
Why Purview?
I chose the name Purview because I liked what it suggested about developer tooling.
A purview is an area of influence or responsibility. That's a good description of what these projects represent: the parts of the development experience where I think better tooling can make a meaningful difference.
Purview isn't intended to be one enormous framework that dictates how an application should be built. It's a collection of focused tools for the areas within that purview — generation, validation, telemetry, event sourcing, .NET Aspire, build infrastructure, and the other repetitive pieces around building and maintaining software.
The common goal is simple: make development easier.
From repetition to tooling
Most Purview projects are evolutions of something I originally built to solve a real problem.
I'd build something for one project, encounter the same problem somewhere else, improve the solution, and eventually realise I was writing essentially the same thing again.
At that point, it probably belongs in a library.
flowchart LR
solve["Solve the
problem"] --> repeat["Encounter it
again"]
repeat --> generalise["Generalise the
solution"]
generalise --> automate["Automate it"] That thinking has become one of the principles behind Purview:
Automation, not operation.
If something is predictable and repeatable, I'd rather automate it once than make developers remember to do it forever.
The projects
Today, Purview spans 13 active projects covering areas such as event sourcing, strongly typed telemetry, schema validation, incremental source generation, .NET Aspire integrations, and shared build infrastructure.
Source generation features heavily because it fits the philosophy particularly well. If the compiler already has enough information to generate something correctly, I'd rather generate it than maintain repetitive runtime wiring or boilerplate by hand.
It also moves more mistakes into the development cycle, where they are cheaper and easier to understand.
How the projects fit together
Each project is intended to be useful independently. There isn't a requirement to adopt a "Purview stack".
Where projects naturally complement each other, they share foundations and integrate
with one another.
Purview.SourceGeneratorFramework provides common infrastructure for source-generator-based
projects, while
Purview.Build and Purview.BuildSdk provide common build conventions
and automation. Higher-level libraries can use other Purview components where doing so genuinely
adds value.
The aim is to build small, composable tools with consistent conventions , rather than a tightly coupled framework.
Use one because it solves a problem you have. Combine them where that makes sense.
Building in the open
Purview is also where I can take ideas that have grown out of day-to-day software development and explore them further.
Some projects are mature; others are experiments that are still evolving. Many are pre-1.0 while their APIs and approaches settle.
The projects share common tooling for building, testing, validation, packaging, and publishing. That infrastructure is itself part of Purview: if maintaining multiple projects creates repetitive work, that's another opportunity for automation.
The same principle applies to maintaining the tools as it does to using them: automation, not operation.
Open source
Purview's public projects are open source and released under the MIT licence.
Issues, ideas, and contributions are welcome. The projects are built around problems I've encountered, but the aim is for the resulting tools to be useful well beyond the projects that originally inspired them.