I developed a VSTO Excel add-in with a Ribbon containing a few buttons. When we build the add-in through our TFS build server, the ribbon isn't loaded, although the add-in itself is loaded without any errors (it's shown as active in Excel\Options\Add-Ins, I write log entries on Startup and Shutdown, which are written correctly to my log file etc.) If I use my developper machine built add-in files (.dll, .dll.manifest, .vsto) the add-in loads correctly.
After long searching, we found a difference in the manifest file created by my machine and the build server. The build server manifest file seems to be missing an entry for the ribbon.
Does anyone know if there's a way to influence what entries are contained in the manifest, or if there's a setting in VS, which influences the manifest creation?
The lines of the build server manifest with the ribbon look as follows:
<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="AVExport">
<vstov4:friendlyName>AVExport</vstov4:friendlyName>
<vstov4:description>AVExport</vstov4:description>
<vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1" />
</vstov4:appAddIn>
The same lines from my developper machine manifest file look as follows:
<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="AVExport">
<vstov4:friendlyName>AVExport</vstov4:friendlyName>
<vstov4:description>AVExport</vstov4:description>
<vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1">
<vstov4.1:ribbonType name="Publisuisse.Publiplan.Client.Offer.AddIn.AVRibbon, AVExport, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</vstov4.1:ribbonTypes>
</vstov4:appAddIn>
As you can see, my manifest contains an additional line which references my ribbon.
I couldn't find any information on this behaviour neither via SO search nor through google.
Any help is appreciated!
Cheers
Dominik
I found the answer to my problem: Here you can find the reason the manifest didn't work anymore, and here the solution:
Override the function
using Microsoft.Office.Tools.Ribbon;
protected override IRibbonExtension[] CreateRibbonObjects()
{
return new IRibbonExtension[] { new Ribbon1(), new Ribbon2() };
}
to load the ribbons manually. Case closed.
Related
So I'm trying to use the direct app install feature of Windows 10 Creators Update to allow downloading a packaged modern app from the web. The key feature of it is that it will auto update your app by checking back to the same URL of the .appinstaller file.
https://new-file-explorer.firebaseapp.com/ (the page is entirely generated by Visual Studio, no modifications from me)
The problem is that when I click it I just get "Error in parsing the app package."
If I manually download the .msixbundle that's referenced in the .appinstaller file it will work! Yet App Installer itself can't "parse" this package?
Here's the weirdest part: if I use "Add-AppxPackage -Appinstaller" from Powershell and point it towards the .appinstaller URL it will completely work!
The other answers on here do not apply, since they were all related to running it on a local server (I tried it anyways).
I thought this was related to MIME types, but I have set the MIME types as stated in the documentation and yet it still doesn't work. I've verified that by using this URL MIME type checker. I'm at a loss to what is actually causing this.
Here is the .appinstaller file:
<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://new-file-explorer.firebaseapp.com/InstallNFE.appinstaller" Version="1.0.9.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2">
<MainBundle Name="NewFileExplorer" Version="1.0.9.0" Publisher="CN=david" Uri="https://new-file-explorer.firebaseapp.com/InstallNFE_1.0.9.0_Test/InstallNFE_1.0.9.0_x86_x64.msixbundle" />
<UpdateSettings>
<OnLaunch HoursBetweenUpdateChecks="0" />
</UpdateSettings>
</AppInstaller>
Here's a link to the .msixbundle it appears to be incapable of parsing (as you can see, it works manually downloading it!)
Thought of putting the solution in case someone else is facing the issue. I also faced the same issue and was able to resolve myself. When opening the Windows 10 .appinstaller file from web, the error "Error in parsing the app package." occurs.
For me the cause was that the links provided in the HTML page index.html generated by Visual Studio was referring to some share location (as my installer location was a file share location) and the installer file was not there. The reason for this is that I didn't do the last step "Copy and Close" of publishing from VS (this step copies the installer from output location to installer location that you provided). Instead of "Copy and Close", I just clicked on another option "Close" and hence the issue.
Just an additional input as i also encountered this issue and spent a whole day of finding the fix.
Let me just copy a line from .appinstaller file of the original poster.
<MainBundle Name="NewFileExplorer" Version="1.0.9.0" Publisher="CN=david" Uri="https://new-file-explorer.firebaseapp.com/InstallNFE_1.0.9.0_Test/InstallNFE_1.0.9.0_x86_x64.msixbundle" />
In this line, it only specify as ".msixbundle" file but the actual file in local folder is ".msixbundle.zip".
After I removed ".zip" from the filename of the file, the issue is gone.
Hope you can help me. I am looking forward to programming my first MS Access AddIn with Visual Studio 2015 (a Ribbon-Bar as VSTO), but not having started I have to stop already. Visual Studio provides templates for almost every office product, but MS Access. I heard it is possible to "change" for example the Excel VSTO-Template so it can be used to develop an MS Access Ribbon.
Does anyone know a good instruction how to handle this? How are you developing VSTO for MS Access?
Thanks for your help
There exists a tutorial for this. I haven't tried it, don't know if it works, but it sounds promising.
Here are the juicy bits.
To start building an Access add-in, I could create a Word (or InfoPath, PowerPoint, Project or Visio) add-in (Excel or Outlook would also work, but they have additional redundant host-specific code).
Then, I'll add a reference to the Microsoft Access Object Library, on the COM tab (this also pulls in references to ADODB and DAO). It also pulls in Microsoft.Office.Core.dll, which duplicates the Office.dll already referenced by default - so I'll delete one of these two duplicates.
In Solution Explorer, I can select the project and click the "show all files" button. This makes it easier to open the ThisAddIn.Designer.cs file – here I can change the declaration and initialization of the Application field from M.O.I.Word.Application to M.O.I.Access.Application. Note that this step changes a file that is auto-generated: the file is not normally re-generated, but can be if I corrupt the project (the point being that my manual changes will be lost if the file is re-generated):
//internal Microsoft.Office.Interop.Word.Application Application;
internal Microsoft.Office.Interop.Access.Application Application;
//this.Application = this.GetHostItem<Microsoft.Office.Interop.Word.Application>(typeof(Microsoft.Office.Interop.Word.Application), "Application");
this.Application = this.GetHostItem<Microsoft.Office.Interop.Access.Application>(typeof(Microsoft.Office.Interop.Access.Application), "Application");
That's all the code changes. Now for the project changes. There are two ways to do these changes – through the IDE in a way that overrides or counters the default settings; or by manually editing the .csproj file directly, to replace the default settings. Let's look at both approaches: first through the IDE, then manually.
First, I'll change the Project Properties | Debug | Start action, to "Start external program", and specify the path to Access, for example:
C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE
Then, I'll create a .reg file with the same name as my add-in solution, and put it in the solution folder. This reg file is used to register the add-in for Access (and unregister it for Word). The example reg file listed below is simply a dump of what the standard VSTO build task does for each add-in type, with an additional line. The additional line (the first reg entry below) simply removes the entry that the build task puts in for Word. The remaining entries are identical for Word and Access, with the only changing being to replace "Word" with "Access":
Windows Registry Editor Version 5.00
[-HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\MyAddIn]
[HKEY_CURRENT_USER\Software\Microsoft\Office\Access\Addins\MyAddIn]
"Description"="MyAddIn"
"FriendlyName"="MyAddIn"
"LoadBehavior"=dword:00000003
"Manifest"="C:\\Temp\\MyAddIn\\bin\\Debug\\MyAddIn.vsto|vstolocal"
In Project Properties | Build Events, I add a Post-build event commandline to merge the .reg file into the registry:
regedit /s "$(SolutionDir)$(SolutionName).reg"
That's it. I can now press F5 to build the solution: this will register the add-in for Access, and run Access for debugging with the add-in loaded.
Note that instead of setting the Debug property to an external program (step 4 above), I could modify the .csproj file directly, to set the from Word to Access. For example, change this:
<ProjectProperties HostName="Word"
HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Word\InstallRoot\Path#WINWORD.EXE"
AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
… to this:
<ProjectProperties HostName="Access"
HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
ApplicationType="Access" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Access\InstallRoot\Path#MSACCESS.EXE"
AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
Note that changing the value, as show above, changes the icons used in the Solution Explorer .
I could also change the element's Name value to change the name of the parent node for the ThisAddIn.cs in the Solution Explorer. Change this:
<Host Name="Word" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
<HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>
… to this:
<Host Name="Access" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
<HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>
Also, registration is determined by the element value. So, instead of setting up a .reg file as a post-build task (steps 5-6 above), I could edit the .csproj directly to change this:
<OfficeApplication>Word</OfficeApplication>
…to this:
<OfficeApplication>Access</OfficeApplication>
I've been developing the VSTO plugin for Outlook and on some customers' PCs ran into the slow loading issue (which is apparently a chronic disease for all managed office add-ins as CLR loading is counted towards the whole plugin loading time).
I've read about a workaround that there is a possibility to have the VSTO plugin loaded by setting its Connect property to true from a fast-loading Native COM add-in: https://blogs.msdn.microsoft.com/andreww/2008/04/19/delay-loading-the-clr-in-office-add-ins/
I've implemented it, however even after setting the Connect property of VSTO add-in to true from the Native add-in it is still not loaded. I have the following code that is executed at OnStartupComplete:
CComVariant vtItem("VSTOAddInName");
Office::COMAddInsPtr spCOMAddins;
m_spOutlook->get_COMAddIns(&spCOMAddins);
if (spCOMAddins) {
Office::COMAddInPtr spCOMAddIn;
if (spCOMAddins->Item(&vtItem, &spCOMAddIn) == S_OK)
{
spCOMAddIn->put_Connect(VARIANT_TRUE);
// I see this message!
MessageBoxW(NULL, L"Connected flag set", L"Native_Addin", MB_OK);
}
}
return S_OK;
The m_spOutlook is defined as:
Outlook::_ApplicationPtr m_spOutlook;
I see the MessageBox, so I assume that Connect property is set, but the addin still does not load. I've tried to do t with all possible LoadBehavior settings and none of those work. So the question is whether this workaround supposed to work? Maybe I should execute it under a different callback than OnStartupComplete. It is fine for me tho have the plugin loaded few seconds after outlook start, I just need it loaded and not hit the 1 second startup limit.
I would really appreciate your help!
P.S. The load-once delay-loaded VSTO plugin (LoadBehavior=16) is only a partial solution for me as I need the button in the ribbon to be disabled on certain items, so I need the plugin to be really loaded. Also, sometimes the button is disappeared without any notable reasons and it requires end users to do some magic to get it back which is not an option for me.
Instead, I'd suggest reviewing the source code of your existing VSTO solution. Move any business logic to secondary threads so Outlook could load the plug-in as fast as it can. Moreover, you can use standard .net mechanism for decreasing the startup time such as:
Use NGen.exe to move code generation from application startup time to installation time.
Utilize the GAC. If an assembly is not installed in the Global Assembly Cache (GAC), there are delays caused by hash verification of strong-named assemblies and by Ngen image validation if a native image for that assembly is available on the computer. Strong-name verification is skipped for all assemblies installed in the GAC. For more information, see Gacutil.exe (Global Assembly Cache Tool).
Defer Initialization Operations. Consider postponing initialization code until after the main application window is rendered. Be aware that initialization may be performed inside a class constructor, and if the initialization code references other classes, it can cause a cascading effect in which many class constructors are executed.
Authenticode verification adds to the startup time. Authenticode-signed assemblies have to be verified with the certification authority (CA). This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. It also makes sure that there is a full chain of valid certificates on the path to a trusted root. This can translate to several seconds of delay while the assembly is being loaded.
You can read more about that in the Application Startup Time article.
Is your add-in shown in the Disabled Items list after the Connect property was set to true?
Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when an VSTO 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 VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article.
Did you try to enable the add-in manually? Do you get the same results?
I have created outlook addin for Outlook 2013 64 bit.
In that Addin, i have created Form region with custom controls.
Then with the reference of http://blogs.msdn.com/b/emeamsgdev/archive/2013/11/21/outlook-deploying-an-outlook-2013-add-in-using-installshield-le.aspx i created setup file for Addin.
Now i installed it in my computer and everything works fine.
However when i try to install it on client computer, it doesn't show addin in outlook.
and i am not able to find any reason.?
I have also created registry for my addins
If it simply doesn't load, without errors, it only means one thing, outlook is unaware of your addin, cause even when addins are not working, outlook gives you an error or turns the LoadBehaviour regkey to '2'.
On your client, you should check that the registry values are set properly.
**HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\Outlook_PROJECT_ADDIN
If your addin doesn't work, check to see if those values exist, and if they do, what happens when outlook loads ? does LoadBehavior turns to '2' instead of 3 ?
If so, and it works perfectly on your pc, it probably means you have issues with the Manifest regkey, make sure the manifest points to a valid local location followed by a |vstolocal
so its syntax should be something like:
file:///C:/Outlook_Proj.vsto|vstolocal
Also make sure you have .Net Framework v4.0 installed on your target PC.
If you're trying to install it to a network drive, make sure you remove the '|vstolocal| thingy, and add the network drive to the trusted zone in Internet Explorer Settings.
Hope the following steps will help you solve this problem if you are still facing it.
Run the deployed setup with administration rights.
If it is not shown under Add-ins, open the setup folder and double click on the .vsto file then select install.
If you can see the addin among the others, and is not functioning it means it is disabled. To enable the add-in(since you are using outlook 2013), go to File -> Slow and Disabled Add-ins, and you shold see your add-in on the pop-upped window. Enable it.
Create the VSTO_SUPRESSDISPLAYALERTS = 0 enviorment variable to get any VSTO alerts. Take a look in the Windows event viewer and off course be sure of being installed the pre requisistes like Office Primary assembles and VSTO for office. Another think, check if your adding was not crashed once and move to inactive add-in list. Search registry for Resiliency key.
I've just built an MS Outlook Add In using Visual Studio and Office 2010. I've installed it ok on 4 machines, but one user is getting the following error -
Error found in Custom UI XML of "...."
...
...
Failed to find Office control by ID
Everyone is running Windows 7 and Outlook 2010 - not sure why this person is having a problem. Can anyone suggest how to diagnose this?
For those having similar issues, you don't have to remove any add-in.
What is happening is: Outlook will try to load all ribbons (found in your ribbon xml) into any window the user goes to. Then it'll complain about not finding ID x or y.
Just make sure your GetCustomUI method in Ribbon.cs does not load the entire ribbon XML at once but rather loads it per fragment.
If you're not sure what IDs you need to target, use a breakpoint in GetCustomUI then start Outlook, surf different views (main, new email, new appointment, calendar...etc) in order to gather the IDs for the views wherein you need to show you add-in.
In my case, I needed Microsoft.Outlook.Explorer, Microsoft.Outlook.Mail.Compose and Microsoft.Outlook.Appointment.
Therefore I changed my GetCustomUI to:
public string GetCustomUI(string ribbonID)
{
switch (ribbonID)
{
case "Microsoft.Outlook.Explorer":
return GetResourceText("MyAddin.RibbonsForOutlookExplorer.xml");
case "Microsoft.Outlook.Mail.Compose":
return GetResourceText("MyAddin.RibbonForOutlookMailCompose.xml");
case "Microsoft.Outlook.Appointment":
return GetResourceText("MyAddin.RibbonForOutlookAppointment.xml");
default:
return null;
}
}
Of course, I had to break down my Ribbon.xml into the three XML files mentioned above. The result: Outlook will ONLY load the fragment needed for a given screen (appointment, new email ...) and will not complain about "not finding an ID on screen X or Y".
Finally, for those who are not sure why some users get that error while others don't: it's because of "Show add-in user interface errors" option (in Options -> Advanced). If that is unchecked then Outlook will ignore the malformed ribbon XML errors. If it checked, users will get related errors about your add-in (if any exists) and also about other add-ins.
If it works for everyone except one user. As #Brijesh Mishra mentioned check if the user has got any other addin and if he is having own quick access tool bar customized.
If he has got any of this then, remove the other addins and try to install or reset the quick access tool bar customization.
For all of you that use a Designer-based VSTO plugin, and not the XML solution.
I searched all the web for this problem, but only found XML-based solutions.
There's nothing for Visual Designer on the web, because in this case you don't have to override the "GetCustomUI" method.
Ribbons designed by using the Visual Designer return a RibbonManager by default.
This RibbonManager object represents all Ribbon (Visual Designer) items in the project and is automatically handled in background through the active window inspector.
So you don't have to write any special code to handle different windows.
To configure it correctly you just have to:
Add one extra Visual Designer Ribbon for every window the user goes to
in the Ribbon Object go under "RibbonType", open the checkbox list an only activate the corresponding window, where the ribbon should appear.
If there is more than one window checked in the list, Outlook trys to insert the ribbon in all the marked windows. Even if the corresponding window is currently not opened. That's the reason, why the error "Failed to find control ID" appears.
the actual fix for me was to separate the ribbon XML files containing the customUI and redirecting to the correct one in the GetCustomUI method (implemented using Office.IRibbonExtensibility)
in example:
public string GetCustomUI(string RibbonID)
{
switch (RibbonID)
{
case "Microsoft.Outlook.Mail.Read":
return GetResourceText("namespace.type1.xml");
case "Microsoft.Outlook.Mail.Compose":
return GetResourceText("namespace.type2.xml");
default:
return null;
}
}