easyPDF SDK Usermanual
PDF Creator Programming API  |  Download Free Trial  |  Contact Us to Purchase

Native .NET Printer API


The native .NET API is very similar to the COM API, with only a few distinct differences.

First, you need to add using BCL.easyPDF.Printer;.

Then you need to add reference to the BCL.easyPDF.Printer.dll assembly, which is under C:\Program Files\Common Files\BCL Technologies\easyPDF 8.

.NET Framework 3.5 or above is required.

COM exceptions were replaced by the new PrinterException.

The Printer class is inherited from IDisposable, which means it really needs to be deterministically disposed. Relying on the garbage collector is not recommended, because each Printer object launches a separate worker process. Even though these worker processes are sleeping while not executing a function, they are still in the memory, and only really quit when the Printer object is disposed.

The Printer object should be treated as if it were an expensive resource, such as a file, mutex, or a database connection. If you would like to know what really is inside Printer, it is just a named pipe. However, the worker process is programmed to only quit when the pipe is closed.

If the customer's application crashes, the system automatically closes all pipes belonging to the process, which means all related worker processes automatically quit as well.

The minimal C# sample code looks like this:
(Note: all Native .NET sample code and declarations have a light yellow background color)

using(Printer printer = new Printer())
   printer.PrintJob.PrintOut(@"c:\test\input.doc", @"c:\test\output.pdf");

The key here is the using keyword, which gives Printer a deterministic behavior.

An alternative solution, especially if you are catching exceptions, is the try/finally idiom:

Printer printer = new Printer();
   printer.PrintJob.PrintOut(@"c:\temp\input.doc", @"c:\temp\output.pdf");
catch(PrinterException ex)

The key here is the finally block, which calls Dispose().

Printer's constructor is designed to never throw exceptions. That's because it does not launch a worker process and does not create a named pipe, it merely initializes a few variables to their default values. In other words, creating a Printer object is extremely lightweight, like creating a Color object.

However, as soon as you do anything else, even getting a property, it instantly launches a worker process.

Notification Events

Notification events in the native .NET API are slightly different than in the COM object. Here is an example that catches OnPageStart, which is called before printing each page:

using(Printer printer = new Printer())
   printer.PrintJobMonitor.OnPageStart += new PrintJobMonitor.OnPageStartEventHandler(OnPageStart);
   printer.PrintJob.PrintOut(@"c:\temp\input.doc", @"c:\temp\output.pdf");

You would then create your own handler method as follows:

prnMonitorResponse OnPageStart(int id, int pageNumber)
   return prnMonitorResponse.PRN_MON_CONTINUE_CONVERSION;

What's different here from COM is that event handlers return prnMonitorResponse, instead of int.

Launch Timeout

Launching the worker process and connecting the named pipe should happen very fast, in milliseconds. However, under an abnormally heavy load, the computer may not have enough cycles to perform this task in a timely fashion.

The Native .NET API has an internal timeout built-in. The default value is 1 minute. This is because a server may momentarily slow down so much that it is not responding for seconds, but it usually recovers after a while.

The default timeout value can be changed via the LaunchTimeout member (in milliseconds). This must be performed immediately after the creation of the Printer object.

using(Printer printer = new Printer())
   printer.LaunchTimeout = 30000; // 30 seconds
   printer.PrintJob.PrintOut(@"c:\temp\input.doc", @"c:\temp\output.pdf");

Upon timeout an exception is thrown, and the SDK cannot be used. Another attempt may be made later.

Server-Side Operation

Printing from the server side has always required easyPDF Loader, a special service that helps execute functions under a different user account.

The Native .NET SDK offers two possible solutions for server-side printing. One is called the Loader Service, and the other one is called Impersonation.

Customers who are printing from a web server or a system service should study both alternatives, and decide which one they prefer.


PrinterMonitor does not exist in the native .NET API at this moment.

Note that most customers do not need PrinterMonitor. Its sole purpose is to enable File > Print in a desktop environment. It was not designed for server-side operation anyway.

If you just want to get notification events while printing, please use PrintJobMonitor, which is part of the native .NET API.

If you really need PrinterMonitor, it is still available in the COM API.