I have a VSTO document-level customisation which was originally built with VS2005, VSTO 2005 SE and Excel 2003. In that configuration, I published the customisation from VS2005, copied it to where I wanted it on a user's PC, and ran a tool I have developed which set the CAS policy correctly and used the ServerDocument class to add the customisation to the user's workbook. The user could then restart Excel, open the workbook and the customisation would run. We could just copy a new version of the customisation to the same location and it would be used next time the user opened the workbook.
I've now upgraded to (gasp!) VS2008, VSTO 3.0 and Excel 2007. I've reworked my custom policy tool so that it works with the new version of VSTO. I can still attach the customisation to the workbook, but on first opening the workbook it seems to "install" the customisation into the user's AppData\Local\Apps folder. This then causes considerable grief when we want to update the customisation later. This also changes the value of AppDomain.CurrentDomain\BaseDirectory.
Is there a way in VSTO 3.0 to go back to how we used to work, without installing the customisation to the Apps folder?
As I understand it, Microsoft shifted VSTO in VS2008 to use ClickOnce for deployment and Authenticode for Code Access Security (CAS).
However, you can avoid ClickOnce by appending |vstolocal flag to the _AssemblyLocation custom property value of your customized workbook file. This |vstolocal instructs "VSTO to run the solution from the installation folder" according to this VSTO Team blog post on deploying VSTO add-ins to everyone on a machine
The VSTO loader's change from CAS policy to Authenticode may also effect how you sign your assemblies.
Related
I am developing EXCEL VSTO add-in where each user have their own license file to communicate with API. I am new to VSTO add-in development and have no experience on creating installer of VSTO Add-in. Is there any chance that in installer we can provide step where we ask user to upload license file before installation?
There are two main ways for deploying Office solutions:
Deploy an Office solution by using Windows Installer
Deploy an Office solution by using ClickOnce
All the required steps are described in the articles mentioned. It is up to you which one is to choose.
However, MSI (Windows Installer) allows to create a custom UI with custom actions that will work for you best.
I am developing an add-in for Word to add ribbon bar functions for our business.
I am developing the add-in in VB.Net using Windows Visual Studio 2017.
The machine is currently a stand-alone machine that is not connected to the main network.
My issue is that for some reason, the add-in seems to have set itself up in such a way that it appears to have already been installed on the system and loads, with the most updated code, if I just start Word normally.
Any development has been done in Debug mode and I have not been re-building the solution in release mode, and yet anything I change and then run/debug updates the code that the add-in appears to be run off when opening Word directly.
If I go through the options --> add-ins and disable the VTSO add-in it just gets enabled again. I don't seem to be able to separate a debug/development section and live code.
Edit from comments: I can accept that the VTSO needs to be installed and registered but having no separation of live code and development code is frustrating. This machine is used by others for other purposes and this includes using Word, and so any old code must be kept as comments that can set back as the working code should I need to leave part way through. I cannot leave anything partially written as any run the debug mode will set the code as live.
What you're experiencing is normal behavior. When you debug, VSTO registers the add-in in the Windows Registry. This is all that's required for the Office application to find and load the add-in when it starts.
If you disable the add-in in Word, it will remain disabled until you again debug the add-in in Visual Studio.
If you share the machine and want to have the add-in under development disabled for other users:
Work with separate user profiles. VSTO registers its add-ins under CurrentUser, not for all users - VSTO isn't designed to register add-ins for the entire machine. OR
Get into the habit of using Visual Studio's Build/Clean Solution functionality when you leave the machine. That unregisters the add-in (until it runs in debug mode again).
Its a long story. I had a simple VSTO excel solution that i build in VS 2005 and Excel 2003. Few years ago we upgraded to Excel 2010 and VS2010. The VSTO solution was upgraded to .xlsm file and everything worked fine.
Recently we upgraded to Office 2013 and VS2013. (Office 2010 was uninstalled and then Office 2013 was installed). I opened the VSTO project and it forcibly upgraded the solution. I published the new version which created the setup.exe in the publish folder. I install the new customization on my dev PC and then open the .xlsm file that was installed on c:\user\abc\appdata\local... on my dev machine and everything works fine.
However, when i install setup.exe on a user machine and open the .xlsm file, even though i dont get any errors, the customizations (buttons etc) are all greyed out. Its as if it didn't even install. I banged my head with this all day today and cant figure it out. PLEASE HELP.
Thank you in advance.
Tarun,
Make sure that all the required prerequsites were installed properly. See Deploying an Office Solution by Using Windows Installer or Deploying an Office Solution by Using ClickOnce for more information.
Also I'd suggest checking the COM Addins list in the application. Is it enabled?
Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.
Hard disabling can occur when an 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 add-in is executing.
Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again. See How to: Re-enable an Add-in That Has Been Disabled for more information.
I am trying to build a simple addin for Word 2007 using Visual Studio 2010 and .NET 4.0. It's a relatively simple addin, which brings up a save dialog and saves the document as a Word 2003 document.
The addin runs fine in Word under Debug mode, but does not run under Release or when I create a setup project for it. (It does create the registry keys under HKCU\Software\Microsoft\Office\Word\Addins and they look to be correct) I don't get any errors, and the addin isn't listed under the Disabled Addins either.
I tried adding the Addin manually but it says that it isn't a valid addin. The version of Office is 32-bit, running under Windows 7 64-bit.
Or are there even any alternatives to using VSTO (VBA?) that will let me add a tab to the Ribbon?
You can use IRibbonExtensibility interface (http://msdn.microsoft.com/en-us/library/microsoft.office.core.iribbonextensibility.aspx) to avoid using VSTO.
I have created a VSTO application using office 2005 & visual studio 2005 professional.I found there a setup folder.While i am running the *.exe file in client machine,it giving me error."An add-in could not be found or could not be loaded."
What is the architecture of the client machine?
If Vista: do you have the UAC (Security Dialog) disabled?
Also check in the Registry if the Path to the Manifest File is correct.
Is it loading the right Framework Version?
Are you using the Publish feature, or are you trying to create your own MSI?
You need to do some debugging on your side to have this sorted maybe:
Try to uninstall VSTO SE completely and install it again.
Create a new VSTO add-in without any additional code and run it.
Evaluate what happens and perform actions accordingly