Article ID: 268016
Article Last Modified on 1/10/2007
APPLIES TO
- Microsoft Office Excel 2003
- Microsoft Excel 2002 Standard Edition
- Microsoft Excel 2000 Standard Edition
- Microsoft Excel 97 Standard Edition
- Microsoft Internet Explorer 3.0
- Microsoft Internet Explorer 4.0 128-Bit Edition
- Microsoft Internet Explorer 5.0
- Microsoft Internet Explorer 5.5
This article was previously published under Q268016
SYMPTOMS
When you navigate to a Microsoft Excel Add-in (*.xla) file from a Web page while running Internet Explorer, the add-in fails to load and Internet Explorer displays a warning that the page you are looking for is currently unavailable. The problem occurs when you open the add-in with the HTTP protocol but not with the FILE protocol.
CAUSE
The warning occurs because the Excel Add-in (XLA) is really an Excel Workbook (*.xls) that does not contain any worksheets. The only part of the file that is used by Excel is the Visual Basic for Applications (VBA) project sub-storage, which contains the add-in (VBA) code. However, because an XLA is just an XLS in disguise, it shares the same CLSID as an Excel Workbook ("{00020820-0000-0000-C000-000000000046}") and is represented by the same Multipurpose Internet Mail Extensions (MIME) type ("application/vnd.ms-excel").
Internet Explorer versions 3.0 and later support in-place activation of ActiveX Document objects (ADO) inside the Web browser. Because an XLA has the same CLSID as an Excel Workbook, Internet Explorer attempts to load an XLA as an embeddable workbook. Because the XLA contains no worksheets for in-place editing, the embedding fails and Internet Explorer displays the warning. The running instance of Excel that was started for the embedding may either shut down immediately or become visible. However, because of the failed in-place activation, it appears without any toolbars or menus.
Internet Explorer relies on the MIME type setting of documents that are returned from a server to know how to activate the page for viewing. If an HTTP server returns a MIME content type of "application/vnd.ms-excel" for a requested page, Internet Explorer tries to load the file contents as an Excel workbook. By default, Internet Information Services (IIS) associates the *.xla extension with this MIME type, so that hyperlinks to XLA files typically result in the behavior described.
RESOLUTION
To avoid the problem of opening the add-in by using the HTTP protocol, your Web page can use client-side scripting to start Microsoft Excel through Automation, and then load the XLA from a URL. The following steps demonstrate this technique:
Create a new text file in Notepad and add the following code:
<HTML> <BODY> Press the button to start Excel and load an XLA. <SCRIPT LANGUAGE="JScript"> function LoadMyXLA() { var oXL = new ActiveXObject("Excel.Application"); var oAddin = oXL.Workbooks.Open("C:\\Test.xla"); oAdd.RunAutoMacros(1); oXL.Visible = true; oXL.UserControl = true; } </SCRIPT> <P><INPUT ID=button1 TYPE=button VALUE="Load XLA" ONCLICK="LoadMyXLA()"> </BODY> </HTML>- Replace the string passed to the Open method with the path to your XLA (either a fixed path or a URL).
- Save the text file and rename it with an HTM extension, then open it in Internet Explorer and click the button. Note that Excel starts up in a separate window and that the XLA is loaded.
MORE INFORMATION
Excel Add-ins (*.xla) do not support embedding and cannot be opened inside of Internet Explorer. End users do not normally open XLAs; instead they open an XLS that (if needed) loads one or more XLAs during startup. Only in rare cases does a user need to start an XLA directly. In these situations, scripting code can be used if the file is to be started through Internet Explorer.
Automation of Excel from script does not work, however, if the client computer has been set to High security or if the "Initialize and script ActiveX controls not marked safe for scripting" option has been set to Disable. These clients must lower their security to "Prompt" to be able to choose to run the script code and open the XLA. XLAs and Excel Automation are not safe for scripting by default.
For additional information about how to programmatically change these Internet Explorer options from a trusted control or setup utility (but not script), click the following article number to view the article in the Microsoft Knowledge Base:
182569 Description of Internet Explorer Security Zones Registry Entries
Other Workarounds and Considerations
If scripting is not a solution that fits your Web design, you can seek to avoid the problem through registry changes and modification of the XLA file itself. This must be done outside of Internet Explorer or Active Server Pages (ASP), and is not a viable solution for Web applications where the client environment cannot be controlled. The following discussion explains in more detail the cause of the problem and what you must do to avoid the problem.
Because Internet Explorer uses the MIME type specified by the server during an HTTP GET operation, you need to prevent IIS (or the Web server with which you are communicating) from associating the *.xla extension with the "application/vnd.ms-excel" MIME type. IIS saves this information in the property settings for the Web folder (that is, in the metabase). To change the behavior of your IIS Web site, you need to edit the metabase. To do this for IIS versions 4.0 and 5.0, you can use the following steps:
- Start the Internet Information Services Manager.
- Right-click the folder containing the add-in under the Default Web Site, and choose Properties from the drop-down menu.
- Select the HTTP Headers tab, and click File Types under the MIME Map section.
- Click New Type. Specify .xla for the Associated Extension, and text/plain for the Content Type (MIME). Click OK to add the file type.
- Click OK to close the File Types dialog box, and then click OK to close the Folder Properties dialog box.
NOTE: The IIS server may need to be shut down and restarted for the changes to take effect.
For files opened locally, or for files opened from a Web server that did not specify a MIME type, Internet Explorer uses the CLSID from the file itself to associate a server and load the file. Because an XLA is the same an XLS, the CLSID for the root storage is to an Excel Workbook (Excel.Sheet.8). In order to prevent Internet Explorer from using this CLSID, you need to strip it from the file using OLE Structured Storage APIs. This should not affect the functionality of the file in Excel, but if the file is modified in Excel, the CLSID is re-inserted into the file.
The following Microsoft Visual C++ code shows you how to replace the CLSID of the main storage with a NULL CLSID:
#include <windows.h>
int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR pszCmdLine, int nCmdShow)
{
WCHAR wszFile[MAX_PATH];
CHAR szFile[MAX_PATH];
szFile[0] = 0;
OPENFILENAME ofn;
ZeroMemory(&ofn, sizeof(OPENFILENAME));
if (FAILED(CoInitialize(NULL)))
return -1;
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFilter = "Microsoft Excel Addins (*.xla)\0*.xla\0\0";
ofn.nFilterIndex = 1L;
ofn.lpstrDefExt = "xla";
ofn.lpstrFile = szFile;
ofn.nMaxFile = MAX_PATH;
ofn.Flags = OFN_HIDEREADONLY | OFN_FILEMUSTEXIST;
if (GetOpenFileName(&ofn) && (szFile[0] != '\0'))
{
if (!MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED,
szFile, -1, wszFile, MAX_PATH))
{
MessageBox(NULL, "Can't convert to Unicode!",
"XlaClsid", MB_ICONSTOP | MB_SETFOREGROUND);
return -2;
}
IStorage* pstg = NULL;
HRESULT hr = StgOpenStorage(wszFile, NULL,
STGM_READWRITE | STGM_SHARE_EXCLUSIVE, NULL, 0, &pstg);
if (SUCCEEDED(hr) && pstg)
{
pstg->SetClass(GUID_NULL);
pstg->Release();
MessageBox(NULL, "Call succeeded. CLSID has been stripped.",
"XlaClsid", MB_ICONINFORMATION | MB_SETFOREGROUND);
}
else
{
MessageBox(NULL, "Unable to open file. It may be in use.",
"XlaClsid", MB_ICONSTOP | MB_SETFOREGROUND);
}
}
CoUninitialize();
return 0;
}
Note Internet Explorer does not check the CLSID from the structured storage file if the XLA is opened from the Address bar, but does check if the XLA is referenced in a hyperlink. While this behavior may change in future versions of Internet Explorer, you should not rely on the current behavior and forgo removing the CLSID from the XLA.
If the file's CLSID has been removed, and the server has not specified a MIME type, Internet Explorer then uses the file extension to start Excel and load the XLA. Depending on the configuration of the registry on the client system, the file may still open for embedding, so modification of the client registry may be needed. The registry keys of interest are:
HKEY_CLASSES_ROOT\.xla
-and-
HKEY_CLASSES_ROOT\Excel.Addin
You need to make sure that there is no "Content Type" value specified under these registry keys because the keys can re-direct Internet Explorer to a MIME type, and from there back to the workbook CLSID. Also, the Excel.Addin key may contain a CLSID subkey that also re-directs Internet Explorer to use embedding. This key should be renamed or removed to prevent Internet Explorer from finding the CLSID.
If all of the preceding steps are followed, Internet Explorer will be unable to locate a CLSID for the file type and will load the file with a ShellExecute command. This runs the file as if the user had double-clicked it from Internet Explorer.
REFERENCES
For additional information about MIME types and Office documents, click the following article numbers to view the articles in the Microsoft Knowledge Base:
199841 HOWTO: Display ASP Results Using Excel in IE with MIME Types
266263 BUG: Word 2000 and Excel 2000 Display ASP Source When Using MIME Type to Stream Data
247389 IIS: How to Disable Caching of Specific MIME Types
Additional query words: 00020820-0000-0000-C000-000000000046 application/vnd.ms-excel .xla
Keywords: kbprb kbprogramming KB268016
