I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 1 of an 8-part series documenting both the development process and the engineering decisions behind bringing the project back to life.
This is the Dev Log: the practical work, cleanup, implementation steps, and day-to-day progress behind this part of the project.
Day one of building Munchausen v1.0 started with deleting the existing implementation and deliberately breaking its replacement.
Munchausen is a mock-data generator for .NET that infers realistic values from
your types. Before writing v1.0, I spent time designing the API and architecture,
then captured the result in a single design document. At the end, I divided the
implementation into stages: M0 for the repository scaffold, M1 for determinism,
and later milestones for metadata, inference, compilation, and runtime behavior.
The plan gives me a route through the project. Implementation is where I find out
whether those ideas actually hold together, and M0 was the first test.
First move: delete the old thing
The repo already had a prototype from years ago, an early Lie /
ModelGenerator / ValuesGenerator trio and a .travis.yml pinned to a
dotnet-1.0 preview. My first instinct was to keep it nearby. Some of it might be
useful, and deleting code always feels more dramatic than leaving it alone.
Reading it changed my mind. The prototype reflected an earlier idea of the
library, and keeping its types invited me to preserve decisions I had already
reconsidered. Removing it gave me a clean place to test the new design without
negotiating with the old one. The history is still there if I need it.
The satisfying part: breaking the build on purpose
One idea from the design was that the public API should be a deliberate contract,
not whatever happens to escape from the assembly. I added PublicApiAnalyzers,
which tracks every public symbol in two text files. At M0 those files contain no
API entries. The public surface starts at zero and grows only when I consciously
add to it.
Configuring the analyzer was easy. Trusting it was different. I could see that
the package was installed and the build was green, but that did not prove it
would catch the mistake I cared about. So I added a mistake on purpose.
I wrote a throwaway Canary class with one public property and no XML comments,
then committed it. The build went red with exactly the errors I hoped to see:
RS0016 (this public symbol isn't declared in the API files) for the type, its
getter, and even its implicit constructor, plus CS1591 for the missing comments.
One little class tripped both wires at once. Then I removed the canary commit,
rebuilt, and watched the build go green again.
I expected a quick configuration check. Instead, I learned that a green build
only shows the current code passes. A deliberate failure proves the build can
protect a boundary I care about. When later milestones introduce public API, I
know accidental additions cannot quietly slip through.
Giving future problems somewhere to live
The rest of M0 turned design choices into places where future work can happen:
net8.0, nullable reference types, warnings treated as errors, required XML
comments, and a Directory.Build.props that keeps those choices consistent. I
added CI and created six projects for the package, unit tests, acceptance tests,
determinism tests, benchmarks, and shared test models.
The shared models include Car, Owner, Customer/Order/Item, a
positional record, an init-only type, and Employee whose Manager is another
Employee. That last model is a question waiting for a later milestone: what
happens when generation encounters a cycle? I do not need the answer yet, but
putting the model in place now means I cannot conveniently forget the problem
when recursion and cycle detection arrive.
Where this leaves things
Zero features. Zero public API. A green build, a CI pipeline, and a guardrail
I've personally watched fail and recover. More importantly, I finished M0 with a
better understanding of the design than I had when it existed only on paper.
Starting from zero is not empty progress when the boundaries themselves are part
of what you are building.
What's next
M1 takes on the determinism core. Munchausen promises that the same seed produces
the same data forever, across machines, OSes, and .NET versions. .NET doesn't
guarantee that System.Random will preserve its algorithm across versions, so
I'm building an owned PRNG (xoshiro256** seeded by SplitMix64) and validating
it against published reference vectors. If my numbers don't match the ones the
algorithm's authors published, my code is wrong, full stop. That's the kind of
unambiguous test I love. More soon.
