none
VSTO Excel add-in only working in development machine RRS feed

  • Question

  • Hi,

    I am creating a Excel 2007 VSTO COM Add-In using VSTO 2005 SE . It runs perfectly fine when I build it and run the in development computer having VS 2005.

    However, when I try to install the setup.exe or .msi file for the same addin in the client machine or Virtual PC having the following installed:

    1. VSTO Runtime - Shipped with VSTO 2005SE

    2. Office 2007

    3. .NET 2.0 Framework

    it does not seems to load .

    I have done :

    1. caspol settings to make it Fully Trusted .

    2. set vsto_suppressdisplayalert=0 and run excel.exe from cmd ......Same Results ....

    I get the following error " Not Loaded. A runtime error occurred during the loading of the COM Add-in."

    It has been over a week now that I am struggiling with the same problem . Its not only me but the entire development team is struggling with the same problem.

    Please help !!!

     

    Thursday, October 12, 2006 6:04 AM

Answers

  • Abhishek - the steps that Helmut, Pavan and Geoff have described should all help you to pin down your problem. As a minimum, you should be doing the following:

    • install Office, including the PIAs,
    • install .NET 2.0,
    • install the VSTO 2005 SE runtime,
    • run your add-in MSI,
    • setup FullTrust CAS for your add-in.

    The fact that even a simple "hello world" add-in is not working for you suggests that either you're missing one of the steps or there is something missing in your environment.

    Bear in mind that you're working with pre-release versions of both Office 2007 and VSTO 2005 SE. Depending on exactly which version of Office 2007 you're using, there could be a mismatch there somewhere. Perhaps you can confirm that you have all the right versions of the right pre-requisites.

    Another possibility is that Excel is loading some other add-in that is causing a problem, perhaps by force-loading the 1.1 CLR. When you run Excel, can you confirm that the 2.0 CLR is being loaded? You can use a tool such as Process Explorer to discover this.

    If you've checked all these, and it still doesn't work, I suggest you repair all your installs, or perhaps wait for the final release of both Office 2007 and VSTO 2005 SE (which should be very soon now).

     

    Saturday, November 4, 2006 3:06 AM

All replies

  • Hello Abhishek,

    maybe you have a programming error in your Add-in.
    Because it says there is a runtime error.

    Have you tried to put in some Debugging and tracing code and/or  try/catch blocks, messageboxes ?

    Hope this helps,

    greets, Helmut

    Thursday, October 12, 2006 6:15 AM
    Answerer
  • Before I was trying with my regular Add-in which had lots of code . Then just for testing purpose now I just have a single line of code in my new Test Addin

    private void ThisAddIn_Startup(object sender, System.EventArgs e)

    {

    #region VSTO generated code

    this.Application = (Excel.Application)Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Wrap(typeof(Excel.Application), this.Application);

    System.Windows.Forms.MessageBox.Show("Hello World");

    #endregion

    }

    Thats it . It works in my development machine but when I install this addin in Virtual PC or client machine not having VS 2005 it throws this error.

    I am not able to figure out what exactly the problem is ...

    Thursday, October 12, 2006 6:47 AM
  • Hello Abishek,

    Try it only with a MessageBox.
    Then you should see if its an Environment problem.

    when this works, you could do a try / catch block and

    log / display the Stacktrace and / or the inner exception.

    Hope this helps,

    greets, Helmut

    Thursday, October 12, 2006 6:59 AM
    Answerer
  • Hi Helmut,

    I tried the above too but no success. I don't think so that there is any problem in the code .

    If I install Visual Studio 2005 in the client machine then it starts working .Open source code in VS2005 press F5 ..excel starts up and shows this message box.

    Again If i uninstall VS 2005 and run the setu.exe for my addin it stops...May be there is some problem in the architecture of VS 2005 SE beta .

    "LoadBehavior: Not Loaded. A runtime error occured during the loading of the COM Add-in" This is the only error message I see when I go to Excel-> Addin-> Com Add-in.

    Apart from this there is no trace or log . I think its happening beofre the addin_startup .

    Thanks,

    Abhishek

     

    Thursday, October 12, 2006 8:47 AM
  • Hey Abhishek,

    Looks like you have done the add-in dev ysing VS 2005! Did you happen to take care of KB908002? If your add-in is working on a m/c that has VS 2005 but doesnt on the one which doesnt have VS 2005 then there, in all probabilites, is some dll that you are missing to re/distribute with your add-in taht VS is giving! Chk if such any dll is missing!

    Hope this helps,
    Regards,
    Pavan

    Thursday, October 12, 2006 11:01 AM
  • Hi Pavan.

    This is an Excel 2007 Addin that I am creating and testing . BTW- I have Kb9808002 installed in dev machine .

    Still no solution . Can sombody please try depolying a dummy excel 2007 addin to a virtual PC or a machine whihc doen not have VS 2005 installed and let me know if it work . Then probabaly I will follow the steps .

    Thanks in advance and really looking forward for some help on this !!

     

    Thursday, October 12, 2006 11:55 AM
  • Are you follwoing the packing instructions gives in KB908002 while building ur setup? 

    Thursday, October 12, 2006 12:38 PM
  • Yes I am doing so ...Anyways its not going to effect becauase its a 2007 add-in and not 2003 add-in.
    Thursday, October 12, 2006 1:20 PM
  • Hi,

    Sorry to hear you are having trouble.  You are going to need to back into this to see where things are breaking down.  Before we start, are you running Windows Vista on the problem machine?  If so, is your Add-in registered in HKCU and are you launching Excel with an elevated token?  Recent builds of Vista have disabled that scenario; otherwise malware could register itself as an add-in when running as user and then get elevated when the host application was launched elevated.  If that is what is happening, you just need to launch Excel normally (i.e. non-elevated).

    Assuming you aren't running Vista, the first thing to do is set VSTO_SUPPRESSDISPLAYALERTS=0 in your environment.  Then launch Excel under that environment and try again.  If there is an exception coming from us, that will allow you to see it.

    After that, you will want to start with the registry.  First find the Add-in registration under either HKCU or HKLM  (\Software\Microsoft\Office\Excel\Addins).  Locate the FriendlyName value.  Then go to HKCR and find the key that matches the friendly name.  Under that key, find the CLSID key and get the value.  Now find that key under HKCR\CLSID.  There should be an InProcServer32 key underneath.  The default value should point to AddInLoader.dll.  Verify that AddInLoader.dll exists where it is registered.  Next, check the ManifestLocation value.  Make sure the manifest exists in that location and make sure it correctly identifies the Add-in assembly and location.  If all of this is correct, then setup apparently worked.  Otherwise the problem is in your setup.

    Assuming setup worked correctly, you'll need to determine how far in the loading process you get.  The first step would be to attach a debugger to Excel (make sure you attach to debug native code) and attempt to load the Add-in.  After receiving the error, you will want to check the modules window in the debugger (Debug.Windows.Modules) and see if AddInLoader.dll got loaded.  If it did not, the first thing to do is go back to the registry and search on AddInLoader.dll.  You should find both a CLSID key and a TypeLib key.  Verify that the Add-In loader is installed where it should be.  If everything looks good, you are going to need to get your hands dirty and debug CoCreateInstance.  To set that breakpoint, type Ctrl-B to bring up the New Breakpoint dialog.  In the Function edit box, type {,,Ole32}_CoCreateInstance@20.  Set the language combo box to C and click Ok.  The breakpoint should show up as resolved in the breakpoint window.  If you don't have symbols, you can get them from our public symbol server--see http://support.microsoft.com/kb/311503.  Once you have the breakpoint set,  try loading the Add-in.  You should hit the CoCreateInstance breakpoint.  Step over it and check the return code.  Verify that you got a failure and see if the HRESULT gives you an answer.  Otherwise, you'll need to do some assembly level debugging to figure out what is going on.  The CoCreateInstance implementation is fairly straightforward.  At a high level, it will locate the passed in CLSID in the registry, find the InProcServer32 key, load the server, call _DllGetClassObject to get the IClassFactory and then call IClassFactory::CreateInstance.   You will just need to figure out where in that sequence you are getting a failure.

    Alternatively, if the Add-in loader is getting loaded, then we are either unable to create the AppDomain or we couldn't load the assembly.  The first thing to check would be the fusion log.  Run fuslogvw.exe from %ProgramFiles%\Microsoft.Net\SDK\v2.0\bin, click Settings, select Log all binds to disk, and click Ok.  Try to load your Add-in.  Then click the refresh button in the Log Viewer.  Check the log to see where Fusion is looking for things and see if that gives you any hints.  More than likely though, you never got this far--otherwise you should have gotten exceptions from the loader.  That said, do enable Common Language Runtime, Win32, and C++ exceptions in the exceptions dialog (make sure you are attached for both managed and native debugging) and try loading your Add-in.  If there are any exceptions going on, doing that will catch them. 

    Well there you have it.  An advanced course in debugging Add-in startup problems.  Hopefully that will enable you to sort out the problem.

    Sincerely,

    Geoff Darst

    Microsoft VSTO Team.

    Thursday, October 12, 2006 5:13 PM
    Answerer
  • Hi Geoff ,

    Thanks for the explanation . This was indeed one of the best answer I have seen so far to the problem and I really felt like doing an advanced course in debugging Add-in Startup problems,

    1. I checked all keys in registry and every thing is set right there .(I am not using Vista, I am creating Excel 2007 VSTO add-in)

    2. Running the fuslogvw.exe I got the following message .

    *** Assembly Binder Log Entry  (10/13/2006 @ 10:51:13 AM) ***

    The operation was successful.
    Bind result: hr = 0x0. The operation completed successfully.

    Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
    Running under executable  C:\Program Files\Microsoft Office\Office12\EXCEL.EXE
    --- A detailed error log follows.

    LOG: Found assembly by looking in the GAC.


    3. Attaching debbugger to excel doesn't not throw up any error in development machine . However I dont have VS 2005 installed in client . Its only .NET 2.0 Framework that is installed in client machine .

    Can you please help me . Just try creating a simple "hello world" addin . Make a set up and try installing the set up in a virtual machine or any machine which does not have Visual Studio 2005 installed in it . Let me know the steps if you have any success.

    Thanks again for all your help !!

    Abhishek

    Friday, October 13, 2006 5:48 AM
  • Abhishek - the steps that Helmut, Pavan and Geoff have described should all help you to pin down your problem. As a minimum, you should be doing the following:

    • install Office, including the PIAs,
    • install .NET 2.0,
    • install the VSTO 2005 SE runtime,
    • run your add-in MSI,
    • setup FullTrust CAS for your add-in.

    The fact that even a simple "hello world" add-in is not working for you suggests that either you're missing one of the steps or there is something missing in your environment.

    Bear in mind that you're working with pre-release versions of both Office 2007 and VSTO 2005 SE. Depending on exactly which version of Office 2007 you're using, there could be a mismatch there somewhere. Perhaps you can confirm that you have all the right versions of the right pre-requisites.

    Another possibility is that Excel is loading some other add-in that is causing a problem, perhaps by force-loading the 1.1 CLR. When you run Excel, can you confirm that the 2.0 CLR is being loaded? You can use a tool such as Process Explorer to discover this.

    If you've checked all these, and it still doesn't work, I suggest you repair all your installs, or perhaps wait for the final release of both Office 2007 and VSTO 2005 SE (which should be very soon now).

     

    Saturday, November 4, 2006 3:06 AM
  • I have same problem with Word 2007 Add-in. I think it's a bug.
    Add-in works only from Visual Studio.I create installation project and install Add-in on same OS   - Add-in doesn't work.

    I check
  • install Office, including the PIAs,
  • install .NET 2.0,
  • install the VSTO 2005 SE runtime,
  • run your add-in MSI,
  • How  I can  check: setup FullTrust CAS for your add-in?

Friday, December 15, 2006 3:35 PM
  •  

    Hi Andrew:

    Do you have a pointer to the fifth step in your process (setup FullTrust CAS) that can be automated to duplicate the settings that VSTO sets.  E.g. an installer class (preferred), a batch file etc.

    Thanks!

     

    Sunday, December 17, 2006 4:41 AM
  •  Geoff Darst - MSFT wrote:

    ...Assuming you aren't running Vista, the first thing to do is set VSTO_SUPPRESSDISPLAYALERTS=0 in your environment.  Then launch Excel under that environment and try again.  If there is an exception coming from us, that will allow you to see it.



    I had this same error and setting this environment variable yielded the following output:

    Could not load file or assembly 'ExecutiveCalendar, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Failed to grant permission to execute. (Exception from HRESULT: 0x80131418)

    At least I now have something to work with.  Thank you.

    - Ray
    Friday, October 19, 2007 12:55 PM
  •  

    Same problem in outlook.

     

    Any solution

    Tuesday, October 30, 2007 10:08 AM
  • OK this seems to be a persistent problem. I am developing a Project 2007 add-in using the ORCAS Beta 2 ide on a Vista machine. The add-in runs fine on my development machine and deploys fine to XP machines, but when I try to deploy to a non-development machine running Vista I get the run time error described here. I have placed a try...catch block around the Startup code but nothing is reported from that.

     

    Has anyone solved this mystery yet?

     

    Thanks

    Mike

    Friday, November 2, 2007 4:38 PM
  •  

    I've been having the same issue, Word 2007 plugin. I need to test a little more but think I have a fix, or at least the start of one. I ran my installer, got the problem "Not loaded" "Run time error" etc. I was checking the trust center in word and saw that the path to my DLLs was added when it occured to me to check the .Net permissions for the assemblies. Using the "Microsoft .Net Framework 2.0 Configuration" tool I manually increased the trust level of each of my assemblies to Full Trust. Re-enabled the add-in in Word, restarted Word and hey presto! it works.

     

    I'll need to check a little more to find out the minimum steps required, having to manually go to control panel to increase the trust level of the assemblies isn't ideal. But it's a path for people to work now, I'm sure there's some simple way of getting the installer to give adequate trust to the assemblies (assuming the install is run with high enough permission level).

    Friday, April 4, 2008 2:36 PM
  • Hiii
    Abhishek
    I read your all discussion about Excel Addins Loading problem.
    I am also working on Excel 2007 and Outlook 2003 Add ins using vb.net 2005 and i am also facing same problme in both add ins. How you solve your problme. What is the possible solution for this problem.
    Plz suggest me.
    Reply me or mail me :
    Thanx
    Mitesh Khatri
    khatrimitesh@hotmail.com
    Monday, June 9, 2008 1:24 PM
  • try installing the correct PIA on your target machine, there is an install that will take care of the PIA files for Office2007 its called o2007pia.msi
    its pretty much a silent install. try this link. http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en

    I have been doing the same kind of testing a very small skelton Addin, deployed to new computer, it failed, ran the o2007pia.msi and then reinstalled the Addin and it works.


    Monday, October 27, 2008 4:34 AM
  • Has anyone found the solution to this problem?  I notice in this thread there are very good detail tips to find the source of the problem but I don't see a confirmed solution. 
    Friday, December 5, 2008 4:52 PM
  • hotshot,

    see the sticky post titled Deploying Office Solutions in this forum.  there are a number of security steps that must be completed in order for VSTO solutions to work on end user computers.

    m.
    Friday, December 5, 2008 10:01 PM
    Moderator
  • I found a solution to this...

    When you create a new addin project the class name was ThisAddIn, for some reason the designer files were still referencing ThisAddIn when i had changed the name of the class, did a global search and replaced with the new class name, rebuilt, installed and hey presto it all worked :)
    Tuesday, March 31, 2009 4:36 PM
  • Scenario: VS 2005 creating an COMAddin for PowerPoint 2003

    I found that when the KB908002 was followed then the extensibilityMSM.msi had to be installed on the target machine.  At that point the COMAddin loaded correctly.
    Friday, July 3, 2009 2:35 PM
  • I had the same issue on my client machine and had all of the pre-requisites accounted for. It took me 2 days but finally found the issue. My setup project was adding the classid for my addin in the registry with the default registry setting of: "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll"
    Excel 2007 didn't have issue with this but I noticed when I ran a process monitor that Excel 2003 was pre-pending file system locations to it and failing. It never actually looked in %CommonProgramFiles%. If this happens to be your issue you can test it by changing the default to the exact location of the Loader on your client machine registry and then adjusting your setup project correctly if that was the issue.
    Friday, August 21, 2009 4:19 PM
  • "I had the same issue on my client machine and had all of the pre-requisites accounted for. It took me 2 days but finally found the issue. My setup project was adding the classid for my addin in the registry with the default registry setting of: "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll"
    Excel 2007 didn't have issue with this but I noticed when I ran a process monitor that Excel 2003 was pre-pending file system locations to it and failing. It never actually looked in %CommonProgramFiles%. If this happens to be your issue you can test it by changing the default to the exact location of the Loader on your client machine registry and then adjusting your setup project correctly if that was the issue."
    THANK YOU Robert Gardnet!!!!!
    That was my problem, %CommonProgramFiles% was not translated well because I set a wrong type for registry key InprocServer32\(Default), it must be of type vsdrvtEnvironmentString.


    Friday, October 23, 2009 12:10 AM
  • We have VSTO Add-in developed for Excel 2003; is it possible to load the same in Excel 2007 or do we need to rebuild it using Office 2007 interops... as of now it says it cann't load the assembly..
    LOG: Processing DEVPATH.
    LOG: DEVPATH is not set. Falling through to regular bind.
    LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

    I have both .NET 1.1 and 2.0 frameworks and VSTO for office system 3.0 runtime..

    thanks,
    Wednesday, November 4, 2009 6:53 AM
  • "Assuming you aren't running Vista, the first thing to do is set VSTO_SUPPRESSDISPLAYALERTS=0 in your environment"

    Does this mean the parameter doesn't work on Vista /Windows 7?  I'm having similar problems, and can't get Outlook 2003 to display any error messages on my Win 7 computer. I'm coding an add-in with .NET 3.5 and I've set the CAS policy to full trust.

    Friday, April 23, 2010 4:40 PM
  • "I had the same issue on my client machine and had all of the pre-requisites accounted for. It took me 2 days but finally found the issue. My setup project was adding the classid for my addin in the registry with the default registry setting of: "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll"
    Excel 2007 didn't have issue with this but I noticed when I ran a process monitor that Excel 2003 was pre-pending file system locations to it and failing. It never actually looked in %CommonProgramFiles%. If this happens to be your issue you can test it by changing the default to the exact location of the Loader on your client machine registry and then adjusting your setup project correctly if that was the issue."
    THANK YOU Robert Gardnet!!!!!
    That was my problem, %CommonProgramFiles% was not translated well because I set a wrong type for registry key InprocServer32\(Default), it must be of type vsdrvtEnvironmentString.

     

    This is true for Excel 2003 VSTO add-ins, which use this registry key. Versions post 2003 don't use it.

    We solved the issue in two ways:

    • Converted the add-in from VSTO addin to Office Shared addin
    • Uninstalled Microsoft .NET Framework 1.1
    Friday, June 3, 2011 1:29 PM