Office Automation and IIS

re: Office Automation and IIS

jvierra — Fri, 12 May 2006 23:29:06 GMT

This question has come up over-and-over for years. Thnkyou for clarifying it loudly from a very hard to argue with perspective.

See my additions here to why and what can or might be done to be able to use Office from the web.

http://tech-comments.blogspot.com/2006/05/support-for-office-document-creation.html#links

re: Office Automation and IIS

David.Wang — Sat, 13 May 2006 12:18:45 GMT

jvierra - Thanks...

Yeah, Office Automation is right up there with:
1. writing VB COM components for use in ASP pages
2. using Access/JET as the database for use in ASP pages

When it comes to practicality.

I understand that Office Automation, VB COM components, and Access MDB databases are easy to create and use, and it is tempting to try and scale the desktop solution to co-workers/clients by simply bringing it to the web... but what users fail to understand is that those technologies are all ultimately designed for Single end-user Interactive use on a desktop and NOT multi-user remote access on a web page.

And when you try to shoehorn a desktop application onto the web and beyond its initial design, all sorts of bad things like hangs, crashes, slow performance, high lock contention, etc can occur. And no matter how much users complain, Microsoft can only provide a few hacks and recommend that you "use the right technology designed for the right problem".

XML, SQL, Script Components, and ASP.Net are the way to go to write scalable, multi-user, remote-access web applications...

//David

re: Office Automation and IIS

Mark Jenner — Thu, 20 Dec 2007 22:00:51 GMT

It seems to me that wanting to have a web app be able to process and/or produce Word and Excel documents is an extremely basic and common requirement with very wide utility. There is nothing inherently "interactive" about reading or writing an Excel spreadsheet... it is simply a file format that should be able to be easily processed in a non-interactive environment.

The fact that Microsoft products are unable to provide this functionality is only an indication of inadequate design on the part of Microsoft. They simply inextricably coupled the disparate functions of document processing and creation on one side with the interactive applications with which these functions are typically carried out by desktop users on the other.

Microsoft, in the person of Mr. Wang, instead of aknowledging this design flaw and working to address it, blames the customer for wanting this functionality. A 100% legitimate and useful customer requirement is invalidated as being "outside of reality".

Microsoft may view "reality" as "anything Microsoft can do". Well, the users know otherwise.

re: Office Automation and IIS

David.Wang — Fri, 21 Dec 2007 07:49:14 GMT

Mark - I'm not certain where you are coming from. This is my point --

Microsoft Office has on object model that can be perfectly used from a Web App to process/produce Word/Excel documents. People do this all the time in non-interactive manner for Office-related automation.

The problem is whether the function can be non-interactively accessed in a single-threaded or multi-threaded manner and its performance/reliability -- specifically, for web-access. This actually reduces down to a classic problem with a class solution that is hardly an "Microsoft reality". Almost all developers would choose the same tradeoffs given the information at the time.

Let's look it this way -- 99.9999% of Office users run it interactively with no requirement of multi-threaded access (which is additional software complexity, which translates into added cost and longer/riskier ship date). You can certainly make an academic argument that non-interactive, multi-threaded access to Office is a 100% legitimate and useful customer requirement, but when you weigh the $100 billion worth of the 99.9999% Office users vs the $10 million worth of non-interactive, multi-threaded access, what would you choose?

I am sure that you will choose to delay Office release at the cost of $10 million/day to add a feature/design worth only $10 million over its lifetime.

This is the reality of software development which few people know nor understand.

//David