A few weeks ago we had an interesting discussing in my team (triggered by a customer’s request for some hints on charting in ASP.NET) about the use of GDI+: here is what the documentation states on the subject (and what spurred the customer on opening a Service Request with CSS):
Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.
(from http://msdn2.microsoft.com/en-us/library/system.drawing.aspx)
Just to clarify: they were not experiencying any particular problem and you can go with GDI+ if that workes fine according to your requirements, but the statement above means that CSS can’t help you if you are running into troubles with it…
Customer concern and question: Searching the internet, most of the samples for ASP.NET applications providing charting work with GDI+; there are even books on this topic. Why Microsoft is not supporting GDI+ in ASP.NET? If we want to build charts on our own, what design can we use which Microsoft DO support?
Well… GDI+ ins’t supported from a service because those components/classes where not designed/tested to run without an interactive desktop in a high-load environment.
Even using pure native GDI from a non interactive context has always been a pain (at least from my experience). All GDI functions are based on a device context that we have to map to an existing device, especially when using non interactive context; those libraries work great from MFC or any other interactive application, but were just not designed for silent applications.
As far as I know GDI+ is mostly a managed wrapper on GDI (but I’m not a real expert in this area, so feel free to correct me if you wish 😉), so I assume the test cases for those wrapper were not deep enough to ensure all external calls will be handled correctly without an interactive desktop attached. In my experience with GDI+ within ASP.NET application, even if it’s not supported in most of cases it works fine.
We had cases in our team where the process was hung, and it turned out that most of time the hang was caused by GDI+ critical sections not correctly released because of lack of Dispose() calls. That’s very important in GDI+ to always have reliable Dispose(), since most of GDI+ critical sections are released there. We mostly had problem with Fonts, process was stucked in GdiPlus!GdipNewPrivateFontCollection(), GdiPlus!GdipGetGenericFontFamilySerif(), etc…
Often, the problem was coming from exceptions raised in the Dispose call (from the Finalizer or explicit ones) that were not handled correctly, and leading to that critical section lead. From what we saw, having reliable exception handling/GDI+ objects disposition allows to have a stable situation (but still unsupported…) .
Then what Microsoft can recommend to generate graphs from an ASP.NET application/service?
I would say the more reliable way is a GDI COM component, developed in a smart way, and tested enough in non interactive contexts. That’s the way all good third party native charts components are developed. The other points I was thinking about are native enhanced metafiles, or maybe even OpenGL code. I’m not experienced enough with it, but I think you have less requirements from a non interactive desktop.
From a pure managed perspective, I doubt you’ll find a reliable & supported way to generate such graphs. From the non deterministic way of managed code works, it’s really hard to interact with GDI subsystem in a highly reliable way…. So in my opinion… that’s just a not-any-supported-way issue…
Cheers
P.s.
Thanks to my colleagues Nicolas Dietrich from CSS France and Stefano Pronti from CSS Italy for sharing their thoughts on this topic! 🤓