We are not using WPF with IIS, but we are certainly using WPF as a rendering engine which runs within a Windows service (which in turn runs a WCF service).
This problem is nothing short of a disaster for us. We are unveiling our product in a couple of weeks, and have deployments soon after that. I am now faced with re-writing a complex rendering engine, comprised of a large amount of geometry, various brushes, very complex text rendering, and so on, in GDI+ or some other technology, instead of focusing on the many other things that we need to get done before then.
All of our code used to work beautifully as a service, and of course it still works when the service code is instead run as a console application. And even now all of our rendering code is working in a service scenario, except for one line:
DrawingContext drawingContext = drawingVisual.RenderOpen();
This fails with the error “The program issued a command but the command length is incorrect. (Exception from HRESULT: 0x80070018)”.
If I change this to “DrawingContext drawingContext = drawingGroup.Open();” then our rendering code works again, up until the point where we need to turn the DrawingGroup into a BitmapSource using RenderTargetBitmap.
We use the code at http://forums.msdn.microsoft.com/en-US/wpf/thread/c1a1f56e-e552-452d-985c-2fb801c01bf6/ to do this conversion (minus step 4) – perhaps there is another way?? Basically this approach fails when we try to create the System.Windows.Controls.Image object, and the way to solve that is to launch a separate STA thread and have the conversion code in there. But this just results in more confusion, and leads into another threading problem.
This is all getting very cumbersome, launching extra threads and adding extra rendering steps to something that needs to work very quickly; generally it’s making a mess of things! I know it works in principal because during my testing I was able to get a single image back to the client this way before things went haywire with the extra threads, but the rendering was all wrong and out of proportion due to using a DrawingGroup instead of a DrawingVisual. So even if I got this solution working on a realistic timeline, I’d still have my work cut out for me to get it looking right.
Our product relies on SQL Server 2008, which installs .NET Framework 3.5 SP1 as a prerequisite, so I don’t see how we can get around this issue in the short term. Unless we can uninstall .NET Framework 3.5 SP1 and still have SQL Server operate as normal?
I have already tried many, many things to fix this (running the services with different users and permissions, allowing interaction with the desktop, launching the console app from the service, running the console app as a service using “Exe To Service”, using different threads for the rendering, targeting a different .NET framework in Visual Studio 2008, etc). Possibly we could host the WCF service in a web server other than IIS? Or re-write it somehow using WIC? Or possibly redo the entire thing in GDI+? Or maybe there’s some way to use WPF operations to “paint” to a GDI+ surface? I’m really clutching at straws here. The best I have come up with so far is to set up Windows Server to auto-login and then automatically run a console application, but obviously this is not a long-term solution.
I’m VERY interested to hear what you come up with David!!