Do any of you have advice on methods for deploying an office VSTO addin, especially Excel, that makes it easy to update and deploy the document as well as the addin.
I have a document level addin for Excel 2010 that I created using VSTO. I currently deploy it using click once. However, this has a few problems. The first problem is that I publish it to ftp then users install it from my website. Since the document and addin are downloaded from the internet, I obviously have trouble getting proper permission for the addin to run and the document to be trusted. Currently I just have users manually adjust permissions and grant access when the solution is installed. That part works and is fine, but if any of you have suggestions on how to automate this that would be great.
The second problem, the main one I am wanting help with in this post, is deploying updates. I generally like using clickonce because of its ease of installation and automatic update features. The solutions I develop are used in rapidly growing fast changing companies, which means I am often making updates. Click once makes it easy enough to update the "code" or addin itself. I just have it automatically check for updates when it is started, and if there are updates it will prompt the user to download them. But what about the document? My solution doesn't only include the code. It also includes the highly customized Excel workbook.
When the solution is initially installed a copy of the workbook is just downloaded to the local computer. But what about after it is deployed to dozens of computers? Does a document level change (adding a column for example) mean going to each computer and downloading the updated workbook manually?
Surely there is a better way to automatically deploy updated versions of the workbook. Any suggestions?
Here are a few ideas I thought of:
Use some installer other than clickonce. Any suggestion on one that allows easy automatic updates?
Somehow package the workbook as an application resource. I have actually done this in some situations, but not in cases where the document itself included a VSTO addin.
Related to the previous idea. Make a "wrapper" project that includes the workbook & VSTO addin. Then the addin would be launched by clicking on a regular icon on the desktop, which would download the workbook (if an update was needed) then open it in Excel. I would prefer that method of launch over simply opening the workbook anyway.
Note: No user data needs to be preserved in the Workbook when an update is done. The old version could simply be overwritten by the new one. The workbook gets all its data from an SQL server.
You could use a Visual Studio Setup Project which leverages Windows Installer. See this deployment walkthrough guide on using VSTO 4.0.
In Visual Studio 2012, support for Setup Projects is being deprecated in favor of InstallShield LE which is another alternative.
Related
I have recently moved from developing VBA Excel Add-Ins to using the new Office JavaScript Add-ins platform. I am used to my VBA Add-In being active across the whole of Excel and the state of the variables is available no matter what workbook you are interacting with.
This does not seem to be the case with JavaScript Add-ins. I have been testing my Add-In and happened to create a new workbook and noticed that none of the Add-In state appeared to be active any longer.
Am I missing something or is this a consequence of the new Office JavaScript Add-ins architecture where it runs inside a browser within Excel?
Just to confirm I have already enabled the Shared Runtime option, that is not my question. I am able to share state between Commands, Takspane and Functions. But all within a single workbook.
I have tried one of the example Yeoman generator for Office Add-ins and it certainly seems that global variables are not shared between the Add-In in two different workbooks.
This behavior is expected. With Office (web) add-ins, each add-in runs in an embedded JavaScript runtime that is a completely separate process from Office and any other add-ins, so it cannot share data across add-ins. Some people have made sharing across add-ins work using the OfficeRuntime.storage object, but it only works in Windows. It won't work on Mac or in Office on the web. Frankly, the Office platform team considers it a bug that it can be done on Windows and that may be fixed at any time, so you should not create an add-in that depends on it even if you know your add-in will only be run on Windows.
Depending on what your scenario is, you might be able to store state in the document with either Office.document.settings or Office.document.customXmlParts. Another possibility is to store state in a database on your server side.
This is hardly the first time this question has been asked, but there are no completely satisfactory answers that have been presented, and nearly ALL of them rely upon Microsoft's error-laden developer documentation.
After creating a vb.net VSTO Excel Template project using Visual Studio 2019 with Office 2016 and porting exiting VBA code to vb.net, I have run into a brick wall. I was able to convert the code to vb.net without too much trouble, and thanks to the .net libraries, I was able to include additional functionality that before was impossible with VBA (e.g. Action Panel menus, etc.). But now I cannot distribute the solution to my employees because I cannot create a setup file that will allow the template code to run correctly when the resulting document is saved to any location other than where it was first installed.
I have tried using the supposedly simple ClickOnce method. I have tried the Windows Installer method. We don't have a Sharepoint server (we are a small company) and I don't want to learn how to create one. I have followed the examples at
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-windows-installer?view=vs-2019
and
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-clickonce?view=vs-2019
and
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-a-vsto-solution-by-using-windows-installer?view=vs-2019#to-build-the-setup-project
and several other Microsoft Visual Studio VSTO instructional articles to no avail. I still cannot get the resulting template file to reference the necessary libraries when the template is moved or saved to any location on a user's computer other than its original install folder. This pretty much makes the solution useless to me. You would think something this important to so many VBA users would be a priority to Microsoft, but it clearly is not. Microsoft refuses to fix/update its documentation, and it ignores vb.net like Microsoft's own policies had nothing to do with why so many of us use it.
I would post my code, but I have no idea what code, in what has now become a rather complicated solution, is causing the problem. My only clue is the error message, which appears whenever the Excel workbook is saved somewhere else and states that "my solution".vsto could not be downloaded because Office is looking under where the template is now stored rather than the original installation directory.
I have been digging into this for quite sometime to no avail. Thanks for any pointers.
Lets say you have a simple VSTO excel add-in. In the publish properties, I have specified a publish location and an installation location for end users.
I click publish. Out comes a setup.exe, addin.vsto manifest and application files. I understand that I will eventually copy this to an install location specified in the properties.
The question is - where exactly the "installation folder url" end up?
I searched in the vsto manifest, resources in setup.exe and resources in the addin.dll etc.
Why I want to know is that at build time, I want to change the installation folder url. I tried passing a command line argument, but it seems that eventually when I publish a revision, the updates are not getting picked up on the end user machines. Now I am curious as to how this value that I enter in this dialog box is used by the publish process and where it ends up.
Thank you for reading and your time.
Answering my own question since I spent more than a week on this and it might be useful to others.
At least for the scope of the question - You are developing an excel VSTO addin
The installation folder URL that you specify in the publish properties of Visual Studio is not used. It might be used for document level customization, but not for application level add-ins.
Essentially when users install the add-in from an "installation folder url", the
value of that is entered into the registry under Office\excel\addins, and this how the add-in checks for updates.
I wish the installtion folder url is grayed out for add-ins so it is clear that it is not really used. But now you know
I am tasked with upgrading a current add-in, and creating a new add-in for Office Excel. The requirements dictate that these solutions be implemented as application level add-ins as opposed to document-level. Each solution is isolated in a separate group within the same proprietary tab on the Office Ribbon.
Is is possible to have multiple application-level add-in solutions or must these be contained within one Visual Studio solution. If they must be contained within a single solution what would be the best practice for tabling (and hiding from the end-user) the solution that is still a work in progress? \
---APPEND---
To clarify, I will define each programmatic entity to be accomplished as a task. Each task is contained within a single group on the Ribbon. All tasks/groups are on the same custom ribbon "tab". How do I release these projects individually to end-users? I should be able to release Task-A to to end-users without worry about the status of Task-B even though they are on the same ribbon tab?
There is no issue in having all the application addin under single solution, I preferred to have it in a single solution in my projects.
With regards to hiding from the end user, if you are going for Click once deployment then just publish the addins which are ready for release. Even if you go for MSI you should be able to do the same by deploying only the addins which are ready to release.
You could also hide the ribbon tabs if they are not completed yet. Hope this answers your question.
Reply to your Appended Question:
In our project we just hide the buttons from the ribbon by setting Visible = False so that the QA or enduser could not be able to see this hidden button. Eventhough there is unfinished/untested code they are never invoked.
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.