Export (0) Print
Expand All
4 out of 9 rated this helpful - Rate this topic

Troubleshooting in Office at Run Time

If error messages from Microsoft Office 2003 appear while you are building your solution, or your end users report error messages, it might be due to one of the following common issues.

This problem causes the following error message to be displayed:

The common language runtime could not be loaded by <application>. Contact your administrator for further assistance.

The version of the Microsoft .NET Framework on the end user's computer must be the same as or later than the version on the computer that was used to develop the solution. For more information about installing the .NET Framework and the common language runtime, see the Microsoft .NET Framework downloads page (http://msdn.microsoft.com/netframework/downloads/).

This problem causes the following error message to be displayed:

The custom macros in this document require the common language runtime, version 2.0, to be installed. Contact your administrator for further assistance.

Custom macros in this instance means the managed assembly. The end user might have a version of the Microsoft .NET Framework installed that is not compatible with your solution. You must install a version of the .NET Framework on the user's computer that is the same as or later than the version you used to develop your solution. Installation can be side-by-side with the existing version. For more information about installing the .NET Framework and the common language runtime, see the Microsoft .NET Framework downloads page (http://msdn.microsoft.com/netframework/downloads/).

This problem causes the following error message to be displayed:

The current .NET security policy does not permit <assembly> to run from the folder <path>. Do not change the security policy in your computer. The .NET security policy is controlled by your administrator or the developer who wrote the custom macros. You can still edit and save the document. Contact your administrator or the author of this document for further assistance.

Custom macros in this instance means the managed assembly. The assembly is not trusted and might be harmful. If you are sure that the assembly is safe, you must grant it full trust in the user's .NET security policy before it will run. For more information, see How to: Grant Permissions to Folders and Assemblies.

This problem causes the following error message to be displayed:

The current .NET security policy does not permit <document> to load custom macros. Do not change the security policy in your computer. The .NET security policy is controlled by your administrator or the developer who wrote the custom macros. You can still edit and save the document. Contact your administrator or the author of this document for further assistance.

Custom macros in this instance means the managed assembly. The main possibility is that the document was opened from an untrusted location or from an e-mail attachment, and might be harmful. If you are sure that this document is safe, save it to the user's computer and then open it. Once it is saved on the computer, the document is in the My Computer zone, which has full trust. If the document is an e-mail attachment, it is in the Internet zone, which does not have full trust.

Another possibility is that the correct version of the Microsoft .NET Framework was on the computer at one time, but was removed before running the solution. If the user installs the .NET Framework versions 1.0 and 2.0 side-by-side, then removes version 2.0, this security message appears instead of the message stating that the required version of the .NET Framework is not installed. To run the solution, you must install .NET Framework 2.0.

For more information, see Security Requirements to Run Office Solutions.

If you receive a security exception when you are certain that the main project assembly has full trust, it might be the case that a referenced assembly is attempting to perform an action that it does not have the required permissions to complete. You must grant referenced assemblies any required permissions manually.

When a project is built on a developer computer, all referenced assemblies that are in the project's output folder are granted Execution permissions. Only the main project assembly is automatically granted full trust.

This problem causes the following error message to be displayed:

The customization assembly could not be found or could not be loaded. You can still edit and save the document. Contact your administrator or the author of this document for further assistance.

To resolve this error, try the following options:

  • Check that the user has access to the assembly location and that the named assembly exists. For more information, see Assemblies in Office Projects Overview.

  • If the assembly is available, check whether Word or Excel is running a customization, such as an add-in, smart tag, or smart document, that explicitly loaded a version of the .NET Framework common language runtime (CLR) that is incompatible with the Visual Studio 2005 Tools for Office runtime. To resolve the issue, disable any customizations that explicitly load a version of the .NET Framework CLR that is earlier than 2.0.

    A running application can load only one instance of the .NET Framework CLR. The Visual Studio 2005 Tools for Office runtime requires the .NET Framework 2.0 CLR. If a customization forces Word or Excel to load an earlier version of the .NET Framework CLR, then Visual Studio 2005 Tools for Office solutions will fail to load.

  • Check whether an unhandled exception in the customization assembly is preventing the assembly from loading. Debug your solution with the debugger set to break on common language runtime exceptions, or with the Break when exceptions cross AppDomain or managed/native boundaries option selected in the Options dialog box. For more information, see How to: Handle Errors in Office Projects and General, Debugging, Options Dialog Box.

This problem causes the following error message to be displayed:

The custom macros in <project> could not be initialized correctly. You can still edit and save the document. Contact your administrator or the author of this document for further assistance.

Custom macros in this instance means the managed assembly.

Some of the reasons for this error message include:

  • The main Office project assembly is partially trusted. For example, if you create a project on a network share that only has Intranet Zone permissions in machine-level security policy, you get this message even if you granted it full trust at the user level. The assembly is loaded with no security warning, but because the machine-level policy is more restrictive, the assembly does not have the required permissions to access the Office object model (which requires full trust) and the assembly is not initialized. A network administrator must grant full trust at the machine level if you are working on an assembly that is not stored on your local computer. For more information, see Security Requirements to Run Office Solutions.

  • The primary interop assembly for a referenced COM component is not installed in the global assembly cache prior to adding the reference. Visual Studio generates an interop assembly that might not work fully in all cases, and it places the assembly in the project directory instead of in the global assembly cache.

To reference the correct interop assembly

  1. Find all references in your project to COM components (such as Office applications) that have the Copy Local property set to True.

  2. Right-click the reference, and then click Remove on the shortcut menu.

  3. Run Microsoft Office Setup to install the primary interop assembly that is missing. For more information, see the technical article "Installing and Using the Office 2003 Primary Interop Assemblies" (http://go.microsoft.com/fwlink/?LinkId=73424).

  4. Open your project in Visual Studio and add a new reference to the component. For more information, see How to: Target Office Applications Through Primary Interop Assemblies.

This situation causes the following message to be displayed:

The custom macro in <path> is not available offline. Do you want to go online to download the customization? This may affect other programs running on your computer, such as Internet Explorer.

Custom macro in this instance means the managed assembly. This message is shown when the computer is in offline mode and there is not a copy of the assembly in the cache. To work offline, the following conditions must be met:

  • The assembly must be located on a Web server.

  • The assembly must be accessed through an HTTP or HTTPS path in the custom properties.

To cache an assembly that meets the above criteria, you must go online and open the Office document to download a copy of the assembly at least once. The assembly is then available for offline work. For more information, see Offline Model for Office Solutions and How to: Deploy Solutions for Offline Use.

Other programs might be affected because there is only one offline and online mode for the computer. If you select Work Offline on the File menu in Internet Explorer, all applications go offline.

This situation causes the following message to be displayed:

The custom macro in <path> is not available online, but a local copy is available. Do you want to go offline and use the cached copy? This may affect other programs running on your computer, such as Internet Explorer.

Custom macro in this instance means the managed assembly. This message appears when your computer is not connected to a network, or the network is down, and the computer is in online mode. Clicking OK causes your computer to go into offline mode and use the cached copy of the assembly. You must set your computer to offline mode to be able to use a cached assembly, either by clicking OK on this dialog box or by selecting Work Offline on the File menu in Internet Explorer. For more information, see Offline Model for Office Solutions and How to: Deploy Solutions for Offline Use.

Other programs might be affected because there is only one offline and online mode for the computer. If you set your computer to offline mode, all applications go offline.

This problem causes the following error message to be displayed:

Could not load type <projectname> from assembly <assemblyname>.

This message might appear if you obfuscate the solution code. Obfuscating the code changes the names of all of the classes. However, the original class names are referenced in the manifest, and the obfuscator does not change the manifest.

To avoid this error, add the names of the worksheet and workbook classes to the obfuscator's list of classes not to rename.

If the locale selected in an end user's regional settings does not match the installed language for Microsoft Office Excel 2003, he or she might receive the following errors when calling certain Excel methods and properties:

A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll.

Additional information: Exception from HRESULT: 0x800A03EC.

-or-

A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in ExcelProject.dll.

Additional information: Old format or invalid type library.

For details on correcting this problem, see Globalization and Localization of Office Solutions.

Reasons that the code does not run and no error messages appear include:

  • The Office primary interop assemblies are not installed in the global assembly cache, possibly because the .NET Framework 2.0 is not installed on the computer, or the assemblies are marked Not Available in Office setup.

  • The version of Word or Excel being used does not support Visual Studio Tools for Office solutions. End users must install Word and/or Excel from an edition of Microsoft Office 2003 that supports Visual Studio Tools for Office. For more information, see How to: Install Visual Studio Tools for Office.

  • The document is opened from an HTTP or HTTPS location and the Browse in same window option for .doc or .xls files is not selected in Windows Explorer. This option is used by Internet Explorer to determine whether the document is hosted inside the current window or in a separate window. If the document is hosted in a separate window, the customizations do not load and run. To access the Browse in same window option for a Word or Excel document, open Windows Explorer, click the Tools menu, and then click Folder Options. On the File Types tab, select DOC or XLS in the list of file types, click Advanced, and verify that Browse in same window is selected.

For more information, see Debugging in Document-Level Projects.

A Microsoft Office 2003 solution created with managed code extensions runs even if the Security setting in the end user's Office application is set to High. This is because managed assembly code security is governed by the Microsoft .NET Framework, and not by Microsoft Office Word 2003 or Microsoft Office Excel 2003. However, there are several ways to open a document or workbook that contains managed code extensions without running the assembly code. For more information, see How to: Open Office Solutions without Running Code.

If Excel or Word quits unexpectedly after a user triggers an event on a modeless form, check to see if there are any places where unhandled exceptions could be raised in the code. Add error handling to prevent possible loss of data.

There are several possibilities to check for if an Outlook add-in does not load correctly:

  • If Microsoft Office Outlook quits unexpectedly or an error occurs while an add-in is initializing, Outlook might disable the add-in. For more information, see How to: Re-enable an Application-Level Add-in That Has Been Disabled.

  • An Outlook add-in can fail to load if the add-in manifest file is not located in the same directory as the add-in assembly. If you deploy the manifest file to a different directory, you must update the codebase attribute of the asmv2:installFrom element in the add-in manifest file to point to the location of the add-in assembly.

  • Outlook might be running an add-in that explicitly loaded a version of the .NET Framework common language runtime (CLR) that is incompatible with the Visual Studio 2005 Tools for Office runtime. To resolve the issue, disable any add-ins that explicitly load a version of the .NET Framework CLR that is earlier than 2.0.

    A running application can load only one instance of the .NET Framework CLR. The Visual Studio 2005 Tools for Office runtime requires the .NET Framework 2.0 CLR. If an add-in forces Outlook to load an earlier version of the .NET Framework CLR, then add-ins created using Visual Studio 2005 Tools for Office will fail to load.

You can get additional troubleshooting information by setting environment variables that make Visual Studio Tools for Office display detailed error messages and write all actions to a log file. For more information, see Debugging in Application-Level Projects.

Do not use the COM Add-Ins dialog box to install Outlook add-ins created by using Visual Studio Tools for Office. Use the deployment project included in the Outlook project template. Outlook add-ins use a proxy .dll file, named AddinLoader.dll, to extend Outlook's functionality. The proxy enables the managed assembly to communicate with Outlook through COM. For more information, see Deploying Application-Level Add-ins.

If your Outlook add-in creates a custom property page for the Options dialog box of Outlook or the Properties dialog box of an Outlook folder, you must explicitly make the custom property page visible to COM (by default, the assembly is not visible to COM). Otherwise, your add-in will fail create the custom property page, and you might receive a COMException while debugging your add-in.

There are two ways to make a custom property page visible to COM:

  • Add a ComVisibleAttribute to the class that implements the custom property page in your project. For information about applying attributes to classes, see Applying Attributes.

  • Use Visual Studio to make your entire add-in assembly visible to COM.

    To make the add-in assembly visible to COM using Visual Studio

    1. In Visual Studio, right-click your project in Solution Explorer, and then click Properties.

    2. Click the Application tab.

    3. Click the Assembly Information button.

    4. Select the Make assembly COM-Visible check box.

    5. Click OK.

If you create an event handler for the Quit event of the Microsoft.Office.Tools.Outlook.Application class in an Outlook add-in, the event handler will never run. When you close an instance of Outlook that is running an add-in created by using Visual Studio Tools for Office, the add-in is unloaded before the add-in receives the Quit event. As an alternative, you can put code that you want to run when Outlook closes in the ThisApplication_Shutdown event handler in your project. For more information, see Outlook Add-in Project Template.

When you call the Close method of the Excel Workbook object or the Word Document object from a modeless form, the application might quit unexpectedly. All open documents or workbooks will close and data might be lost. If Microsoft Office Outlook uses Word as its e-mail editor, all open e-mail messages might also close. This might also occur if you display Windows Forms or message boxes while handling the System.AppDomain.DomainUnload event.

To work around this problem, do not call the Close method from a modeless form or in an event for a modeless form. Instead:

  • Use modal forms (for example by using ShowDialog instead of Show) if you must close the document from the form.

  • If you must use a modeless form, ensure that the modeless form is closed and that your form references are completely destroyed before attempting to close the document or workbook. For example:

    SampleForm form1;
    
    private void OpenForm()
    {
        form1 = new SampleForm();
        form1.Show();  // Show form modelessly.
    }
    
    private void ForceShutdown()
    {
        // Completely close the form if it is still running.
        // Note that hiding the form might not work by itself.
    
        if (form1 != null)
        {
            form1.Close();
            form1.Dispose();
            form1 = null;
        }
        object saveChanges = Word.WdSaveOptions.wdSaveChanges; 
        this.Close(ref saveChanges, ref missing, ref missing);
    }
    
    

For information about passing the parameter missing in C#, see Understanding Optional Parameters in COM Interop.

If you show the SaveAs dialog box inside of the DocumentBeforeSave event handler of ThisDocument and set the Cancel parameter to false, the application might quit unexpectedly. If you set the Cancel parameter to true, an error message appears indicating that Autosave has been disabled.

If you split a worksheet window that contains Windows Forms controls, the controls might not behave similarly in both windows. For example, if you run code to change the BackColor property of a TextBox on a worksheet, the change might appear in only one of the windows.

Some methods and properties in Excel require that you pass them a native Office object. If the ExcelLocale1033Attribute attribute is set to false, and you pass in a host control that is based on the native Office object, it throws an InvalidCastException. You can use the InnerObject property of host controls to pass the underlying native Office objects to these methods and properties. For more information about localization issues in Excel, see Formatting Data in Excel with Various Regional Settings.

If Excel displays a modal dialog box while the dataset that is bound to a ListObject is being updated, the data binding of the ListObject fails. When the ListObject loses data binding, it raises the DataBindingFailure event. To bind the ListObject to the data source again, handle the DataBindingFailure event and call the SetDataBinding method.

If you double-click a deployment manifest, the following message is displayed:

Cannot continue. The application is improperly formatted. Contact the application vendor for assistance.

Unlike ClickOnce deployment, you cannot run a Visual Studio Tools for Office solution by double-clicking the deployment manifest. To run the solution, open the Office application. For Word and Excel, open the solution document inside the application. Alternatively, you can double-click the document file.

For more information about deploying Visual Studio Tools for Office solutions, see Deploying Document-Level Customizations and Deploying Application-Level Add-ins. For more information about deployment manifests, see Deployment Manifests for Office Solutions.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.