Limitations of Office Web Components when used server-side

The Microsoft Office Web Components provide Web developers with spreadsheet, charting, and pivot table capabilities to make Web pages more dynamic. The components were developed as client-side ActiveX controls that can be used inside of Microsoft Internet Explorer.

The functionality of the components, however, has led many developers to use them in server-side solutions, such as in Active Server Pages (ASP) or COM+ to build and export charts. While the components can be used in this way, limitations can hinder the stability and performance of server code, and may make the components problematic in a large-scale server-side solution.

Microsoft does not recommend that you use the Office Web Components in a server-side solution. Several known limitations prevent the components from functioning properly in a highly reentrant, multi-threaded, non-interactive environment. Among the problems that you may experience are the following:

• Slow execution or poor performance: The Office 2000 Web Components were designed for the multiple single-threaded apartment (STA) environment of Internet Explorer, and not the multi-threaded apartment (MTA) environment of most server-side applications. The protection for thread concurrency for the Office Web Components was not designed for the high volume, multi-threaded calls that are typical of a Web service, and can therefore impact performance. For example, the Office Web Components protect a number of shared memory blocks with the same critical section, so that threads that do not modify a memory section may still be blocked if another thread modifies the memory section. Moreover, many of the functions for processing were imported from other Office sources that were designed in a single-threaded model, and these sections of code cannot run concurrently.
• Out-of-memory errors: The Office Web Components uses a static build of the Microsoft Office shared library to handle memory management. The memory allocation functions of the Microsoft Office shared library are designed for the client side, and do not expect the loads and concurrent requests that are typical in a server-side solution. This may limit the amount of memory that the components have available to them, regardless of the amount of memory that is free on the computer.
• Automation errors at random times: The Office Web Components use a few state variables that are not fully protected, and if the variables change while a function is running, they can cause the function to fail unexpectedly. Functions that require asynchronous processing (such as requesting data from a data source, or calculating cell values in a spreadsheet) are more likely to generate such errors if multiple threads are automating concurrently.
• Thread deadlocks: In some situations, the Office Web Components may encounter race conditions that lead to indefinite wait states or global exceptions, which can orphan a thread and cause a loss of resources. These situations typically occur when the components are "stressed"; for example, this may occur when a high number of clients make concurrent requests to the server, and each request creates, automates, or destroys its own component instance. Pooling instances can minimize the risk of deadlock.
• Multi-Thread Contention: If creating separate Office Web Components in separate Single Threaded Apartments (STA) inside a single process, and the threads run concurrently, you may encounter performance penalties or thread contention issues which can result in high CPU usage or state corruption. It is recommended that you keep all instances in the same STA, or if you need parellel execution, you create separate processes to host each STA thread needed.

The problems with the Office Web Components that are listed above are design limitations that are consistent with their intended use as client-side ActiveX controls. No workaround or fix is available for these Office Web Components limitations.

Although you can run the Office Web Components server-side and this will work for a small Web site, these issues may prevent you from scaling the solution up to handle a large Web site that has heavy traffic. If you plan a new solution, carefully consider your scale requirements and decide whether Office Web Components is suited to meet the demand. If you need a more scalable solution, there are many third-party products that can perform similar operations and are designed specifically for server-side operations. These third-party products may be better suited to your requirements.

If you currently use the Office Web Components in your server-side Web solution, consider upgrading to the most recent version of Office Web Components. Some memory error issues and automation error issues have been addressed in more recent versions of Office Web Components. However, the design of the Office Web Components as ActiveX controls will not make them fully reliable for large scale Web projects if the components are run server-side.

To download the latest version of the Office Web Components, see the following Office Web site: For more information about situations where a developer may want to use Office Web Components server-side, click the following article numbers to view the articles in the Microsoft Knowledge Base: