I'm using a simple console application to convert infopath forms to PDF files. Here's a brief summary of how I'm going about this.
Summary: The console application creates a windows form. When the form is loaded (modally) I add an infopath control (Microsoft.Office.InfoPath.FormControl) to this window. At that point I call infoPathControl.Open(myInfoPathFileStream). All of this is done in a forloop.
The problem: Randomly the application will throw exceptions (Catastrophic failure, heap corrupt, etc), and even better it will occasionally hang without throwing an error. Logging and debugging has lead me to believe it's hanging in the infoPathControl.Open(myInfoPathFileStream) call. Obviously for an automated process this is unacceptable.
Attempted (but failed) solutions
- I've tried wrapping each created form in it's own (STA)thread and using thread.join. This hasn't worked due to issues with COM.
- I've tried wrapping each iteration of the loop in it's own application domain. This has worked to an extent, but due to the nature of appDomains still being synchronous, it won't solve the problem of a hang-without-error. Additionally, oddly, it seems I'm not always able to catch exceptions thrown by the COM object.
- Lastly, I've tried putting a timer on the form thread to throw an exception if the timer ever expires. So far I haven't been able to prove either way if this works or not.
Any ideas would be much appreciated as I've spent a good deal of time on this already.
Thanks!
In the end the solution was to run the infopath conversion process within it's own executable with return codes setup for success, failure, and specific types of errors. This was then called by a second executable with a timeout. If the conversion did not succeed within a period of time, it would be killed off by the calling executable. This ultimately does not resolve the issues within the infopath automation libraries, but it does the job we needed to get done without fail.