Part I - Deployment of Office-based Applications(VSTO)

Issue

Create a simple VSTO project, deploy to localhost. If you transfer these files to a computer that has never had Visual Studio 2005 installed, open the workbook, delete Sheet1, then save the workbook under a new name, opening the workbook results in an error that the customization assembly cannot be found.

Resolution

One possible workaround that the you may be able to employ is to rename Sheet1 so that it has a unique name that is not likely to be reproduced and then set the XLSheetVisibility property of this sheet using VBA code so that it is set to xlSheetVeryHidden.By hiding the worksheet in this fashion it would make it more difficult for the client to delete this worksheet from the workbook. The problem as originally understood from the repro steps was that if the user deleted Sheet1 from the Excel workbook that was part of a VSTO solution that once they saved, closed and then reopened the workbook they received the error that the "Customization assembly could not be found or could not be loaded". Based on the description of the problem and as a result of tests if the user was to delete Sheet2 or Sheet3, given the workbook that was provided, then the problem does not occur and the VSTO code successfully loads.So by renaming and hiding Sheet1 from the user it would be less likely that they would delete this sheet and thereby prevent the scenario which results in the error while still allowing the VSTO code to execute. An assumption is made that there is no code contained within the Sheet1 class and/or no .NET controls residing on Sheet1.

It is often recommended that users do not delete sheets from a workbook that is part of a VSTO 2005 solution.

Another way you could do it is to follow the following

There may be another option which would prevent the error from occurring.

If the "Trust access to Visual Basic Project" option is enabled within Microsoft Excel then if the user deletes Sheet1 and there is no code behind or controls on this sheet they should be able to save, close and then reopen the workbook without receiving the error and the VSTO code should still execute.I would also indicate that changing this setting could pose a potential security hazard.By enabling this setting you are allowing macros or automation code to have access to the core Visual Basic objects, methods, and properties which could potentially allow malicious code to be inserted into a workbook and then be executed when the workbook is opened.

For more information please see the url below.http://office.microsoft.com/en-us/assistance/HA011403191033.aspx