We have an existing add-in that we publish to users via click once. We would now like to use this as a vehicle to publish some of our existing C# methods directly into Excel so that the users can call them as a UDF.
For example - I have an assembly called MyAssembly, that has a class called MyClass with a public method called MyMethod. I also have an excel addin which adds some item to the ribbon for some custom functionality. I would now like to publish MyAssembly with my existing addin so that a person who has the addin installed can enter =MyMethod into a cell and have my custom method run.
How would one go about doing this?
I solved this quite comprehensively by using ExcelDna, an open source XLL implementation which is very simple to use, and pretty much avoids the whole COM debacle all together. So far it has matched our requirements perfectly...
http://groups.google.com/group/exceldna
you have not been very verbose about what you want to do. What do you mean with "users can call them"?
If you mean that add-in methods should be exposed to VBA you can find two articles on that here:
http://blogs.msdn.com/andreww/archive/2008/08/13/comaddins-race-condition.aspx
http://blogs.msdn.com/andreww/archive/2008/08/11/why-your-comaddin-object-should-derive-from-standardolemarshalobject.aspx
Related
I have a SAP Business Objects Web 7.5 Add-in in Excel 2007.
The add in itself is made up of a compiled .xll file (CtExcelLinksWeb.xll) and a number of dll's.
A bit of vba shows the xll is registered, and all of its registered functions.
However, when I try to use one of these functions in VBA using Application.Run(), I get
Runtime 1004 - Macro may not be available or may be disabled.
I have tried registering the xll within the same sub (Application.RegisterXLL ()) and upon registering a VBAProject called CtEmpty.csv is created
I want to be able to automate the use of this add-in using VBA as it does long winded repetitive tasks, and then I can work on figuring out how to use the functions
Any help will be appreciated
Are the DLLs on the PATH? It may be that Excel can't load the DLLs that the XLL is dependent upon. Dependency Walker (depends.exe) is a handy tool for troubleshooting this kind of issue.
Also, have you tried using File/Options/Addins to register the XLL, as well as VBA code?
I am trying to evaluate Excel DNA to use it in one of my excel add-in. I use C# functions (.NET 4.0) and want to invoke these functions from Excel. The reason I am interested is, the users of my addin are non-admins and hence would be a breakthrough, if I can find a solution not to do a regasm on my .NET dll, to get my addin working.
I understand that if it is like a worksheet function (with simple return types and arguments), as in: private string Add (int a, double b)
I can easily wrap expose them using excel dna. Also, I understand that, I can also call these simple functions using Application.Run from VBA.
But, if I have a complex type involved in the API and want to use this from VBA then do I require to regasm that assembly and types? example as in this:
private MyType AddLogic (myType1 A, myType2 B)
Or is there any way in Excel DNA, that I can also consume such kinds of functions in VBA without any regasm or regsvr32 ?
Thanks
Mani
You are referring to the built-in COM server support in Excel-DNA. There are a few options, all of them work fine for users without administrator rights.
You can register the COM types at runtime in your AutoOpen - they will then be available late-bound from VBA (so everything in VBA calling those COM types will be 'Variant' and you get no intellisense).
You can register the COM types with regsvr32, using the .xll as your COM server. The Excel-DNA registers its types in the HKEY_LOCAL_USER part of the registry, which the user can always write to.Then the VBA project that uses the COM-exposed types will run even if the .xll add-in is not loaded.
To add type library information for the COM-exposed types, you will have to do the regsvr32 registration, which again works without admin rights, and then you get intellisense etc. in VBA.
In none of these cases do you use RegAsm - which registers managed assemblies for runtime activation - since the native Excel-DNA .xll mediates the COM activation of your .NET types itself.
If you are not interested in providing worksheet functions, ribbons etc. you probably don't need Excel-DNA for this. You can register .NET assemblies for use by non-admin from VBA by just making a .reg script which will right the registry entries in HKEY_LOCAL_USER instead of HKEY_CLASSES_ROOT. I mean to say that the non-admin registration of Excel-DNA is no special magic. The main reason for integration of this feature in Excel-DNA is to ensure that those objects are activated in the same AppDomain as the rest of the Excel-DNA add-in, which is tricky and sometimes important.
I have code that worked in the VSTO version of an Excel Addin
Microsoft.Office.Tools.Excel.ListObject lo = Globals.ThisAddIn.VSTOWorksheet.Controls.AddListObject(r, "lo1");
lo.AutoSetDataBoundColumnHeaders = true;
lo.DataSource = dt; //some DataTable
I was using this API because its declarative databinding syntax. And the Excel.Interop API didn't have methods such as AutoSetDataBoundColumnHeaders..
If I can get Microsoft.Office.Tools.Excel.ListObject imported, how will I resolve the Controls collection on which I call AddListObject without the VSTO stuff inside Excel DNA ?
Any solution would be nice, even if it involves scrapping my code, but in general I'd like to understand when to use which API inside of Excel DNA in order to accomplish this databinding stuff.
VSTO adds some extensions on top of the Excel object model. I have no experience with VSTO, and for stuff like the ListObjects I can't tell where Excel's object model ends and the extended VSTO wrapper objects start.
The boundary is basically this: Microsoft.Office.Interop.Excel can be used from Excel-DNA (so this is the ListObject interface you can use: http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.listobject_members.aspx). Microsoft.Office.Tools.Excel is part of VSTO.
Also, I really have no idea whether the VSTO libraries can be used together with Excel-DNA. The issue would be getting the VSTO libraries initialized and hooked up - it might be tricky.
It might be worth it for you to try to re-implement those object model extensions yourself, on top of the Excel object model. I don't think VSTO is doing anything you couldn't do yourself.
So I want to capture some key-commands in our Docuement-level Excel VSTO addin. I can't seem to find a way to do it, other than to use VBA and have our addin talk to the VBA. Any help/examples would be greatly appreciated.
I am using Excel 2007.
One method involves using the 3rd party solution from Addin-Express. Their product includes the ability to add a keyboard shortcut as a property to the ribbon menu commands.
The other way is to make use of low level keyboard hooks, through some Win32 API's which is generally referred to as windows subclassing. Here is an excellent explanation with code sample of how to do it. Note that the only "extra" thing you need to do to get this code to "work" in VSTO is moving the SetHook() method to the Startup event, and the UnhookWindowsHookEx() method to the Shutdown event.
Check out the article on MSDN here by Stephen Toub.
Finally there is the use of the OnAction property of the Addin class. This method requires the use of some VBA (in terms of a callback method that points back to the underlying .net addin), and works ok so long as you are willing to distribute some VBA in your solution (i.e. a xls or doc w/ vba project, or perhaps a native addin). Note you will also need to mark comvisible = true, and expose the GetAutomationServiceObject method so that your VBA can reference your addin from VBA code.
see here for a thread on it...
You can only do this through API calls to subclass Excel and watch for key commands. This is older, but it still applies.
I'd like to be able to call a function exposed by a VSTO addin from a cell in an excel worksheet. More specifically, if I have a VSTO function Foo() that returns "bar" I'd like to be able to write =Foo() in A1 which evaluates to "bar" on calculation.
Is this possible? What are the key steps I'd need to take?
The prospect of being able to leverage managed code and the VS08 IDE for excel development is very appealing. I thought VSTO would allow me to easily do this but I'm no longer sure. Am I misunderstanding the architecture here? The documentation is a little shoddy.
Excel-DNA (which I develop) is an open-source project that allows you to create user-defined worksheet functions (UDFs) for Excel, as you describe.
With Excel-DNA you can also make full-featured Excel add-ins that include ribbon customization, macros, async function and RTD servers. Excel-DNA uses the native Excel XLL interface to integrate with Excel, so you get very good performance too, compared to solutions based on COM integration.
I don't believe you can do so directly, though you can use a VBA wrapper, see for example http://blogs.msdn.com/pstubbs/archive/2004/12/31/344964.aspx.
You can also use a third party product like ManagedXll to create Excel UDFs in managed code.
I think you can make use of COM Interop.. here is a webpage where I've seen the process described.
http://www.cpearson.com/excel/creatingnetfunctionlib.aspx