Is there a possibility of having a general addin for Microsoft office and the same addin is visible in all Office solutions such as EXCEL, WORD, POWERPOINT etc. We can create individual addins for these applications separately but having a common solution would serve my purpose e.g. if I need to tag some information to all of my documents to be printed.
Any sort of information is highly appreciated.
Thanks.
Is there a possibility of having a general addin for Microsoft office and the same addin is visible in all Office solutions such as EXCEL, WORD, POWERPOINT etc.
Yes
There are two types of Add-In
VSTO Add-Ins (I will use VAI for short in describing them below)
Shared Add-Ins (I will use SAI for short in describing them below)
VAI are application-specific viz, MS Excel, MS Word etc. On the other hand SAI can be written for more than one application i.e can be shared between MS Excel, MS Word etc. Also I am sure that you are aware that VAI has only two main methods. One for startup and the other for shutdown. However SAI has to implement different methods for connection, unconnecting, startup and shutdown.
Another thing that is important to note is that since VAI is application specific there is not too much of code involved as compared to SAI. The reason being SAI work across different applications and hence you need to extra code to distinguish which application is currently calling your Add-in.
I prefer VAI because it lets me use additional programming "shortcuts" and useful objects not available in a Shared Add-in. Not that these are cannot be used in SAI but then you will have to specifically create them. An unnecessary added work if I may say so.
And the last that I can think of is the deployment. They both have a different deployment method.
Hope this clears the concept of a VAI and SAI
Related
I have three addins that do roughly the same thing, but one is for Outlook 2010, one for 2013 and one for 2016.
I've been researching for a couple days how to (and if it is at all possible to) make it so I have only one that would install on the three versions of Outlook.
I know that the add-in for Outlook 2016 uses a few objects (and maybe events) that don't exist in Outlook 2010, but I'm pretty sure that's not that bad, that I could just verify the version when the start-up event fires and go from there ?
I'm very new at VSTO Add-Ins, so I haven't yet tried anything, but from what I read, all of them should be able to work on any version, provided a few tweaks?
Problem is: I'm not even sure of that because I've seen a lot of different views on this (people saying it's possible and others saying "hum no, just don't") and even if I was I think what I understood is there might be problems of compatibility because of the PIAs ?
I just have no idea where to go from here, actually.
VSTO allows creating add-ins that support multiple Office versions. Read more about that in the Run solutions in different versions of Microsoft Office article.
Note, you need to use PIAs that correspond to the lowest version of Office supported. In that case, you can make sure no runtime exception is fired by a member which doesn't exist in a new Office version. At runtime, you may check the host application version and use the late-binding technology represented by Reflection in the .net development world, see Type.InvokeMember for more information.
Also, you may consider using Add-in Express. They allow creating version-neutral add-ins out of the box.
I would like to convert Word Document to PDF on my local intranet Server for my company. It Is a good idea to use microsoft.office.interop.word on my project instead of buying very expensive tools that don't support Arabic at all.
I will be happy to hear an expert opinion about this case :)
it depends on your need, Third party libraries would give lots of out of the box features whereas you would need to write a lot of code to achieve the same with PIA. But if you need simple word doc to pdf conversion then PIA should do it for you.
But i would strongly recommend you to go for a wrapper assembly which would help to over come the disadvantages of using PIAs such as,
They are limited to a version, i.e. they only work with one or
certain versions of Office
They cause problems while transferring or installation on other
systems
They offer no protection mechanism in the management of COM proxies
in a nutshell, if you are a using PIA your code might not work for different version of office whereas these wrapper assemblies manage multiple office versions using Late Binding.
You can use NetOffice which I have been using in projects for some time. some of the features of NetOffice are,
Office integration without version limitations
All features of the Office versions 2000, 2002, 2003, 2007, 2010,
2013 are included
Syntactically and semantically identical to the Microsoft Interop
Assemblies
I would not go as far to say that I am an expert here, but I can at least share my journey in hopes that it would save you time and energy.
This can work fairly reliably in limited scenarios, but Microsoft will tell you up front that:
[InterOp on a Server] is not supported and will not scale well
I agree, but for simple stuff... meh.
Your first hurdle is having the correct rights to run interop. Where
to run interop is a challenge for some companies. IMHO, I would not
run it on my intranet server unless I could contain the process with
limited rights (and yes that's doable).
Your next challenge will be with virus's and the vulnerabilities of
MS Word. MS Word must be kept up to date, customers must be able to
deal with documents not getting converted (due to potential virus or
bad macros in the file).
The approach that I use is to run MS Word interop in a service or as a workflow. You need to expect to queue these requests and write your app as such. The service would work in the background and have limited rights other than to run MS Word, open a file and "Save As" PDF format (plus what ever other business logic you require). You would scale by adding more services/workflows on new servers (one interop service per machine)
When run in this manner, I have rarely had issues. I hope this helps.
I want to support all Office suites in one application using Office Interop.
I was able to do this in Visual Basic by making use of CreateObject()?
The problem was that I wasn't able to see the functions up-front and had to jump around between docs to get it done (Due to Object being used).
If I use a factory pattern and have an implementation for each version of Office, would it work?
Example:
Factory->ABaseOffice GetImplementation(string office_version)
Returns an instance of ABaseOffice which is implemented by Office2000 and OfficeXP.
This way if a new Office version comes out I just have to write the speciffic code for it and not be bothered about the previous versions or depending on 3rd party software.
I don't want to follow the COM/Interop - Supporting Multiple Versions route.
yes - in theory this works... the problem is that you definitely can't reference different versions of the Interop-DLLs in the same project... so you will still have to use the late binding approach for the implementations of the ABaseOffice interface
UPDATE - as per comments:
In theory the described option (see http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx) would allow for adding those references... several reasons not to do so:
these are much more than 2 versions of Interop DLL
the DLL name ist the same IIRC (which poses a problem not addressed in that article!)
the result would be really hard to understand/maintain/debug
I am using Excel 2007. I have C# code written in a separate binary. The code uses static classes and static methods on the classes. I have a reference to the DLL in my VSTO Excel Worksheet project. What do I have to add or modify to get this to work?
My C# code looks like this:
using System;
using System.Collections.Generic;
using Microsoft.Office.Interop.Excel;
using System.Runtime.InteropServices;
namespace FooStatistics
{
[ComVisible(true)]
public static class Statistics
{
public static int Count(Range range)
{
return range.Count;
}
I want to be able to put a formula into an Excel cell that looks like this:
=FooStatistic.Statistic.Count(A1:A10)
Or whatever.
I've seen this but it appears to be for non-static classes in Excel 2003. I can't believe the integration is not better by now.
I've looked at a lot of StackOverflow questions on this. They don't appear to provide native integration (many say, "Use X open source library") and, ominously, many are not accepted by the OP. I am not looking for, "Make it into a COM object and call it from VBA."
So I'm looking for:
Excel 2007
code in C# DLL
call from Excel cell as UDF
native integration
So here's another StackOverflow link, in which two responders say:
As far as I know, you cannot directly create UDFs in VSTO.
VSTO has no support for creating Excel UDFs. Automation Add-Ins can be created in .Net, and seem to be the Microsoft approved way of doing it.
This is a question from June 2009. Is this true -- in 2009 you have to expose your .NET components as COM servers to get callable UDFs for Excel?
If these are your four requirements -- (1) Excel 2007, (2) code in C# DLL, (3) call from Excel cell as UDF, (4) native integration -- then, yes, this can be done, and pretty easily. One of the best tutorials on how to do this is Eric Carter's article Writing user defined functions for Excel in .NET.
If you additionally want your code be hosted via VSTO, then I am virtually certain that you are required to use a VBA wrapper in this case. See Paul Stubbs' article How to create Excel UDFs in VSTO managed code where he uses a VBA add-in to expose VBA UDFs, which in turn call his Managed UDFs written in VSTO.
To be honest though, for Excel UDFs, I would simply avoid the use of VSTO. VSTO is a great designer for managed COM add-ins, allowing you to easily add Ribbon controls and the like. But it is of no help for UDFs (and in fact, does not even support it). So my advice is to create a managed automation add-in, as per Eric Carter's article, and drop the VSTO requirement.
If you do this, you will have no problems, I promise. :-)
Mike
Hugh,
I understand your desire for a 'native' solution, rather than to "Use X open source library". But even VSTO does not seem very 'native' to Excel.
Your requirement is exactly what lead me to develop ExcelDna (http://exceldna.codeplex.com) after finding the Automation add-ins inadequate. The support for Automation Add-Ins has not improved in recent Excel versions, whereas the .xll add-in API (that ExcelDna uses) has seen updated support in recent versions, now supporting multi-threaded recalculation, and with async calls coming in Excel 2010.
Even though ExcelDna is an extra part to introduce into your solution, you'll be pleased at the result. Sadly there has been no clear direction from Microsoft on managed UDF add-ins, or any sign of support for this in VSTO, but in practice doing it with ExcelDna is easy, light-weight and it works very well.
Govert
# hughdbrown: just follow the example in Erics article. If you do that it will work.
No you can't use static class. your instaniating a .net class with a COM wrapper (registering it for com interop).
We have an Excel 2002/XP based application that interacts with SQL 2000/5 to process fairly complex actuarial calculations. The application performs its function well, but it's difficult to manage.
We're trying to create a "controller" application or service that can manage and monitor these various instances of Excel (start/stop/process commands etc) but it's a bit of an InterOp nightmare unfortunately.
Does anyone have a good (i.e. working) example of doing something like this in VB.Net or C#?
Don't do it!
We tried for weeks to get something like that to work and it simply does not behave as advertised. Don't even start - give up immediately!
The only options that you really have is a heavy server-side MOSS based implementation - Excel (Web) services (they call it something like that). Windows based COM Excel interop is pretty much dead and will be replaced by MOSS.
The other option is to use SpreadsheetGear. It is actually a fantastic product
It is lightlingly fast
The engine is separate from the UI so you can use it to do Excel stuff server side (with no office installed)
Fairly cheap
Has an API similar to the existing Excel COM api so moving code across is relatively easy
It all depends on the formulas that you need in your spreadsheet. Have a look at the formula list for Spreadsheet Gear and if there is a match go for it.
Interop works fine except that you always end up with references to Excel objects that aren't released, so Excel instances won't close. The following KB article explains why:
http://support.microsoft.com/default.aspx/kb/317109/EN-US/
You can avoid the problem if you have very carefully written code for a limited set of Interop scenarios. But in the general case it's very difficult to get it working reliably.
You might want to take a look at this product: http://www.spreadsheetgear.com/products/spreadsheetgear.net.aspx
It's all managed code and direct .NET libraries. No InterOp headaches. I haven't used it myself, but I've heard very good things from people in the finance world.
We have written a service that controls a single instance of Excel 2003. We never managed to get Excel instances to close cleanly, so we start one instance when the service is first accessed and use only that, serializing client requests.