# PDFsharp 7 previews a .NET 8 to 10 rebuild, and the AGPL licence is the part to read first > The PDFsharp and MigraDoc libraries for generating PDF documents on .NET, now in a 7.0.0 Preview 2 built for C# 12 and .NET 8, .NET 9 and .NET 10. The build has a wrinkle, since assets are no longer in the repository and must be downloaded before the solution compiles. **empira/PDFsharp** — PDFsharp and MigraDoc Foundation for .NET 6 and .NET Framework - Repository: https://github.com/empira/PDFsharp - Website: https://docs.pdfsharp.net/ - Stars: 1,010 · Forks: 277 - Language: C# - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/empira-pdfsharp ## The licence is the first thing to settle PDFsharp and MigraDoc are published under AGPL and a commercial licence, and the README states it in the copyright block for both projects, copyright empira Software GmbH, Troisdorf in the Cologne area of Germany. That combination is the defining constraint on adoption, and it differs from the permissive licences most .NET PDF libraries carry. A dual AGPL and commercial grant means the commercial route is a paid licence negotiated with the vendor, and the AGPL route is free but carries the copyleft obligations that the AGPL extends to network use. For a PDF generation library that a web application calls on every request, the AGPL question is a serious one rather than a formality, and it needs to be settled before the library enters a build, not after. The README also names a third party detail with the same care. The Core build of PDFsharp uses BigGustave to read PNG images, and that library was released into the public domain and does not restrict the AGPL or commercial licence used by PDFsharp. A vendor who has checked that their dependency does not conflict with their own licence terms is doing something worth noticing, because the chain of licences in a PDF library is where the copyleft questions hide. The GitHub metadata reports a licence that GitHub could not classify, which is the expected result for a dual licence with a custom commercial component, and the authoritative text is in the LICENSE file and at the licence page on the documentation site. This is not legal advice, but the practical advice is to read those before writing a line of integration code. ## A preview release for C# 12 and .NET 8 through 10 The version being announced is 7.0.0 Preview 2, published on 2026-10-13, and the README describes it as a preview of the PDFsharp project, the main project of PDFsharp and MigraDoc 7, with updates for C# 12 and .NET 8, .NET 9 and .NET 10. The dual project structure is the thing to understand first. PDFsharp is the lower level library that draws on a PDF page canvas, with the familiar graphics model of lines, rectangles, text and images. MigraDoc is the higher level document layer that sits on top, where you describe a document as paragraphs, tables and sections and it lays out the page for you. They share a history: the original PDFsharp developers are Stefan Lange, Niklas Schneider and David Stephensen, and the original MigraDoc developers are Klaus Potzesny, Niklas Schneider and Stefan Lange, so the same people wrote both. The current developer list is Stefan Lange, Thomas Hövel, Martin Ossendorf and Andreas Seifert, and the README credits a long line of community developers who filed issues and fixed bugs, which is the usual shape of a project that has been maintained across a company and its community. The target framework spread is the practical reason to care about this release. A library that supports .NET 8, .NET 9 and .NET 10 with C# 12 lets you keep one dependency across several service generations instead of pinning an old version of a PDF library that only runs on the framework you deployed two years ago. ## The build needs assets that are no longer in the repository This is the part that will trip up a first build, and the README puts it under a heading that reads as an instruction: download assets first. Assets such as bitmaps, fonts and PDF files are no longer part of the repository. You must download them before compiling the solution for the first time, using a script in the `dev` folder to create the `assets` folder that some unit tests need and that some projects reference. ```ps .\dev\download-assets.ps1 ``` The script is a PowerShell script, and the README notes that PowerShell 7 is required to execute the PowerShell scripts that come with PDFsharp. That is a real prerequisite on a Linux or macOS build agent, and it is the kind of detail that turns a five minute build into a half hour one if you hit it cold. The reasoning behind the change is sensible. Keeping large binary assets in the repository inflates every clone, and test fixtures and sample documents are exactly the kind of content that does not need version control. The cost is that a build is no longer self contained, and a CI pipeline that expects a plain clone and build will fail until the download step is added. After the assets, the build itself is a single command. ```ps dotnet build ``` The README states that this should build the solution without any warnings or errors, and that you need the latest .NET SDK installed. ## Central package management and the repository layout The solution uses central package management, which means every referenced package version lives in one file, `Directory.Packages.props` in the `src` folder, and adding a new package means adding its version there rather than in an individual project file. That is a deliberate choice for a repository with a large number of projects, and it has a visible side effect for anyone who has worked with a differently structured solution: the version a project references is not visible in the project file, and a merge conflict in `Directory.Packages.props` is a conflict across every project that depends on the package in question. The top level layout is small and predictable. There is a `src/` directory with the projects, a `dev/` directory holding the development scripts including the asset downloader, a `docs/` directory, a `PdfSharp.sln` solution file with its DotSettings file for Rider, and an `azure-pipelines.yml` at the root, which is where the build and release pipeline is defined. There is also a `.globalconfig` and an `.editorconfig` at the root, which together mean the project enforces analyzer and formatting rules across the whole codebase. That is worth noting for a library with this many contributors: the style and the analyzer configuration are checked in rather than left to individual preferences. The build configuration also handles versioning automatically. The README records that a git repository with at least one commit used to be required, because `GitVersion.MsBuild` errored without one, and that a tag such as `git tag v6.2.0` could define a specific version number, with 0.1.0 used when no tag was present. That is now handled automatically by BuildConfig, so a fresh clone no longer needs a tag to build. ## What the maintenance status actually tells you The last push to the repository was on 2026-10-19, and the repository is not archived. There are no GitHub releases, so the version history lives in the repository tags and in the announcement text rather than in a release page. For a library that teams tend to pin for years, a version 7 preview is a signal to wait unless you need the newer framework targets. Previews are published so that people can test the new target frameworks against their own code, and so that the maintainers collect breakage reports before the final release. The gap between a preview and a stable release is where the API changes still land. The dual licence shape is a bigger factor for adoption than the preview status. A commercial licence for a PDF library is normal and common, and the AGPL route exists for people who want free use. What matters is that the choice is not anonymous, and that a team with an existing open source policy has to read the AGPL and decide rather than assume the library is permissively licensed because it lives on NuGet. The documentation site is the authoritative source for all of it, and the README says so directly with a Read this FIRST heading pointing at docs.pdfsharp.net. For a library whose licence has a commercial component, that site is where the terms live, and the README is a signpost rather than the contract. ## Conclusion Adopt PDFsharp if you generate PDF documents from .NET and you need either a commercial licence or you are comfortable with the AGPL and its obligations, and you want a library that tracks current .NET versions. Do not adopt it as a drop-in for an AGPL free stack without reading the licence, because the project is published under AGPL together with a commercial licence, and the AGPL reaches networked use. Verify first that the preview status suits you, since version 7.0.0 Preview 2 is not a stable release, that you have downloaded the assets before the first build, and that your build environment has PowerShell 7 available for the scripts the project ships. ## FAQ ### What licence is PDFsharp published under? PDFsharp and MigraDoc are published under AGPL and a commercial licence, copyright empira Software GmbH. The README notes that BigGustave, used by the Core build to read PNG images, is public domain and does not restrict either licence. ### Which .NET versions does PDFsharp 7 support? Version 7.0.0 Preview 2, published on 2026-10-13, is a preview with updates for C# 12 and .NET 8, .NET 9 and .NET 10. The project has no GitHub releases, so the version history is in the repository tags. ### Why does building PDFsharp fail on a fresh clone? Assets such as bitmaps, fonts and PDF files are no longer part of the repository. Run the download-assets.ps1 script in the dev folder to create the assets folder before the first build, and note that PowerShell 7 is required to run the scripts that ship with the project. ### What is the difference between PDFsharp and MigraDoc? PDFsharp is the main project of PDFsharp and MigraDoc 7 and provides the lower level PDF drawing layer. MigraDoc is the higher level document layer for describing documents with paragraphs, tables and sections. The README lists the original developers of each. ### How are package versions managed in the PDFsharp solution? The solution uses central package management, with every referenced package version stored in Directory.Packages.props in the src folder. New packages need their version added there. ## Sources - [empira/PDFsharp on GitHub](https://github.com/empira/PDFsharp) - [Issues](https://github.com/empira/PDFsharp/issues) - [Project website](https://docs.pdfsharp.net/) - [README](https://github.com/empira/PDFsharp/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/empira-pdfsharp