Aug 13 2008
WPF running under IIS no more…
About a year and a half ago I began work on an application that has a WPF client deployed through click once and a public Web interface. The two apps share many reports and we really wanted to have a common report library that would provide fixed page documents through both. After evaluating some very expensive PDF generation tools and a few not so great inexpensive ones we settled on leveraging FlowDocuments as the templates and then converting the flow documents to XPS documents on the fly. The solution worked great for both the WPF app and the ASP.NET application, but there was this nagging feeling in the back of my mind because Microsoft did make it clear they did not support using WPF within a service.
Well, with Monday’s release of Service Pack 1 for the .NET 3.5 Framework our reporting solution came crashing down. A quick search on Google showed quite a few others that where using WPF within ASP.NET were running into the same issue, and of course Microsoft’s response, which to be fair Microsoft said from the begining 2+ years ago, is that executing WPF in a service is not a tested or supported scenario. *SIGH* The silver lining is that the SP1 enhancements do launch our client application MUCH MUCH faster. Great job on the cold start issue guys! In the mean time, we’ll be moving back to PDF as our standard for fixed documents until there is supported XPS creation hosted under the service model.
So back to the drawing board on searching for a reporting solution common to both. So far PDFSharp is the front runner. It has an extremely open license enabling us to incorporate it into our commercial application, the source code is very clean and the object model is proving to be very intuitive. The library incorporates MigraDoc Lite for document management and they are actively adding native WPF support into the library. The GDI+ API works well for both our WPF client and ASP.NET app. Kudos to empira Software® for releasing a solid document creation API!
Comments Off