DFe.NET: a C# library for Brazilian electronic fiscal documents

What the library covers, and what it deliberately hides

DFe.NET is a C# library for issuing and printing NFe, NFCe, MDF-e and CT-e, and for consuming the web services needed to maintain them, following the layouts published by the tax authorities. The design premise is stated plainly: the project contains classes built by hand that extract the complexity of the XSD schemas, so you can fill in native .NET objects and generate the XML in the structure your document requires, and the same in reverse, reading a document XML back into native .NET objects. On top of that, the library includes the methods for consuming the web services, which means consulting, transmitting, cancelling and inutilising. The practical claim is that with the library you fill a native .NET object and transmit your document in a fully transparent way, without worrying about the serialisation or the web service call. That last part is the reason a project adopts a library like this, because the XML and the SOAP conversation with SEFAZ are where the tedium lives.

The printing path is where the money and the platform limits are

Printing the documents is a separate concern with its own matrix, and the table is worth reading carefully because it decides what you can deploy. The free path uses OpenFastReport, and it covers NFe, NFCe, CTe and MDF-e across .NET Framework 4.6.2 through 4.8, .NET Standard 2.0, and .NET 6.0 on both Windows and Linux, with .NET 7.0 and later on Windows only. The paid FastReport path covers the same document set and a similar framework range, with .NET 6.0 without a platform note and .NET 7.0 plus on Windows. The third option, FastReport.Skia, is for NFe only and runs on .NET 7.0 and later across Windows, Linux and mobile. The practical consequence is that if you are deploying a Linux service on .NET 8, the Skia path is out because it does not cover NFe with NFe only... it covers NFe but is paid and .NET 7+. The free OpenFastReport path is the one that works on .NET 6 on Linux.

Seven NuGet packages, split by document type and by printer

The library is distributed as a set of NuGet packages rather than one, and the split is by document type and by printing backend. The core packages are Zeus.NFe.NFCe for the NF and NFC documents, Zeus.MDFe for the MDF-e manifest and Zeus.CTe for the CT-e transport document. The printing packages are separate: Zeus.Net.NFe.Danfe.Html for HTML output, Zeus.Net.NFe.Danfe.PdfClown for PDF through the PdfClown library, and Zeus.Net.NFe.Danfe.QuestPdf for the QuestPDF route. The NuGet package is described as the best way to get the latest version of Zeus into your project, and there is a build status badge tied to a workflow on the master branch. The version numbers are date-based, so a release tag looks like a timestamp, and the three most recent ones in the repository are 2026.09.24.1416, 2026.09.23.1958 and 2026.09.23.1949, with the last push on 2026-09-24.

Three lines to print a DANFE from an existing XML

The example the README gives is short and shows the shape of the printing API. You load the process from an XML file, build the DANFE with a configuration, an emission number and a key, and then call the method that opens it:

var proc = new nfeProc().CarregarDeArquivoXml(Caminho_do_arquivo_XML);
var danfe = new DanfeFrNfce(proc, new ConfiguracaoDanfeNfce(NfceDetalheVendaNormal.UmaLinha, NfceDetalheVendaContigencia.UmaLinha, null/*Logomarca em byte[]*/), "00001", "XXXXXXXXXXXXXXXXXXXXXXXXXX");
danfe.Visualizar();
//danfe.Imprimir();
//danfe.ExibirDesign();

The commented lines are the alternative modes, with Imprimir for printing and ExibirDesign for the designer view, and the Visualizar call opening the document in the default viewer. The configuration object takes the detail layout for a normal sale and one for a contingency sale, plus a null logo, and the constructor takes the process, the configuration, an emission number and the access key. The comments in the code are in Portuguese, which is a reminder that this is a library aimed at Brazilian developers, and the whole API surface is in that language.

The tax reform is only partly implemented, and the project says so

The most consequential piece of information in the README is about the Reforma Tributária do Consumo, the Brazilian consumption tax reform, which directly affects electronic fiscal documents. The library is in the process of adapting to it. From pull request 1649 and the version 2025.10.03.1855 of the NuGet package, the library partially meets the requirements the reform establishes for NFe and NFCe. Support for CTe and MDF-e will be handled in the future, tracked in issue 1623 for CTe and issue 1624 for MDF-e, and the general tracking of the reform support is done through issue 1615. The word partially is doing real work there, and the project invites community contributions to speed up the full implementation. If you are deploying into a tax regime where the reform applies to your documents, that set of issues is where the current state of play is, and the honest reading is that NFe and NFCe are partly covered while the other two document types are not covered yet.

Framework support follows the Microsoft lifecycle, and the old ones are gone

The supported versions table is broad for the library itself: .NET Framework 4.6.2, 4.7, 4.7.1, 4.7.2 and 4.8, plus .NET Standard 2.0 and .NET 6.0, 7.0 and 8.0, across the NFe, NFCe, CTe and MDF-e scopes. The library was written in C# using Visual Studio Community 2022 with the net462, netstandard2.0 and net6.0 SDKs installed. What is not supported is stated as firmly as what is: there is no support for .NET Framework 4.5.2 or 4.5 or anything older, and the library will follow the Microsoft version lifecycle, dropping compatibility with specific old .NET versions when Microsoft drops its own support for them. That is a sensible policy for a library with this many consumers, but it does mean a consumer on an old .NET Framework has a deadline rather than a path, and it means the library is not a candidate for a long-lived on-premises deployment on a frozen platform.

A solution with a demo application for every document type

The repository layout shows the scale of the effort, which is a lot of small projects rather than one large one. For the NF side there are the classes, the services, the utilities and the WSDL definitions, plus separate Danfe application projects for each printing backend, HTML, Fast, OpenFast, PdfClown, QuestPdf and the Fast.Skia variant, and test projects for the classes, the utilities and the QuestPdf output. The CT-e has the same shape with its own AppTeste, Classes, Dacte, Fast, OpenFast, Servicos, Utils and Wsdl directories, and MDF-e has the equivalents including a Damdfe print application. There is a shared directory for the parts common to NFe and MDF-e printing, a base library, an integration project, a native DANFE project, test data, a version directory for the assemblies, and a NuGet directory. The solution file itself is named Zeus NFe.sln, with a DotSettings file beside it, and the contribution guidelines are in a CONTRIBUTING file at the root.

The documentation advice starts with the domain, not the API

The section on how to use the tool is unusually honest about what a newcomer needs. Before anything else you are told to read the manuals and understand the projects you intend to use, what an electronic fiscal document is, what a digital certificate is, how a web service works, and what is mandatory in the document you plan to issue. Only after that do you study the library, and the note about C# is that basic knowledge of the language helps a lot even if you only use the assemblies from VB.Net or another compatible language. The library also ships demo projects of the DEMO kind to make the learning easier, with the CT-e one described as a WPF project demonstrating CTe usage. The LGPL licence covers it, and the project asks for community contributions to accelerate the tax reform work. The upshot for an adopter is that this library assumes you already work in the Brazilian fiscal domain, and it removes the XSD and web service plumbing rather than teaching you the domain.

Editorial conclusion

DFe.NET suits a Brazilian software house that has to issue electronic fiscal documents and would rather not hand-roll XML against the XSD schemas or the SEFAZ web services. It does not suit a project that needs full coverage of the consumption tax reform, because the library states it meets the new requirements only partially for NFe and NFCe, with CTe and MDF-e still tracked as future work. Before you adopt it, read the tax reform tracking issue, check that your target framework is in the supported list, and decide which printing backend you will pay for, since the paid FastReport and FastReport.Skia paths and the free OpenFastReport path do not have the same platform coverage.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. README
4. Releases
5. ZeusAutomacao/DFe.NET on GitHub