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?
Related
I have built an Excel Add In using Excel DNA and C#. I am able to build the app thru Visual Studio 2017 by setting it to Release and build. As of now, I distribute the excel add in by going to the release folder and copying the .xll file and pasting it to the users add in path on their machines. This process works but as you can tell not really professional. In addition, I am also using Azure to host winforms applications. My question, is what is the best way to distribute and possibly install the .xll file on users machine. (The install is really copying over the previous .xll file). Can I use azure to do this (Just hold the .xll file)? Or do I need to go thru Jenkins or similar type application.
A common approach to deploy Excel-DNA add-ins is by creating an installer that gets downloaded and run by the user.
https://github.com/Excel-DNA/WiXInstaller
https://jiripik.com/2017/02/25/use-advanced-installer-excel-dna-project/
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.
I just upgraded (if you can call it an upgrade) from VS 2010 to VS 2012. They are now forcing you to use installshield Essentials, which is rubbish and you need to sacrifice a chicken, whilst performing satanic rituals to get it to work.
So my question, can I install the ADDIN manually? I know what registry entries are needed. I ask because I want to know if I can build the addin and then get a third party installer and use that.
Also the MS addins seem to use VSTO, can I not use a simple DLL? I ask because I see my NOD32 antivirus addin is a simple DLL.
Yes, it is enough to include in the installer the DLL, VSTO manifest file and create the registry entries as documented. This way you can create the installer with any tool that integrates in VS, like Wix or Advanced Installer(disclaimer: I work on its development). They are both free for what you need.
Sure, you don't have to use VSTO at all. On the low level, your COM addin is just an in-proc COM server (dll). The COM object exposed by the add-0in must implement the IDTExtensibility2 interface. That's it, there are no other requirements.
See: VSTO 4 ( 2010 ) Lessons Learned
FWIW, I've authored about 10 VSTO AddIn installers and half of them using InstallShield Limited Edition. It actually works really well once you fully understand the deployment requirements and how to use the tools. The primary problem with ISLE is that it does hide a lot of the functionality that's in Windows Installer and more fully explosed by InstallShield Professional Edition.
ISLE allows you to consume setup prerequisites (.PRQ files) but doesn't provide an editor to tweak them if needed. Using an eval version of InstallShield and then back porting the changes to ISLE works nicely there. Also the use of Windows Installer XML (WiX) to create merge modules that get consumed by ISLE solves most of the other problems.
I've got this type of installer template down to the point of taking < 8 hours per project including
project management, testing and close out. Someone brand new to installers should expect to take several months to get something that "seems" to work.
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.)