To be honest, when I came across this news bit few days ago, I thought it was a 4/1 prank sort of thing and never got the instinct to check it. When I saw the same news again, I decided to verify it thinking if Microsoft too could do such things. Wow! Yes, it’s true!!! SPD 2007 is completely free (no trial version) from April 2, 2009. Read the official news and download SPD 2007 (after Passport registration) at

The official blog news is here:

As you know, SPD is the next incarnation of FrontPage, a HTML Editor and the only tool (apart from WSS/MOSS web UI itself) available for customizing Windows SharePoint Services 3.0 & MOSS 2007 based portals/sites.

I usually don’t talk too much about or discuss things that are commonly known to everyone. Why add noise unnecessarily when something has already been discussed overwhelmingly by the internet community and all it takes is an internet search to find them. The subject of this post is just one of them. I frequently see many posts requesting for jump-start help, suggestions for improving performance or troubleshooting assistance for web applications that automate MS Office applications (primarily Word, Excel & PowerPoint). Microsoft has gone depth and breadth and documented comprehensively why one should not attempt to automate Office applications on server side and consequences of doing the same. See Considerations for Server-side Automation of Office for details.

Just to reiterate quickly:

  1. Office applications are still COM based (COM servers) working in STA model. Microsoft hasn’t made them to be server-side friendly and it may not happen, at least in near future. OK, the Office interoperability library provided by Microsoft is intended for desktop Windows applications only.
  2. The object model is not thread-safe and naturally not suited for multi-threaded web server environment.
  3. Office applications are designed to be desktop-based applications and assume the availability of user interactivity (e.g. popping up a dialog box and waiting for the user to respond to it). Since web applications run in non-interactive mode, an Office application popping up a dialog box, will just keep waiting (hanging) because the dialog box won’t be visible and hence impossible to respond to it. The end-result is unpredictable.
  4. Deriving from 1 & 3, concurrent requests to Office object model will be serialized for unknown periods of time. This affects the web application’s stability, performance and scalability adversely. Web servers will start issuing HTTP/500 status code to client requests once the request queue becomes full.
  5. Too many instances of Office applications consume more memory and have the potential for threading and shared-resource related issues.

As obvious as can be, none of the above are in favor of multi-threaded web server environments and this is just a small list highlighting significant ones. There are other aspects such as security, data marshalling between COM and .NET, etc, each playing their own devil game.

So, what are the alternatives for programmatically creating/manipulating Word, Excel and PowerPoint files?

  1. Migrate to OpenXML based file formats (.docx, .xlsx, .pptx) which use XML files for data storage and Zip as the container format for the XML files. By the way, .docx, .xlsx & .pptx are all actually zip files with different extensions. Rename any of these files to .zip extension and open it using your favorite unzip tool to see the actual ‘ingredients’ of those files. Working with OpenXML formats is possible from .NET 3.0 onwards (System.IO.Packaging namespace is all about this only) and they are interoperable with other OpenXML based Office suits. Users having Office 2000/XP/2003 can still open and edit OpenXML-based files using the Office 2007 compatibility pack available freely from Microsoft.
  2. Use a 3rd party component to programmatically manipulate Office documents without Microsoft Office installation. Aspose is a popular component vendor in this area. See their website for more details (I am no way associated with this company).
  3. Consider text-based formats such as rich text format (.rtf) or HTML instead of binary .doc format. HTML is flexible, simple to create and can be opened in any browser, while RTF requires some learning curve (and patience!).
  4. If the document or Excel file is relatively simple in size and format, you may use XML cum XSLT based rendering.

If none of these are to your liking, you may write your own Office 2000/XP/2003 file processor! The binary file format specifications are freely available from Microsoft!!

Not to mention, the whole story applies not only to web applications but Windows NT service applications (or any application/service that runs in non-user interactive mode on Windows) as well.