I'm working on a VSTO add-in for Outlook that, if another custom VSTO is loaded, will perform a specific action. How would I determine if that VSTO is loaded? I've not delved too far into COM as of yet other than writing a number of add-ins.
You can check the key:
"HKLM\Software\Microsoft\Office\Outlook\Addins[YourAddInName]"
in the registry.
Existence of the key means that the AddIn is installed.
You can also read the value LoadBehaviour under the above key, the value 3 means that the addin is loaded/to be loaded normally. The value 2 means that the addin has problems.
Related
I am currently maintaining a company-internal add in that only takes a mail, wraps it as attachment and sends it to our internal mail adress for spam reports.
The add in always had the issue that for seemingly no reason ( - besides: "the addin has caused outlook to crash - therefore it has been permanently disabled", when checking the addin state)
Outlook doesn't like it and disables it permanently without options to re-enable.
This was already an issue with Outlook 2016, and could back then be solved by setting a few registry keys. I was tasked to build a version for Outlook365. Outlook365 seems to be a lot more sensible there.
I have added a function that sets the following keys:
[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\SpamReporter]
"LoadBehavior"=dword:00000003
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList]
"SpamReporter"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Addins\SpamReporter]
"LoadBehavior"=dword:00000003
The following key is also rolled out via company policy:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\outlook\resiliency\addinlist]
"SpamReporter"="1"
Furthermore. The assembly is signed with a Comodo Certificate in Visual Studio, and I have also tried to sign the installer itself again.
But all of these efforts seem to not make a difference. I thought I had a working version we could roll out, only to get the response from our rollout guy that the plugin doesn't show up for him when he tested it quickly.
This behaviour is really frustrating and the docs on Office 365 VSTO COM add-in troubleshooting seem really scarce.
I have spent an obscene amount of hours trying to fix this issue.
Most likely your addin takes too long to load (assuming it does not crash on startup).
Note that you get punished for using .Net - the whole .Net run-time of a particular version needs to be loaded before a single line of code in your addin runs. There used to be a Warmup registry key that allowed to tell Outlook whcih version of .Net run-time you are using so it will preload it, but it is no longer supported.
What does Outlook itself say when you go to File | Options | Addins | COM Addins?
I've written a Excel-Dna based Addin in C#.
Used the following technique to register it at users computer (from WixInstaller and ManageOpenKey):
Locate the active Excel version key in registry (16.0 for this example):
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Options
Write the path of the XLL in the first available string value named
"OPEN". As seen in this screenshot, my Addin is written at "OPEN1" key.
Everything works as expected in the installation, but the problem starts if one of the addins is uninstalled using WixInstaller.
For example, if value "OPEN" is removed, addins at "OPEN1" and "OPEN2" will stop functioning. Excel explicitly looks for "OPEN", "OPEN1", "OPENXXX" sequence and if one of the values is missing - it stops enumerating.
I checked the source code of ManageOpenKey - it "blindly" removes the addin key even if this operation breaks the sequence.
Only solution I am thinking, is to write a function that re-orders all the keys. This does not look so difficult, but my question is:
Have anyone found a solution for this?
Yes you would have to rewrite the OPEN keys so that they are in contiguous ascending sequence.
Also worth removing the key from the ADDINS hive in case a user has used the XL Addin manager to move it from the active to the inactive list of addins.
Charles Williams answer is correct. When uninstalling an Excel add-in, you should rewrite & reorder the values in the registry that comes after the add-in being uninstalled (if any).
I've added an issue to the Excel-DNA WiXInstaller Template repo, for us to fix it.
Uninstalling add-in can break other add-ins
how I can programatically load and unload a VSTO add-in in Word on button click.
I have unloaded it on event click bu using below code.
foreach (Office.COMAddIn addin in Globals.ThisAddIn.Application.COMAddIns)
{
if (addin.ProgId == "DocDrafter")
{
addin.Connect = false;
return;
}
}
but on document change and document start I have to load the add-in again.
But once addin is unloaded I am unable to load it again.
You have a couple of possibilities - it depends on what, exactly, you want to do. To begin with, you should (have) read the information in the Word object model Help for the AddIns collection and the Addin object. (We're talking about Globals.ThisAddIn.Application.Addin/s for your VSTO project.)
There are basically two approaches. One is to used the Installed property of the Addin object which loads (=true)/unloads(=false) the add-in from the Word UI, leaving it in the list of Add-ins (the list in Word's File/Options/Add-ins tab) so that the user (or your code) can load it again as required. It sounds like this is what you need.
The other approach is to remove/add the add-in to/from that list. Use the Addin.Delete method to remove the add-in; use Addins.Add to add an add-in to the list.
If you disconnect the Add-in from within the VSTO project, as your code does, I don't think there's any way within the scope of VSTO that you're going to get it to connect, again...
Help topic in the documentation: start here:https://msdn.microsoft.com/en-us/vba/word-vba/articles/addins-add-method-word
In Visual Studio, I have a solution. In that solution I have 2 projects. One is a VSTO so that we can make a plugin for Excel. The other project is for creating a .xll file so that we can have Custom Functions.
The VSTO helps us create a login system on excel so that they can do certain things.
However, since we only want our users to be able to use our custom functions they have to log in. I think that these 2 projects can't communicate directly so the .xll addin wouldn't know if a user is logged in or not.
Is there anyway for these 2 projects to communicate? Perhaps via a middle-man like a class with static variables?
EDIT:
More information:
Both projects are written in C# code. I was able to do that for the .xll file by using ExcelDNA.
So if there's any way that I can create maybe a C# class that can coordinate or share data between the two projects that would be really great. Since login data isn't the only thing that we want to share.
I'm hoping in the class there would be a static boolean variable holding whether the user is logged in. So the VSTO could set the boolean value and the .xll could get it.
You could add a hidden function [ExcelFunction(IsHidden=true)] to the .xll, which you can call from the VSTO add-in with Application.Run.
I would use a licensing system that let the user validate a licence key. This process can takes place within the VSTO. Then I would use two checks :
if in the VSTO the licence key is validated then load the xll, otherwise do not load it.
within the xll, by using relative path, I would locate and check a second time the licence key (to prevent that the user loads directly the xll).
It just requires to be able to check the licence key in C# (VSTO) and C (Xll), ie to have a validation key algorithm implemented in both languages.
I want to control an Excel Add-In with C# from a Windows Forms Application.
This is what I have so far:
var excelAddin = excelApp.AddIns.Add("C:/.../NWPredict.xlam", Type.Missing);
MessageBox.Show("Predict: " + excelAddin.FullName);
This code works, but how would I start the Add-In and change its settings?
If you want to permanently change settings of an add-in then you would need to Open this file, not attach it as an add-in to the currently running instance of Excel. (This isn't usually done programmatically though.)
Perhaps you should clarify because, to me, an add-in is supposed to be "complete". If any settings need to be changed when the add-in is in use, then the add-in itself should make these settings available to the Excel-instance, via exposed properties (or some other technique). But, again, these settings wouldn't be permanently saved (in the add-in itself).