Native .NET API
In addition to the standard COM API, easyPDF SDK is also
available as a native .NET API. The API layer is written in 100%
managed (verifiable) C# code, without using any native function
calls. It does not rely on any COM objects, p/invoke, or
The native .NET API works by launching an external worker
process (also known as a sandbox), which is not a .NET application,
but rather native x86 machine code. However, this external process
is completely isolated. Named pipes are used for communication in
between the 100% .NET world and the x86 sandbox.
There are numerous advantages to using this new native .NET API,
instead of the older COM objects:
- There is no need to install, register or configure COM objects.
Traditional COM objects are known to have permission issues when
used from a web server. Sometimes COM objects are not registered
correctly, or become inaccessible. Those types of problems are
completely eliminated in the native .NET API.
- There are no more apartment threading issues. The easyPDF
Printer COM objects are STA (single-threaded apartment), while web
servers are MTA (multi-threaded apartment), which makes printing
from multiple threads very complicated. Although ASP.NET websites
can be configured to be STA, ASP.NET web services are much more
problematic. Using the native .NET API, there are no threading
issues, because each
Printer object launches its own
independent worker process.
- If the customer's application process is killed, all related
easyPDF worker processes automatically terminate in an instant. The
opposite is true as well: If an easyPDF worker process crashes, the
SDK instantly detects this and throws a graceful exception.
- Since easyPDF is completely sandboxed, an attacker cannot break
into the web server by uploading a malicious document. They could
only gain access to the current easyPDF worker process, and nothing
else, due to process isolation.
- There is no need for a Loader object anymore. The Loader
service is still necessary for printing on the server-side, but it
is completely transparent. If Loader is necessary, it is
automatically used without any user code, and if Loader is not
necessary, it is not used, unless the customer forces it. If Loader
is required but not running, it is automatically started, as long
as there is enough permission to do that.
- If Loader is required, easyPDF is no longer running from inside
the Loader service itself. If easyPDF should crash, it is
completely isolated from everything, and therefore it cannot
possibly harm the system. When Loader is not used, easyPDF is still
isolated and safe.
- Not having COM objects means all data types, function arguments
and properties are pure .NET. For example,
no longer returns an
object, but a
byte. Exceptions thrown are native .NET as
There are no known disadvantages to using the native .NET API
versus the COM interop API.