COM was intended to provide a unified access model across different programming languages. While this might not be perfect, it usually works pretty well.
Unfortunately, Microsoft has decided to go a different path when accessing .Net assemblies providing COM interop from another .Net language. You will not be able to add a COM reference, but will be forced to add an assembly reference instead. This might work in many cases, but often enough it doesn’t. As it turns out, it does not work for PDFCreator.
PDFCreator relies on different files being present in the folder where the executables are located (helper applications, native libraries etc.). When adding an assembly reference from your project, the assembly files will be copied to your build folder and thus detached from the rest of PDFCreator. This will result in errors, i.e. that PDFCreator.exe or Ghostscript can’t be found.
We do not know why Microsoft took that decision, but it is there since the very first version of COM in .Net, so it most likely will stay this way and we have to live with it.
Fortunately, you can trick the .Net detection by using late binding and the dynamic keyword.
First, you have to get the type using the PDFCreator ProgID. You can then create an instance of that type using the Activator. You can then use all methods of the COM interface.
Type queueType = Type.GetTypeFromProgID("PDFCreator.JobQueue");
dynamic queue = Activator.CreateInstance(queueType);
queue.Initialize();
// add more logic here
The downside is that you will lose IntelliSense support this way. You could get the method signatures from the .tlb file that is created when registering the COM interface, but again, this is blocked by Microsoft.
Starting with PDFCreator 2.5.3, we have therefore created a Wrapper, that provides the same classes and methods as the original COM interface, but invokes them using dynamic calls. You have to reference the file PDFCreator.ComWrapper.dll from the installation folder of PDFCreator. This file will be copied to your build folder, but does not have any dependencies. You can also use the same file across multiple versions of PDFCreator, as the COM interface does not change. We recommend to update the file from time to time though (recompile your application with the latest version).
In some cases we have experienced that .Net detects that we want to circumvent the .Net COM detection leading to the same error message (“PDFCreator.exe cannot be found”) as using the .Net assembly directly. In that case, you have to instatiate the dynamic type from your code once. Afterwards, you can access the wrapper without further problems.
Type queueType = Type.GetTypeFromProgID("PDFCreator.JobQueue");
Activator.CreateInstance(queueType);