We have some programs that must be run in the older CGI context in Windows IIS. The EO.Pdf.PdfDocument functions all work in that environment. Adding pages with images or text also works perfectly in that environment. However the EO.Pdf.HtmlToPDF conversion functions all fail immediately with an Exception in HtmlToPdf.ConvertUrl or HtmlToPdf.ConvertHTML method: EO.Pdf.HtmlToPdfException: Convertion failed. Illegal characters. These exact same code works great in a non CGI environment, for instance in an ASHX module, or as a plain console program in Windows.

Here is an example of converting a String (readText) with ConverHtml that throws this error under CGI.

HtmlToPdf.Options.PageSize = new SizeF(8.5f, 11f);
HtmlToPdf.Options.OutputArea = new RectangleF(0.5f, 0.5f, 7.5f, 10.0f);
HtmlToPdf.Options.BaseUrl = ".";
HtmlToPdf.Options.NoLink = true;

HtmlToPdf.ConvertHtml(readText, doc, HtmlToPdf.Options);

The crash is occuring when your internals attempt to run: System.AppDomain.get_BaseDirectory(). That is because IIS always sets the base directory in the form of: Appbase = file://?/F:/Development/PortalTest/cgi-bin/ (that's my particular path).

Notice the question mark '?' it adds to the base path string. That will throw the error every time.

Here is a stack trace I got from IIS:

Unhandled Exception: EO.Pdf.HtmlToPdfException: Convertion failed. Illegal characters in path. ---> System.ArgumentException: Illegal characters in path.
at System.Security.Permissions.FileIOPermission.HasIllegalCharacters(String[] str)
at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, AccessControlActions control, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String path)
at System.AppDomainSetup.VerifyDir(String dir, Boolean normalize)
at System.AppDomain.get_BaseDirectory()
at EO.Pdf.Internal.ch.a(e5 A_0, String A_1, Boolean A_2)
at EO.Pdf.Internal.lt..ctor()
at EO.Pdf.Internal.lt.a(lt A_0, List`1 A_1, Boolean A_2)
at EO.Pdf.Internal.lt.a(hj A_0, Boolean A_1)
at EO.Pdf.Internal.lt.a(hj A_0) --- End of inner exception stack trace ---
at EO.Pdf.Internal.lt.a(hj A_0)
at EO.Pdf.HtmlToPdfSession..ctor(HtmlToPdfOptions A_0)
at EO.Pdf.HtmlToPdf.ConvertHtml(String html, PdfDocument doc, HtmlToPdfOptions options)
at EOErrorSample.EOErrorSample.AddTextPages(PdfDocument doc, String TextFile, String& errorMessage)
at EOErrorSample.EOErrorSample.workWithPDF()
at EOErrorSample.EOErrorSample.Main(String[] args)


Is there any way around this? Is there any reason that the HTML converters can't use Directory.GetCurrentDirectory(), or something other than System.AppDomain.get_BaseDirectory() if it must get the run location? I tried a "real" path in the HtmlToPdf.Options.BaseUrl and the same thing happens. So, I can't see a way to override the internal behavior.

Thanks,

- Kim

Hi,

We have posted a new build that will try to get the working directory from EO.Pdf.dll's path if System.AppDomain.get_BaseDirectory fails. You can download the new build from our download page and see if it resolves the problem for you.

Thanks!

Great. Thank you very much for confirming the fix! Please feel free to let us know if there is anything else.