At this moment, I have a VSTO add-in fulfilling my requirement. But it needs to run with Visual Studio or installed. Ideally, I want to have a Word file containing this VSTO add-in and put this file on my server so that user can use my add-in just by downloading this file, no need to any extra work. Is it possible?
Any help would be appreciated.
A VSTO project must be installed, whether it's an add-in or a document-level customization. Installation ensures that the correct version of the .NET Framework and other pre-requisites are installed. It also includes the user explicitly trusting the solution.
If you want something that distributes with a document then you need VBA, embedded in the document and saved as a *.docm file. Note that this file type will trigger macro security - some people will have settings that won't allow VBA to run. Some will have settings that can allow "trusted" and/or signed projects to run (you can research that).
Related
My goal is install VSTO Outlook Addin for all users on local PC instead of current user. I used Publish method from Visual Studio and result is exe file, which means ClickOnce method. (not posible for install for All)
Well i start my research i found Wix.
My first question is, when i create Build from Visual Studio from my VSTO addin, i have 2 dirs and 20 files, is possible to assign dirs in product.wxs file in WIX Directory ref?
Second question, when files and dirs are "installed" to target directory, (program files for example) how can be VSTO be assigned to Outlook ? Its becouse to add VSTO to registry HKLM ?
Im asking if im closer to my goal
Not sure if I understood your first question but I will try to answer it anyway. The only files you have to bring to a user's PC are those that are located under bin/Release folder, except for those that have the *.pdb extension. There are 2 ways how you can add them into the installation:
First way is to manually add each file you want to include in your installation as the file component in you Product.wxs. You can find a good example of that in their official tutorial.
Second way is to utilize the harvest tool (Heat) from Wix Toolset. This tool can generate a list of components automatically during a build.
As for your second question. To make Word or Outlook see your add-on you have to create an entry in Windows registry during installation. For example for Microsoft Word you have to create a new key HKLM\Software\Microsoft\Office\Word\Addins\MySuperAddOn with the following entries:
Entry
Type
Value
Description
REG_SZ
Required. A brief description of the VSTO Add-in. This description is displayed when the user selects the VSTO Add-in in the Add-Ins pane of the Options dialog box in the Microsoft Office application.
FriendlyName
REG_SZ
Required. A descriptive name of the VSTO Add-in that is displayed in the COM Add-Ins dialog box in the Microsoft Office application. The default value is the VSTO Add-in ID.
LoadBehavior
REG_DWORD
Required. A value that specifies when the application attempts to load the VSTO Add-in and the current state of the VSTO Add-in (loaded or unloaded). By default, this entry is set to 3, which specifies that the VSTO Add-in is loaded at startup. For more information, see LoadBehavior values. Note: If a user disables the VSTO Add-in, that action modifies LoadBehavior value in the HKEY_CURRENT_USER registry hive. For each user, the value of the LoadBehavior value in the HKEY_CURRENT_USER hive overrides the default LoadBehavior defined in the HKEY_LOCAL_MACHINE hive.
Manifest
REG_SZ
Required. The full path of the deployment manifest for the VSTO Add-in. The path can be a location on the local computer, a network share (UNC), or a Web server (HTTP). If you use Windows Installer to deploy the solution, you must add the prefix file:/// to the manifest path. You must also append the string |vstolocal (that is, the pipe character | followed by vstolocal) to the end of this path. This ensures that your solution is loaded from the installation folder, rather than the ClickOnce cache. For more information, see Deploy an Office solution by using Windows Installer. Note: When you build a VSTO Add-in on the development computer, Visual Studio automatically appends the
You may want to read the official documentation to see more details.
Wix Toolset does allow to do that as well. You have to declare the RegistryKey component in your Product.wxs.
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
Working on an outlook addin and I was wondering if manually replacing the compiled DLL on a target machine is sufficient when I decide to update my addin ? is that practice even valid for stability ?
on some minor changes i did to my addin for tests, It seemed to work, even without changing the manifest, or re-deploying but I'm not sure it will still work if the project changes from end to end - Like, is it possible to take a whole different addin dll, and simply place it instead of a dll that is already installed - and walla ? does its manifest even acknowledge the content of the dll or simply point to it?
is sufficient when I decide to update my addin ? is that practice even valid for stability ?
Theoritically, you can replace the add-in assembly with a new one. But the host application should be closed at that time to let you delete/overwrite an existing file. Be aware, the Trust center settings in Outlook can be adjusted to load only signed with a digital signature assemblies. In that case your add-in will not be loaded by the host applications.
Consider using ClickOnce for updating add-ins on the fly. See Deploying an Office Solution by Using ClickOnce for more information.
Yes, as long as you do not change the addin's class name.
I've created my first Office Add-in using Visual Studio. It targets the 4.0 .Net framework and was created using the new VS 2012. I need to distribute/install this project on various 32-bit XP and 64-bit Windows 7 computers around the office. So I configured the project to be installed on XP (which was my first speed bump because I didn't realize VS 2012 needed an update in order to make a solution that was XP compatible). Now that I have a valid win32 application, I am getting another error:
The following error occurred attempting to install 'C:\filepath...\Import Contacts.vsto':
"No application is associated with the specified file for this operation."
After doing some digging, I think I need to install the Microsoft Visual Studio Tools for Office Runtime on the client computer. To do this, I would like to use the prerequisites properties for the project. So I read up on creating custom prerequisites using some noteworthy sites (e.g, Creating Bootstrapper Packages, Application Deployment Prerequisites, Adding Custom Prerequisites, and Creating a Bootstrapper package for Office 2013 in Visual Studio 2012). I created the files according to that last URL (even though I'm not sure it pertains to the package I need just yet), but it is not appearing in the dialog box under Project > Properties > Publish > Prerequisites
If you read the article, it says the VS prerequisites dialog box should automatically update once I restart VS 2012, which I did but to no avail. I know I'll need to use this feature again in the future, so I would really like to know what I'm doing wrong and fix this. Please help! And I promise to quickly give the ACCEPT to whoever helps me fix this problem! Thank you in advance.
I didn't have any problems following the directions given in the web page and got the bootstrapper added to the Prerequisites dialog. However, there are plenty of possible ways to get it wrong. Some possibilities:
Triple-check the folder you added these files to. Be sure that you picked Program Files (x86) on a 64-bit version of Windows and not Program Files. And be sure that you now see the added VSTOR40 folder along with the other existing bootstrapper folders, like ReportViewer and VBPowerPacks.
You do not have write permission to this folder, UAC prevents copying files there. Be sure that you managed to copy them from, say, an elevated command prompt. Right-click the Command Prompt shortcut and click "Run as Administrator".
If you created the .xml files with Notepad then make sure you didn't accidentally saved them with the .txt extension. If necessary, put Explorer in "programmer mode" so you can see the filename extensions. Control Panel + Folder Options, View tab, untick the "Hide extensions for known file types" checkbox. If you now see product.xml.txt then rename the file to product.xml, same for package.xml.txt
If you created the .xml files with Notepad then be sure to save the file in UTF-8 encoding. File + Save As, Encoding combobox.
For all those who still may face similar issue I think that I found the cause of this issue. It seems that copying folder with custom bootstrapper package (and all necessary files in it) does not "refreshes" the list of available packages. Only when i went through this walkthrough and manually created folder in %Programfiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\ for sample package from this walkthrough my package has shown
I am having some difficulties with installing an Excel addin at my client. I have created an installer for the addin using the instructions at http://www.clear-lines.com/blog/post/create-excel-2007-vsto-add-in-msi-installation.aspx, and it has been successful for the majority of users. The installer was run as an admin and this seemed to work ok. However for a small proportion of users the installation was unsuccessful - the registry entries are created but the addin does not load when Excel starts and does not appear in the addins list. Trying to add it manually from the installation folder gives an error that the addin is not valid.
To complicate matters slightly, the client uses both Vista and XP (although all installations of Excel are 2007). None of the XP machines have installed the addin successfully, whereas most (but not all) of the Vista machines have been successful.
Has anybody had any experience of this, or might be able to point out where I am going wrong?
Many thanks in advance,
Rob
There were changes to various user profile paths between XP and VISTA. If you've hardwired any paths like \Users\username\Application Data, etc, you may not be installing things quite right under XP, where the path would typically be \Documents and settings\username\Application Data.
Finally, if an addin isn't loading, about the only causes are
1) the reg entries pointing to it (or to the MANIFEST in the case of VSTO) either aren't there or aren't right.
2) the addin has some prerequisite or dependency that you've missed, and since it's not there, the addin loader is just failing to load the addin.
For 1), just check the reg entries for all the right values, then add a msgbox or some logging in your addin to verify that it is, indeed, at least being initially loaded by Excel.
For 2) I'd read up on the Fusion Loaded Viewer and use that. Fusion is the .net "loader" service, and it can be setup to log all sorts of detailed info about where it's looking for preqs, which one are found where, and which can't be located.
Details here
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx