victtim

Hi,

I have upgraded a Excel VSTO 2003 solution to VSTO 2005. Now, I am about to deploy this to my end-users. However, I need to automatically migrate the existing Excel workbooks created which refer to the 2003 Solution (via _AssemblyName0 and _AssemblyLocation0 custom properties) to use the new 2005 solution.

I realize this involves embedding a Runtime Storage Control activeX component within the Excel document. Therefore, I employed a technique provided by MS as part of a solution called ApplicationManifestEditor. Essentially, it tries to add the Runtime Storgage Control to a document by using the ServerDocument.AddCustomization(...) method. Unfortunately, when I try this methodology I get an COMException as shown below.

The parameters I am passing to the AddCustomization method are:
documentPath = "C:\MyDirectory\OldExcelWorkbook.xls"
assemblyName = "C:\MyVSTO2005Solution\MyAssembly.dll"
manifestPath = ""
applicationVersion = "1.0.0.0"
makePathsRelative = true / false (tried both).

Could you please assist me in resolving this issue

Thanks,

Tim

System.Runtime.InteropServices.COMException (0x80040407): Exception from HRESULT: 0x80040407\r\n at Microsoft.VisualStudio.Tools.Applications.Runtime.IAppInfoDocument.SetDocument(String fileName, Byte[] bytes, FileAccess access)\r\n at Microsoft.Office.Tools.OfficeAppInfoDocument.GetOfficeDocument()\r\n at Microsoft.Office.Tools.OfficeAppInfoDocument.EnsureDocument()\r\n at Microsoft.Office.Tools.OfficeAppInfoDocument.WriteItem(String element, String id, Byte[] item)\r\n at Microsoft.VisualStudio.Tools.Applications.Runtime.AppInfo.WriteManifest(IAppInfo appInfo, String manifest)\r\n at Microsoft.VisualStudio.Tools.Applications.Runtime.Customizer.CustomizeDocument()\r\n at Microsoft.VisualStudio.Tools.Applications.Runtime.Customizer.Customize()\r\n at Microsoft.VisualStudio.Tools.Applications.Runtime.ServerDocument.AddCustomization(String documentPath, String assemblyName, String deploymentManifestPath, String applicationVersion, Boolean makePathsRelative)\r\n at ApplicationManifestEditor.ApplicationManifestEditor.AddCustomization(String fileName) in D:\\Data\\Visual Studio Projects\\ApplicationManifestViewer\\CS\\ApplicationManifestEditor\\ApplicationManifestEditor.cs:line 504" string




Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

Douglas H. Troy

This might be the problem:

If you are using VSTO SE, you will need to open the ApplicationManifestEditor solution, remove the existing reference to the VSTO, re-add it and then rebuild the solution.
Note: you may not have to remove the VSTO reference, you might be able to just open the solution on machine with VSTO SE and rebuild it, but don't "hold me to that".

The existing ApplicationManifestEditor is compiled against the original VSTO.







Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

Richard Cook - MSFT

Tim,

First of all, do you have the VBA project system enabled You can check this in Excel 2003 by opening Excel and clicking on the "&Tools | &Options..." menu command, selecting the "Security" tab, clicking "Macro &Security..." and checking that "Trust access to &Visual Basic Project" is checked. If you have successfully created and built a VSTO 2005 solution on the machine in question this should already have been selected for you, but it is worth checking it manually.

If the VBA project system is not enabled, try enabling it and running the server document code again. If VBA project is enabled already or the server document code continues to fail, please create a new empty Excel workbook, save it to the file system and run the server document code against this file. Does this fail also If so, could you please supply the error code and call stack. If not, please let me know.

Best regards, Richard.

SDE Visual Studio Tools for Office





Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

victtim

Richard / Douglas,

Thank you both very much for your help. I re-installed VSTO Runtime (and .NET 2.0 Fx) on my machine and this seemed to fix the problem (magically) :-)

I apologize for the late reply - I had expected that I would be "alerted" when someone responded to my post but that never happened. Lesson Learned - keep checking the post.

Okay, now I have the ApplicationManifestEditor working. However, I am trying to find a more "transparent" way of migrating the older document (created with the VSTO 2003 solution).

Here's what I envision

1. User opens the Older Document

2. *Somehow* I intercept the document before the OTKLOADR checks it for customization

3. Once intercepted, I check to see if it is referencing the VSTO 2003 solution,

4. If true (i.e. it is using VSTO 2003 solution) --- I modify the custom properties of the document to point to the VSTO 2005 solution (using the ApplicationManifestEditor methodology)

4a I close the document, and re-open it. (This time the VSTOLoader instead of the OTKLOADR will link the document to the automation assembly)

5. Else - Do Nothing.

The fuzzy part is step 2. To do this, I thought I could potentially use a Excel Add-In which loads when EXCEL.EXE Starts up. (I.e. - an XLA that is loaded into the XLSTART folder).

Do you think this would work Or am I way off, and simply clueless

I really appreciate your guidance.

Thanks,

Tim






Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

Douglas H. Troy

Why not write an external "upgrade" utility that just updates all the current documents your client has Why even mess with that whole: "Open document, intercept before OTKLOADR, etc..."

Since you know you want to migrate these documents ... just migrate them outside of Excel and everything else ...

Just a thought.





Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

victtim

Hello Douglas,

Yes, that was my initial thought as well - to use an external application (maybe in terms of a Windows Service) to perform the AddCustomization. However, the short-comings of this method was that the external updater program would have to update the documents before they are opened. Therefore, it would may have to run continuously in the background and scan through the harddisk to update the files. Alternatively, the user may explicitly launch this updater program to convert the document.

Either of these methods seemed either too non-transparent. Essentially I wanted to be able to do what Visual Studio 2005 does when you try to open a VS 2003 Solution. The "Conversion Wizard" launches when the *.sln file is opened.

Similarly I want my conversion utility to launch when the user opens an office automated *.xls file.

So instead I used the approach of Updating the assembly that the document created using VSTO 2003 solution points to so that it performs the conversion. This seemed to work well.

Here's the solution:

1. User opens the VSTO 2003 Excel Document

2. OTKLOADR links the document to the original assembly (VSTO 2003).

3. The original assembly closes the Workbook, performs the AddCusomtization, and then re-opens the document.

4. When the document re-opens, the VSTO Loader (instead of the OTKLOADR) links the document to the new assembly (VSTO 2005)

Hope this helps anyone else who runs into this issue.

Douglas - I will mark your answer as the "Accepted Answer" as far as the initial probem goes.

Thank you both very much for all your help!

Tim






Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

Richard Cook - MSFT

This sounds like a good solution. Due to VSTO's architecture the document is loaded and the customization executed well before the add-in would see a DocumentOpen event so it would not be possible to update the document in place.

Richard.





Re: Visual Studio Tools for Office ServerDocument.AddCustomization throwing COMException HRESULT: 0x80040407

victtim

Hi Again,

From what I understand, the root cause of this AddCusomtization exception is that the Microsoft.VisualStudio.Tools.Applications.Runtime.DLL ("VSTO Runtime DLL") used in the ApplicationManifestEditor was compiled against VSTO instead of VSTO SE. And, repairing VSTO SE seems to resolve the problem.

Question:

1. Does anyone know what exactly goes wrong in the VSTO SE that it needs to be repaired

2. Is there a "VSTO Runtime DLL" that was compiled against VSTO SE so that this version "incompatibility" issue does not occur

Thanks in advance,

-Tim