How to use Word and Excel in ASP.NET: Don't!

I have seen so many of these that it just makes me shake my head: "How can I use Excel on IIS in ASP.NET (or Word, or any Office program)"....

The answer is, you can try, but it is neither supported or recommended. Here is why:

1.User Identity: Office Applications assume a user identity when they are run, even when they are started via Automation. They attempt to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM or IWAM_[servername] accounts), and therefore Office may fail to initialize properly on startup, returning an error on CreateObject or CoCreateInstance. So, right off the bat, you've got a real problem, OK?

2. Interactivity with the Desktop: Office Applications assume that they are being run under an interactive desktop, and may in some circumstances need to be made visible for certain Automation functions to work properly. If an unexpected error occurs, or an unspecified parameter is needed to complete a function, Office is designed to prompt the user with a modal dialog box that asks the user what they want to do. A modal dialog box on a non-interactive desktop (your web server) cannot be dismissed, which causes that thread to stop responding (hang) indefinitely. That's why trying to do what you are doing (e.g., run Excel from an ASP.NET page on your webserver) is NOT SUPPORTED.


3. Reentrancy and Scalability: Server-side components need to be highly reentrant, multi-threaded COM components with minimum overhead and high throughput for multiple clients. Office Applications are in almost all respects the exact opposite. They are non-reentrant, STA-based Automation servers that were designed to provide diverse but resource-intensive functionality for a single client. In sum, the threading model is completely inconsistent with ASP.NET. Even if you do get it to work, you have essentially "shot yourself in the foot" from a scalability perspective.

4. Server-Side Security: Office Applications were never intended for use server-side, and therefore do not take into consideration the security problems that are faced by distributed components. Office does not authenticate incoming requests, and does not protect you from unintentionally running macros, or starting another server that might run macros, from your server-side code. Based on the security settings that were last set, the server can end up running macros under an Administrator or System context with full privileges -- and compromise your network. Let's simplify the above: How would you like it if your ASP.NET application loaded a Word document that a user uploaded, which would promptly attempt to delete all the files on your webserver's C:\ drive?

There are a number of excellent components by third party vendors that were desigined to avoid these and other serious issues, and the Office Web Components installation from Microsoft does so as well.

Finally, besides the technical problems, you need to consider the feasibility of such a design with respect to licensing. Current licensing guidelines prevent Office Applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).

In sum: Don't waste your time. I didn't "come up" with the above information, most of it is found in several KB articles on the subject. All I did was distill it into a more easily digestible form.

And don't post to newsgroups asking for help, because usually, the above is what you'll get as a response! If you need Word, Excel or Powerpoint functionality in your ASP.NET application, use OWC or a third - party component that was designed for this purpose.