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.
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.
Yep, spreadsheetgear.com is by far the best and fastest I've ever used. FarPoint's new stuff isn't bad but doesn't appear quite as fast processing calculations. Neither of these need office installed on the server.
ReplyDeleteHow about Aspose? Don't they have an Aspose.Excel managed code component?
ReplyDeleteWe are actually using Aspose Cells on a project I'm working on (they had to change the name from "Excel" to "Cells" because of MS trademarks, I believe). Aspose has an entire suite of products for Office automation, including PowerPoint and Word. I won't go on record saying Cells is the best Excel server-side component, but I have found it pretty robust and easy to use.
ReplyDeletePerformance with Aspose was a real problem for us awhile back. Keep in mind, we were filling thousands of cells with complex calculations.
ReplyDeleteWe switched to spreadsheetgear and never looked back. I've never used their office automation products. So, I don't have 2 cents to chime in with.
I am looking for comparison between FarPoint Spread and SpreadsheetGear control for my following basic Requirement.
ReplyDeleteOur basic requirement is:
We have excel XML or excel file, inside file we got formula and formatting, usually we store file in Database (It can be varbinary or xmldata). We want a control to load spreadsheet with formula and formatting not just only content from excel file and display in our application UI (Our first choice is to load the file from DB – which is stored in some formet). Then user can edit the data (not the formula, and we can set formula implemented cells non-editable, cells should auto-calculate and update the value), and app can also read and write data to the cell from database.
Can anyone help me here?