iText 9 Errors

Kmcnet 1,421 Reputation points
2026-06-11T19:56:26.0466667+00:00

Hello everyone and thanks for the help in advance. I am working on a .Net 10 MVC project that utilize iText 9 to generate Pdf files. The code looks like this:

        string webRootPath = _webHostEnvironment.WebRootPath;

        string src = webRootPath + @"\forms\test.pdf";

        byte[] pdfBytes;

        PdfWriter mywri = new PdfWriter();

        using (var stream = new MemoryStream()) 

        using (var wri = new PdfWriter(stream))

        using (var pdf = new PdfDocument(new PdfReader(src), wri))

        using (var doc = new Document(pdf))

        {

            doc.ShowTextAligned(new Paragraph("Hello World"),

                            375, 775, 1, TextAlignment.LEFT, VerticalAlignment.TOP, 0);

            doc.Close();

            doc.Flush();

            pdfBytes = stream.ToArray();

        }        

        return new FileContentResult(pdfBytes, "application/pdf");
```When I run this code in my existing project, I receive two errors, PdfWrite does not contain a constructor that takes 1 arguments and Cannot convert PdfWriter to iTextKernel.Pdf.DocumentProperties.  However, when I take this exact code and place it in a new MVC project, it works fine.  I have verified the same iText 9.6.0 nuget packages are installed and the appropriate using statements are identical on the controller.  I have not idea what the problem is.  Any help will be appreciated.
Developer technologies | .NET | Other
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-11T19:56:40.7533333+00:00

    The behavior difference between the two projects indicates that the existing project is resolving a different PdfWriter type or a different iText version/assembly than the new test MVC project, even though the same NuGet package version appears installed.

    The two specific errors:

    • “PdfWriter does not contain a constructor that takes 1 arguments”
    • “Cannot convert PdfWriter to iTextKernel.Pdf.DocumentProperties”

    mean that, at compile time, the PdfWriter symbol in the existing project does not match the iText 9 API that your code expects. This typically happens due to:

    1. Conflicting references (another assembly defining PdfWriter, or an older iText version) being picked up first.
    2. Mismatched target frameworks or binding redirects causing a different iText assembly to load/compile against.

    To fix this in the existing project:

    1. Check the resolved type for PdfWriter
      In the problematic project, use the IDE to inspect the symbol:
      • Hover over PdfWriter and confirm the fully qualified name (namespace and assembly). It must match the iText 9 type you expect.
      • If it shows a different namespace/assembly than in the new MVC project, that’s the conflict.
    2. Remove conflicting references
      • In the existing project, open the project file and remove any old or duplicate iText references (e.g., older iText 7/8, or other libraries that define PdfWriter).
      • Clean and rebuild after removing them.
    3. Force the correct namespace
      • Temporarily replace PdfWriter with its fully qualified name from iText 9 (for example, iText.Kernel.Pdf.PdfWriter if that is the correct namespace in your package).
      • If the error changes or disappears, it confirms a name collision.
    4. Compare project files
      • Compare the .csproj of the working new MVC project with the existing project:
        • Ensure the same TargetFramework and the same iText package reference (same version, same Include).
        • Remove any extra package references related to older PDF libraries.
    5. Clean build artifacts
      • Delete bin and obj folders of the existing project.
      • Rebuild the solution to ensure no stale assemblies are being used.

    Once the existing project resolves the same PdfWriter type as the new MVC project, the constructor call new PdfWriter(stream) and the PdfDocument constructor overload will compile and run as expected.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator
    2026-06-12T04:02:52.22+00:00

    Hi @Kmcnet ,

    Since the same code works in a fresh project, the issue is almost certainly that PdfWriter is resolving to a different type than the iText 9 one in this project most likely a second PDF library (such as the older iTextSharp) still being referenced, whose PdfWriter wins name resolution and produces both errors.

    The fastest way to confirm is to fully qualify the iText 9 types so there's no ambiguity. If this compiles in the failing project, the cause was a type conflict:

    string webRootPath = _webHostEnvironment.WebRootPath;
string src = webRootPath + @"\forms\test.pdf";
byte[] pdfBytes;

using (var stream = new MemoryStream())
using (var wri = new iText.Kernel.Pdf.PdfWriter(stream))
using (var pdf = new iText.Kernel.Pdf.PdfDocument(new iText.Kernel.Pdf.PdfReader(src), wri))
using (var doc = new iText.Layout.Document(pdf))
{
    doc.ShowTextAligned(
        new iText.Layout.Element.Paragraph("Hello World"),
        375, 775, 1,
        iText.Layout.Properties.TextAlignment.LEFT,
        iText.Layout.Properties.VerticalAlignment.TOP, 0);
    doc.Close();
    pdfBytes = stream.ToArray();
}

return new FileContentResult(pdfBytes, "application/pdf");

    I dropped the unused PdfWriter mywri = new PdfWriter(); line (iText 9's PdfWriter has no parameterless constructor) and the doc.Flush() after Close(), since closing already finalizes the document. The structure matches iText's own "Hello PDF!" example, so the logic itself is fine.

    Disclaimer: This is a non-Microsoft website. The page appears to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classifies as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

    If the fully-qualified version compiles, that confirms the conflict. To find which reference is bringing in the second PdfWriter, pressing F12 on PdfWriter in your original code will show the type and assembly it resolves to anything other than iText.Kernel.Pdf.PdfWriter from itext.kernel.dll is the culprit. Checking the <PackageReference> entries in that project's .csproj for a second PDF package alongside iText 9.6.0 would pin it down.

    If it still doesn't compile, a small sample project that reproduces it would help me dig further.

    If the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here. This can help other community members facing similar scenarios. 

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.