I want to develop addins for Office (Outlook,Word and Excel). The code will be almost the same. The difference is only for retrieve a document (mail for Outlook, document for Word,graphic/chart for Excel.
Should I develop 3 addins and therefore I will have 3 installations for my users. Or can I develop only 1 addin and add a condition somewhere?
Yes, that is possible. You possibly need 3 different AddIn classes, since every platform has it's own format and parameters and you might want to deviate some logic, though there is nothing to stop you integrating the three add-ins in one.
Another option is to make a class library that only uses the general Office assembly, and include that library into your other projects.
For the deployment: you can't use ClickOnce out of the box for that, since ClickOnce only supports a single Office program per installation. You can tweak the installation though, as explained on this article on MSDN: Deploying Multiple Office 2010 Projects in One Package.
VSTO doesn't supoport creating multi-host add-ins. The possible ways are:
Develop an add-in which implements IDTExtensibility2 interface without VSTO.
Use third-party tools such as Add-in Express that support creating multi-host add-ins.
Adding multiple AddIn classes to the extisting VSTO based add-ins is not a convinient way to go. At least, you will not be able to debug the code
Related
I am writing an application that do Excel 2013 Interop.
My first step was to add the reference using the add reference > com panel. But the build on my jenkins failed because Office is not installed on the server.
It is out of the question to install Office on the server but I looked for Office 2013 PIA (like suggested on this post and so many other on the internet), but I could not find it.
So I ended up installing the nuget package for it. It was fine except that it does not install the Microsoft.Office.Core dll required for example to add picture to a worksheet... And I need that feature...
Do you know where I can find the Microsoft.Office.Core.dll or the
Office 2013 PIA?
Or do you have any other solution that could do the trick without
rewriting all the code that currently works?
Recommend you to use OpenXml, which is easy-to-use and will not require you to install Office.
You could add agents (one or more) that are Windows machines with the necessary libraries installed, then configure the master node to only run builds that are specifically assigned to it.
Then you don't need to install the Excel 2013 development environment on your server, and your build environment will more closely represent the user environment.
Refer to How to set up new Jenkins slave (where "slave" is the out of favor term for an agent)
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a possible workaround you may consider using the Open XML SDK if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office. Or just any third-party component designed for the server-side execution (for example, Aspose).
Is it possible to create an VSTO add in for multible office applications?
Can I outsource the functions i want to have for every application and then create an Add-in for every application? If yes, is there a better way to achieve this?
I recommend making a solution with an add-in project for each Office application.
Then add a class library project to the solution and reference that from each of the add-on projects.
That way you can centralize code used in all add-ins.
If you need to interact with the active application or document, you can detect the type of the calling object and typecast it to the relevant application/document type.
Yes - you can just put your common functions into a shared DLL, just like any other application. Since each VSTO project targets a different application structure and potentially UI paradigm, I'd recommend having different VSTO projects in a single solution, and a shared assembly holding the common code.
VSTO doesn't support creating multi-host add-ins. You need to create separate projects for each host and use a class library for the shared code base.
Note, Add-in Express allows creating multi-host COM add-ins. So, a single add-in project can be run in multiple hosts. It comes from the IDTExtensibility2 interface. I don't know why VSTO creators didn't provide such feature to developers.
VSTO itself doesn't provide such an option. If you want to get single project for all application you can use shim add-in. That makes possible to run add-in in all applications from the same dll. The only issue -- your code need to handle what application started to call it to run separate logic or to call specific office API functions.
I have created a PowerPoint add-in using C# VSTO and using msi installer for the deployment.
The Problem is that on every system at my end(all Windows 7 Enterprise edition), the plug-in is working fine, but on users' machines(Windows 7 Pro) either the ribbon is not visible or the events are not working.
My concern is, am I missing something which I need to take care of during the development?
Thanks
This is one of the reasons that VSTO deployment is a pain. You have to understand every dependency of your application and the dependencies of your dependencies and then make sure you cover all of them for every version, flavor and bitness of windows and office that you can think of. Then you come to find out that a user has a Click To Run version of Office installed that generally doesn't support AddIns anyways.
VSTO Lessons Learned
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
There are so many possible failure points in the chain that no one could possibly tell you the cause of your problem. A lucky guess perhaps but that would be it. To date I've created VSTO installers for 6 companies and even with my background knowledge and prebuilt templates they are still labor intensive projects because of the test surface that is involved.
Is it possible to create a portable VSTO application ? (e.g without setup.exe, without admin rights, without clickonce, etc.)
Any vsto solution requires that:
The .net framework is installed on the target machine
The VSTO runtime is installed on the target machine
If you don't have those installed already the answer to your question is: No
If you define those as prerequisites then there are 2 kind of vsto solutions. It can be either a document based solution or an office add-in.
Document based solutions have the assemblies along side of the document and get automatically loaded with the excel file. There is no seperate setup required so you could call those 'portable' (depending on what your prereqs are).
Real office add-ins require registry keys to be created. I don't think there is any way you could get those running without some sort of setup/install procedure
For more information about document level solutions and how they are dealt with on runtime look here
A few months back I put together a simple proof-of-concept piece of software for a small firm with an idea for a document editing tool. The company wanted this tool to be integrated into Microsoft Word, understandably, to maximize its accessibility to the average user.
I essentially wrote the underlying library with all of the core functionality as a C# project, and then used VSTO to get it running inside of Word. It felt like a bit of a duct tape solution, really; but then, I have (practically) zero experience developing tools for integration with MS Office, and it was only a proof of concept anyway.
Well, the firm was quite pleased with my work overall, and they're looking to move from "proof of concept" to the real deal. Fortunately, as I said, the core functionality is all there and will only need to be somewhat tweaked and enhanced. My main concern is figuring out how to put together an application that will integrate with MS Word in a clean and polished way, and which can be deployed easily in accordance with a regular user's expectations (i.e., simply running an install program and voila, it's there in Word).
I seem to remember reading somewhere that nobody uses VSTO for real professional projects. Is this true? False? What are the alternatives? And what are the tips and gotchas that I should be aware of before getting started on this issue of MS Word integration?
One of the main issues with deployment of VSTO solutions has been the total deployment size. You have
your solution
the VSTO Runtime version of the project
the .NET Framework version of the
project
the Primary Interops
This could very easily turn your simple and efficient solution into 40-50MB for someone to have to download. Corporate enviroments are somewhat easier to deploy in, but commercial grade software is tougher.
This is partially solved now in VSTO 2010 with a sort of "only the components you're actually using" Primary Interop deployment. This and other things to make deployment easier, such as One-Click, are certainly a reason to consider VSTO 2010. There are some good intros to this on Channel 9.
Commercial products using VSTO are not unheard of though - StoryboarderPro was written in VSTO and is popular in the eLearning industry.
I also remember reading that VSTO was not ideal for commercial software. Internal software is another matter and it has finally made inroads (at least in my organization).
I believe the biggest argument has to do with legacy versions of Office. VSTO only supports as far back as Office 2003. In addition, VSTO required dependencies have been painful to distribute in the past, although this lessens over time with new Windows releases.
For example, my latest project requires the following (assuming, but verifying .Net framework 3.5 is installed):
VSTO Runtime 3.0
VSTO Runtime 3.0 SP1
Microsoft Office 2007 Primary Interop Assemblies
Hotfix for Office (KB976477) - All users get the application-level add-in