I have an office add-in (vsto) that has been working fine for ages.
It launches perfectly, runs nicely no problem, but this is only when debugging from visual studio.
If I now take the files from my bin\debug and move it to another folder, then I register the released version
c:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe "C:\Program Files (x86)\MyPlugin\MyVSTO.dll"
it registers correctly, but will not load in office.
I have tried retricking the registry setting "LoadBehavior" setting it back to 3, but no luck.
office keeps complaining about my add in with the error
"Not loaded. A runtime error occured during loading of a com add in"
So it seems like it is dying when trying to launch. I though there was a missing dll or something, but no such luck, every library i need is in the folder.
This is the exact same machine so shouldnt be a dot net issue
fyi
This is done in C# 4.0 using netOffice
You can not install an Excel add-in using REGASM because it does not setup all required information; you need to deploy your add-in as per MSDN office deployment guidelines, you have two choices:
Click once
Windows installer
Note: VS actually installs the Add-in for you by setting the right information In Excel and the registry, so that you do not need to deploy the add-in manually for every new build.
Related
I developed an outlook plugin using C# and Visual studio Outlook addin template, that retrieves data from databases and generates a report off of the data.
Plugin works perfectly fine on my local machine. But when I distribute the plugin as an executable to the users, it does not work on the user's machine.
Meaning the addin is not checked by default and even if I check it manually, it does not show up on outlook in the addin bar.
I am unable to figure out if its due to the certificates or anything else.Do I need to install any certificates on the users machine ?
Could some one please help me out ?
EDIT
I right click on the solution file in solution explorer and publish to a folder to generate the setup.exe . My other team mate uses the same steps with the same project checked out of perforce and publishes a setup.exe. Now, his plugin works as expected on the user's machine and mine doesnot work (mine works only on my machine). So, I am not able to figure out what the difference is. Because we both are using the same framework (4.0) and VS (VS 2010 premium).It has something to do with the my machine. not sure if I am missing any installation
Did you have a chance to check out the Trust Center settings on the problematic PC? Are the VBA macro settings applied to COM add-ins? Is the Office application configured to load only signed add-ins?
Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.
Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.
Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.
Read more about that in the How to: Re-enable an Add-in That Has Been Disabled article.
Also you may find the Troubleshooting COM Add-In load failures article helpful.
Hope the following steps will help you solve this problem. I assume you are using Outlook 2013 or 2010.
Run the deployed setup with administration rights.
If it is not shown under Add-ins, again open the setup folder and double click on the correct .vsto file then select install.
If you can see your add-in among others, and is not functioning, it means your add-in is disabled. To enable it go to File -> Slow and Disabled Add-ins, and you should see your add-in on the pop-upped window. Enable it.
Edit:
If your plug-in is shown in Disabled Add-ins try applying the following steps:
Enable your plug-in by File -> Slow and Disabled Add-ins, and you should see your add-in on the pop-upped window. Enable it.
Right click on your add-in bar and select Customize the Ribbon.
Then on the pop-upped window, choose All Commands from the left hand side combo box. You should be able to find your command in the list box.
When you find your command click on the Add button between the lists. This will add your command to the chosen category on the right hand-side list. Then click OK.
Your command should appear under the chosen tab.
How are you deploying the add-in? You need to be sure you have configured the installations settings so when you execute the installer MS Outlook knows were to find it and all of its installations components.
In my example I am using MS Project, Visual Studio 2012 with Install Shield.
Below is an example of the registry settings I use for my add-in. You will notice I have configured the manifest to point to installation directory and points to vstolocal.
You will also need to add your .vsto file to your build when constructing the installer.
I have built an Excel 2010 add-in for a customer, using C# and Visual Studio 2010. There's no UI requirement, just UDFs that are callable from the worksheet and from VBA. The same DLL contains an Automation add-in (for the worksheet functions) and a VSTO COM add-in (to provide VBA access to the add-in functions). It has 32-bit and 64-bit builds, and I also built a WiX installer (MSI) for it, also in 32-bit and 64-bit versions.
The sources for this were many and varied, and mostly on StackOverflow (see this for examples) but it has been working fine up to the last release I sent out, about 27-Sep-2014. Since then the only change I have made was to switch from using a pfx-based code signing file to a .snk-based strong name key (for reasons I won't go into because they are peripheral to the issue and anyway I have reverted back to using PFX code signing now). The add-in uses other class library DLLs that are part of the VS2010 solution and are shipped in the installer. The WiX project has not changed in any way.
Recently I built and sent out another release because of minor changes to one of the included DLLs. The customer (using Excel 2010 32-bit) reported that after installing this, Excel can no longer see the UDF names in the Insert Function Wizard, and if they are typed into a cell they just evaluate to #NAME?. If they revert to the previous installer I sent them, that still works.
I tried the new 64-bit installer on my own development machine (Excel 2010 64-bit) and see the same effect. However if I then rebuild the solution in VS2010 on this same machine, Excel can see the names again. (Whether Excel is run from within or outside Visual Studio). Uninstall/reinstall via the installer (or repair) - names gone again. I have tried doing images of the Registry before and after the VS2010 rebuild, but all that seems to change is the location of files from the installed directory to the build directory. The DLL files themselves (and all the GUIDs, TLB etc) are all exactly the same. The UDFs can still be called from VBA via the COM add-in.
I can't post the code as there is too much, so my next step is to build a minimal add-in and installer using the same principles but with only one UDF and no extra DLLs, to see if this issue is reproducible. If it also has the problem I'll post it here. In the meantime can anyone provide a clue as to what could be causing this? What mechanism does Excel use to gain access to the function names in a loaded automation add-in?
I have made an Excel Add in (Ribbon).
When i run the .vsto and install it, i've one installation under Programs in Windows.
But, when I open my Excel program, another installation appears in the Programs-list.
Why is that and it shouldn't be like that right?
Update:
I notice in Application I have set Target framework: ".NET Framework 4 Client Profile"
and in Publish - Prerequisites it adds a Microsoft .NET Framework 4 Client Profile(x86 and x64), has that anything to do with it?
This can happen when you install the VSTO on your development computer. This is because when debugging the VSTO it will get installed though it won't show in the Programs & Features list. The VSTO will remain installed even after debugging is stopped. Even when performing a proper installation, remnants of the debugged VSTO will remain in the registry.
I've found the best way to work around this (though not ideal) is to manually remove the registry key at this location before performing a proper installation:
HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\[YOUR VSTO PROJECT NAME]
Because maybe in configuration you have set the application to update itself automatically.
So after Excel startup, it tryes to auto-update.
Is it possible?
It is very common to find two instances of the same add-in on your Excel application in a development machine. Since you must be building that add-in code inside your IDE before publishing or making a setup project build.
Whenever Excel starts it automatically detects the add-in manifests that are present on your computer.
Since you also installed your add-in your machine now has two locations where it finds your add-in one in your project folder and another at the location where you have installed the add-in.
So excel will, on its own add two add-ins because it found two add-ins, as simple as that.
And it has nothing to do with your Publish pre-requisites and Target framework.
You can simply go to FIlE->Options->Add-Ins-> over here in the window you'll find a Drop down with the label saying "Manage", in that select COM Add-ins and click on 'GO'.
Now in the window that opens, you'll find both your plug-ins listed there, you can remove the plugin that you do not want to see on your Excel app.
But, anyways the next time you build your excel add-in and start Excel it will again add that add-in automatically to your Excel app.
So it would be better not to install the add-in which you make on your machine until you want to test the installer or something like that.
I've created a simple Outlook add-in and I can't seem to get an install package together correctly.
Specs: Visual Studio 2010 (C#), .Net 4.0, Office 2007
The add-in works perfectly in my development environment and appears to install successfully with the setup file I created (using http://blogs.msdn.com/b/mcsuksoldev/archive/2010/10/01/building-and-deploying-an-outlook-2010-add-in-part-2-of-2.aspx).
The problem is once Outlook is reopened after the install, the Add-in is nowhere to be found. It shows up as an "Active Application Add-in", yet it's not available on the ribbon like it is when I run the add-in through Visual Studio. Do I need to hard-code it in the ribbon somehow? Also, I noticed if I manually open the VSTO file and install it, all seems perfect again. Thanks for your help!
There's a lot that can go wrong with a VSTO installation. Here's what I think may be going wrong in your situation:
If you're installing the add-in on your development machine then try a different machine instead. Debugging the add-in on your development machine sort of registers the add-in with Office via some registry keys but that registration info doesn't get cleaned up. (You can certainly clean those keys up yourself and then try your add-in's installer but I recommend a clean machine just in case.)
Try the installation without |vstolocal in the manifest path. I know Microsoft recommends including it but in my own experience it prevented my add-in from loading, and using a normal path fixed the problem.
If you're installing to Office 32-bit on a 64-bit machine then you'll need to write your registry keys to HKEY_LOCAL_MACHINE\Software\ Wow6432Node\Microsoft\Office...
Consider installing your add-in using VSTOInstaller.exe instead of manually writing the registry keys. (I tried to write the registry keys myself but Microsoft's own documentation -- rather, random blog posts -- for doing this is not thorough enough and sometimes just plain incorrect and misleading.)
I have developed an Add In for Word 2003 in C# using VSTO 2005 SE. The Add In creates a button near the Help button called International Projects. When the Add In is loaded, it gets some data from a Sharepoint 2007 Library and based on that data, when a button in the International Projects menu is clicked, it generates some custom properties for the running document. On the machine that I developed the Add In it work perfectly. I tried to create a Setup Project in my solution so that I could install the Add In on other machines. I created the Setup using the instructions from here: http://msdn.microsoft.com/en-us/library/cc136646(v=office.12).aspx , http://blogs.msdn.com/b/vsto/archive/2008/12/17/deploying-office-2003-solutions-with-windows-installer-mary-lee.aspx and many other sites like these. The problem that I am having is that when I run the setup on a user machine, the setup runs fine, there are no erros in the logs or event viewer, the registry looks to be fine, the files are copied at the address specified in the installer, the add in appears in Add/Remove programs but it doesn't load when starting Word and is not present in Word as a COM Add In. The SetSecurity project I took it from the VSTO 2005 SE Runtime Sample V3, add it to my solution and insert the output in my setup project. I still believe that it is a trust issue between Office and my add in. The PIA for office is present in assembley and the VSTO seams to be installed corectly. I also created another project that simply shows a MessageBox on startup and shutdown and that installs and works fine on the user machine. Some strange things I noticed are the fact that when I build my project there is no .vsto file created but there is a .vsto.manifest file, I read on a forum that vsto runtime might try to use .net 1.1 instead of 2.0 when both are installed, but i installed a patch to solve that and one more that visual studio 2005 might have some problems and I found and installed a patch for that also, but none of this solved my problems. I have been working and trying all sorts of solutions for the past two weeks but without any result. Have you got any experience with creating setup for office 2003 Add ins? If someone does, please help me!
Thank you!
I don't envy you - I haven't had to deploy a 2003 add-in in a while, and I can't say I miss these days.
It's not an answer per se, but I noticed that the MSDN link you provide refers to Office 2007; this post, which is specific to Office 2003, may be useful:
http://msdn.microsoft.com/en-us/library/aa537179(office.11).aspx
I remember running into some issues with Excel 2003 add-ins, maybe you'll also find ideas in some of my older posts like this one: http://clear-lines.com/blog/post/VSTO-add-in-with-multiple-assemblies.aspx
Good luck!