Found a pretty insidious bug (or I'm doing something wrong, but I'm pretty sure it's not me), and I think the bug is in the CLR possibly. Fortunately there's an easy workaround.
InitLibrary gets called in the constructor of internal class PdfLibrary. A static instance of PdfLibrary is supposed to get created as part of the internal static PdfFile class, specifically the _library field. The code assumes - which as far as I know is supposed to always be the case - that the _library field is initialized automatically the first time any static class method is called.
Apparently this is not always the case. Under certain conditions I haven't completely identified, it is possible for _library not to be initialized when Create or another PdfFile method is called. As a result, InitLibrary does not get called, and Pdfium then crashes when any other library call is made.
I discovered this problem when installing my application onto a fresh Windows 7 install. Pdfium.dll was causing an exception and forcing a shutdown. Oddly, when I ran the application through the Visual Studio debugger, everything was fine. Since I couldn't use the debugger (as the problem would then not occur), I inserted MessageBox calls to advise when certain code lines were reached. That's when I discovered that Create was getting called before the PdfLibrary constructor.
I'm still scratching my head as to why this would happen. What's even more bizarre is why it happens running an application standalone, but not when using the VS debugger. At first I thought perhaps it was a problem with the C# code optimizer used for Release configurations. It's possible the compiler saw that the _library field was never actually referenced in the PdfFile class, and so it dropped it as an optimization. But turning off optimization didn't help. Thus I think it's a bug or at least an inconsistency in the way the CLR runtime works in standalone mode versus through a debugger.
In any event, it's easily fixed. In the PdfFile.Create method, I just added:
if ( _library == null )
_library = new PdfLIbrary();
Voila, problem solved.
I guess the lesson is we can't rely on static field initializers to get called before other class methods if those fields are not actually used by the class. If you have code that has to be called before a static class method is invoked, apparently it must be in a static constructor or the method itself.
Hope I've helped and maybe saved someone else a lot of trouble. I didn't think it was worth forking the project for this. Strongly encourage the author to make this update though as it no doubt will arise again.
Found a pretty insidious bug (or I'm doing something wrong, but I'm pretty sure it's not me), and I think the bug is in the CLR possibly. Fortunately there's an easy workaround.
InitLibrary gets called in the constructor of internal class PdfLibrary. A static instance of PdfLibrary is supposed to get created as part of the internal static PdfFile class, specifically the _library field. The code assumes - which as far as I know is supposed to always be the case - that the _library field is initialized automatically the first time any static class method is called.
Apparently this is not always the case. Under certain conditions I haven't completely identified, it is possible for _library not to be initialized when Create or another PdfFile method is called. As a result, InitLibrary does not get called, and Pdfium then crashes when any other library call is made.
I discovered this problem when installing my application onto a fresh Windows 7 install. Pdfium.dll was causing an exception and forcing a shutdown. Oddly, when I ran the application through the Visual Studio debugger, everything was fine. Since I couldn't use the debugger (as the problem would then not occur), I inserted MessageBox calls to advise when certain code lines were reached. That's when I discovered that Create was getting called before the PdfLibrary constructor.
I'm still scratching my head as to why this would happen. What's even more bizarre is why it happens running an application standalone, but not when using the VS debugger. At first I thought perhaps it was a problem with the C# code optimizer used for Release configurations. It's possible the compiler saw that the _library field was never actually referenced in the PdfFile class, and so it dropped it as an optimization. But turning off optimization didn't help. Thus I think it's a bug or at least an inconsistency in the way the CLR runtime works in standalone mode versus through a debugger.
In any event, it's easily fixed. In the PdfFile.Create method, I just added:
if ( _library == null ) _library = new PdfLIbrary();
Voila, problem solved.
I guess the lesson is we can't rely on static field initializers to get called before other class methods if those fields are not actually used by the class. If you have code that has to be called before a static class method is invoked, apparently it must be in a static constructor or the method itself.
Hope I've helped and maybe saved someone else a lot of trouble. I didn't think it was worth forking the project for this. Strongly encourage the author to make this update though as it no doubt will arise again.