The history of .NET blogging is less a straight product timeline than a sequence of architectural experiments. Small weblog tools had to store entries, assemble pages, publish feeds, accept remote edits and survive framework changes. The projects that followed made different choices, but they kept returning to the same compact set of publishing problems.
BlogX and the beginning of a lineage
The early documentation for dasBlog described it as an evolution of the BlogX weblog engine initially written by Chris Anderson and contributors. That wording matters: the project presented itself as inherited work, not as an isolated invention. Its home was the .NET Framework era, when ASP.NET applications commonly combined server-side rendering, XML configuration and Windows hosting.
The same documentation described dasBlog as free and BSD-licensed and credited newtelligence AG. It also recorded specific contributions: themes made available by Bryan Bell for porting, initial POP3 work by Pawel Lesnikowski, an HtmlFormatter from Nikhil Kothari and an XML-RPC library by Charles Cook. These are narrow historical credits from the project-era record; they are not claims of involvement with this reference.
What classic engines had to solve
A useful weblog was more than an entry editor. It needed a navigation model, configuration boundaries, templates, source organization, answers to recurring questions, a place to record known issues and a roadmap. The classic documentation taxonomy exposed all of those concerns. It also included category feeds and mail-to-weblog functionality, evidence of a period when publishing could arrive through several channels.
Early engines often exposed their implementation in their URLs: ASP.NET page names, query-string categories and service endpoints were visible to readers and feed clients. That was ordinary for the time, but it made later modernization a routing problem as much as a code problem. The lesson is developed further in the permalink reference.
A broader .NET publishing ecosystem
Other projects—including Subtext, BlogEngine.NET, Orchard and Miniblog.Core—occupied different points between focused blog engine and broader content system. Their names belong in the ecosystem map because they show how .NET publishing branched: some systems emphasized a classic blog workflow, some expanded toward general content management, and some reduced the stack around a deliberately small application.
The important comparison is architectural, not competitive. A file-oriented engine and a relationally backed engine can both publish durable HTML and feeds. A larger content system and a narrowly scoped blog can both render with server templates. Each approach puts complexity in a different place, as the storage guide and template guide explain.
From Web Forms to modern .NET
The lineage continues in the active DasBlog Core repository. Its own description calls it the original DasBlog reimagined with ASP.NET Core, and its feature list includes server-rendered themes, RSS and Atom feeds, the MetaWeblog API and ActivityPub. The maintainer's current project category records work on modernization and WebFinger.
That continuity is why this site is framed independently. The name belongs to a living open-source project with its own repository and communication channels. Here, dasBlog is a factual case study inside the history of .NET weblog engines—not the name or identity of the site.
Continuity is the real timeline
Framework generations provide convenient dates, but a blog's public life is measured in working links and readable entries. The most successful modernization is the one readers barely notice: old addresses continue to resolve, feeds keep stable identifiers, exported content retains dates and authorship, and a new rendering layer does not rewrite the publication's past. That makes history operational. It becomes a set of constraints for the next migration rather than a shelf of obsolete software.