I've seen this question asked before, but I have not seen any definite answers, and definitely not any answers that solve my problem. I created a windows service to send faxes (semi-automatically) using the FAXCOMEXLib library. So far, my service has been successful at sending text files (.txt). But when I try to send pdf, jpg, or tif files, I get the "Operation failed" error. In SO, I've seen a lot of discussion about the permissions of the user that the service is running under. I've tried a lot of different options (Local Service, Local User, custom user with admin privileges, allow service to interact with desktop). But nothing seems to make a difference. It seems that the service does not have permissions to open the appropriate app to "print" the pdf, jpg, or tif file. But I am only speculating. Has anyone been successful in sending a fax through FAXCOMEXLib in a Windows service? Here is my code that sends the fax:
fileName = @"D:\temp\FaxTest.txt"; //THIS WORKS
//fileName = @"D:\temp\FaxTest.pdf"; //Operation failed
//fileName = @"D:\temp\FaxTest.tif"; //Operation failed
faxDoc.Sender.Name = faxRec.From;
faxDoc.Sender.Company = faxRec.From;
faxDoc.Body = fileName;
faxDoc.Subject = faxRec.ReferenceId;
faxDoc.DocumentName = faxRec.ReferenceId;
var to = "xxxxxxxxxx";
faxDoc.Recipients.Add(to, "Some Name");
var serverName = Environment.MachineName;
string[] returnVal = faxDoc.Submit(serverName);
In case you're wondering, yes, those files do exist on the server with those names, and they are valid files (I can open them up in Adobe Reader and Picture Viewer). And this also works just fine if I run this locally on my dev machine. And of course, the appropriate viewer pops up before sending (on my local machine). My guess is that for some reason the service cannot open the viewer. Has anyone been successful sending a PDF this way in a Windows service?
I want to give a complete answer to this. The previously posted answers had some of the solution, but they did not give a complete picture of everything we had to do to successfully send a pdf file through a fax line, using FAXCOMEXLib in our custom Windows service.
I want to start this off by saying that FAXCOMEXLib is made for a windows console app, not a windows service. You can even read this in the documentation. And I think that's why we had so much trouble getting it working.
However, we were able to get it to work (finally) after much trial and error. Most of the problems we faced were related to setting and permissions in Adobe Reader. What we found is that Adobe Reader was trying to do a lot of things behind the scenes when processing a PDf file. And those "things" it was trying to do required user interaction (clicking away alert boxes, etc). When running this under a Windows service, there is no user interaction from that service, which caused our process to hang indefinitely and eventually error out. But, we found that there is a way around all that. Here is how we did it:
Here is the snippet of code that we are using that works:
There is more code than this in our service, of course. The other code does things like handle callback event handlers to track the status of sending/completed/failed faxes, etc. But this is the "heart" of the code that actually initiates the "send".
And here is a list of configuration changes we made to the server to make our custom Windows service properly decode, render, and send pdf files as faxes. Some of these are listed in some of the answers, but some are not, and I wanted this to be a complete answer.
myProcess.Kill()
function in the sample code).And that should do it. It's a little bit cumbersome, but I hope this gives a complete example of how to set up Adobe Reader in conjunction with your custom Windows service to send faxes from pdf files on a Windows server. We've been doing it for a couple months now with no issues. Our client does a low volume of faxes, so I cannot speak to how this works with a high volume of faxes. So, if you are looking for a "free" way to send faxes, without paying for something like Interfax, this could be a viable option, at least for low volume.