Don’t Use Office Applications (or GDI+, or System.Drawing, or WinInet) in a Server Application (or ASP.Net)

  • Article

Johan posted a timely reminder of a long-standing perennial support call generator in his post Office Automation .

Adding one more option to the list of possible workarounds – direct XML-based production/manipulation of an OOXML (or ODF, for that matter) document (Word, Excel, Powerpoint?) might get you where you need to go.

Now, to get the laundry list out of the way, here’s a quick top-of-the-head list of other technologies best kept away from your shiny new ASP.Net application:

  • Outlook automation on the server isn’t a good idea at all, which is why CDO (or these days, DAV for Exchange Server) is preferred.
  • The Word/Excel/Powerpoint/Outlook programmable Object Models typically drive the application itself rather than manipulating data files directly, so should be avoided too.
  • Tom posted a while back on the perils of System.Drawing/GDI+ in ASP.Net applications. The same goes for WPF, last I heard.
    • We do use System.Drawing as a demo of in some of our IIS 7 demos (most recently seen in the PDC IIS 7 demo that included watermarking using System.Drawing), and elsewhere – it’s an effective demo, but the caveats are as documented.
  • WinInet (the core HTTP engine used by Internet Explorer) is another old, old case of the same designed-for-client paradigm (which led to the creation of WinHTTP (and in .Net land, HttpWebRequest etc)).

I’m not saying any of the above don’t typically work - most of the time, whatever you’re doing might work fine (I personally wrote a bunch of charting and drawing controls years ago in ASP.Net before discovering this), but when it doesn’t, our options are limited in how we’re able to help.