I have successfully coded a little application level add-in for Excel in C# in Visual Studio. But I seem to struggle with the deployment.
I have tried the ClickOnce and Windows Installer variants and they work fine, but not the way I wanted: I would like to be able to install my Add-in though the "Developer" Tab in Excel by pressing "COM Add-Ins" and then "add..."
But Excel says:
It doesn't recognize neither the .dll nor the .vsto nor the setup.exe files as a valid Addin.
Screenshots for reference https://imgur.com/a/Bj6Vf
How can I compile my code that Excel recognizes it?
It seems like I'm missing a step here and I couldn't find any solutions for this online, so I thought I could ask you for help.
Related
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 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 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'm in the process of learning how to create add-ins for Microsoft Office Word. I've created a simple Word 2010 Add-In project in Visual Studio 2010 which displays "Hello World" in a message box. Up to this point everything works fine. But if I want to change the message for instance from "Hello World" to "Hi" i get the following error message
System.Deployment.Application.DeploymentException: Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
After installing the add-in I do the following:
Remove the add-in from Ms Word Options,Add-Ins
Uninstall the add-in from Add Remove Programs
Delete the Normal.dot file
Delete the .vsto in my bin/Debug folder of the project
Once I re-run the project I get the error above.
I really don't know where else can this plug in exist as I think I delete all possible places where any references to it could be found.
I've also tried running RegScanner and deleting all the registry entries pertaining to the add in,yet im getting the same error...
If anyone had this issue before and you know exactly how to solve it and what could be causing it please let me know!
I discovered that if you modify any code in a MS Word Add-in in Visual Studio and you want your changes to be updated in MS Word you can do the folowing:
In Visual Studio,change the version number in Project Name\Properties\Publish\Publish Properties.
Once the version number has been changed (e.g 1 0 0 1) rebuild the project in Visual Studio.
Navigate to ProjectFolder\bin\Debug and double click the .vsto file, voila! You get the following message - The Microsoft Office customization was successfully updated.If you view the .vsto file with a text editor you can also see that the version number has been changed to a new value,hence an update occurs when you double click the .vsto file.It picks up a new version number and re-installs the add-in and successfully attaches to Word.
If the above is the accepted way to do it, that's fine, but I would still like to know whether there is any way that an add-in can be automatically updated in Word without changing the version number.Simply change code,rebuild project,install.