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.
Related
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 want to know whether my add-in is running in Word, Excel or Powerpoint. I need a solution that works in the desktop version of the applications (but preferably for the online version as well).
Is this somehow possible?
The reason I'm asking is twofold:
I want to style the add-in app in the colors of the host application.
I submit the document to a webservice. I want to provide a filename as well and need to know if I should postfix with .docx, .xlsx or .pptx.
There isn't a straightforward way to determine the current host. I would also discourage going down the "single manifest, multiple hosts" path in the first place. As the APIs have matured, more and more functionality has become host specific. The most obvious examples being ExcelAPI and WordAPI.
This isn't to say you should build multiple web apps, just that you should maintain multiple manifests. Each manifest can specify a distinct "landing page" where you can make some session level settings that tell the rest of the App which host it's talking too.
The other benefit of this approach is you can be more selective about which Add-in Commands you declare and where in the ribbon they show up. In some cases you might have functions available in Excel that don't show up at all in Word or PowerPoint.
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.
I'm making a Word 2007 add-in with C# 4.0 in Visual Studio 2010. I need an Access 2007 database (a .accdb file) to be placed in the data directory by the clickonce installer. Unfortunately, the file is getting put elsewhere, so the application can't find it at runtime. I've seen various articles refer to using the Application Files dialog on the Publish tab of the project properties to mark the file as a data file, but I have no Application Files button for some reason.
Any idea how to make the Application Files dialog appear, or some other way to manually mark my .accdb file as a data file?
In the Solution Explorer, if you set the file's property to be Copy to Output Directory = Copy Always. Then when you go to Application Files they should default as a Data File.
However, since this is your database I would consider looking at make it safe across updates so you might consider this post.
See http://msdn.microsoft.com/en-us/library/dd465298.aspx
By the way, "Application Files" button should be on the project properties' Publish tab.
VSTO Applications do not have the Application Files button available, and you can't set the file types specifically. If your file is not being deployed to the data directory and you want it to be, rename it with a file extension that is marked by ClickOnce as data. This includes .xml, .mdb, and .mdf. Otherwise, the file is deployed with the VSTO application and will be in the same location as the rest of the files.
The location of the deployment files for a VSTO application can be discovered programmatically this way:
System.Reflection.Assembly.GetExecutingAssembly.CodeBase
You might want to move the database, though, because unless you deploy it as data, it will be lost when an update is performed. Or you can check out this article about where to put your data to keep it safe from ClickOnce updates.
I was able to get things to work by using the Mage tool as described here:
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx
The trick with MageUI is it's open file dialog assumes you want to open a manifest associated with a .exe; a vsto project has a .dll, so the manifest doesn't appear in the files list by default, which was really tripping me up.
Basically, this process is a pain because you have to remember to do it manually. I don't know if there's a way to make this part of the build (maybe a post-build step? But this is really a post-publish step).