I have a xll file which have a function and I want to call that function from C#.
This xll file is used in excel.any body have idea how to do that?.I tried refrencing the xll file but I am not getting the value.If I open excel like start-->programms-->excel and
in excel if i directly give the function I am getting right value.Same thing If i automate excel in c# and opened excel from Microsoft.Office.Interop.Excel and applied the function I am getting error
You probably won't be able to invoke the function directly because an XLL will expect the Excel interfaces to be driving. You'd have to do some serious faking.
Automating it through Excel will work though.
An xll is just a dll. If you know the signature of the function you want to call, you can call it just like any other function. If you don't know the signature but can load the add-in in Excel, there is a way to get Excel to tell you the signature.
Automation only works if you are running Excel. There is no need for that once you know the signature.
There is a few tools you can use:
XLL Plus
XLL Host
The question has also been asked on MSDN Use XLL from C#, this is the answer:
If it is a COM project, you can add it via the COM tab in the Add reference window.
If you need to create a .NET assembly from the dll, you can try to use Type Library Import tool to create a wrapper around the dll:
tlbimp.exe xll.dll /out:xllnet.dll
If the object does not support COM, but only native calls, you will need to platform invoke the methods using the DllImport attribute. See the Platform Invoke tutorial for more information.
I gave all 3 suggestions a go but didn't have any luck. Given the author of the XLL tool Excel-DNA recommends using a tool I suspect consuming a XLL in a Winform/WPF/Console or Web app is not trivial:
https://stackoverflow.com/a/2865023/495455
Related
Is it possible to unregister methods that I previously registered via ExcelIntegration.RegisterMethods without restarting Excel?
Basically, I'm looking for the opposite of ExcelIntegration.RegisterMethods.
Excel-DNA does not currently let you unregister methods in a loaded add-in. This is just a limitation of the implementation, and how exported functions are hooked up to the native exports of the .xll. You an however unload an entire Excel-DNA add-in, (from another add-in) as long as it only exports UDFs and not ribbons, an RTD server or other COM features.
Another workaround is to re-register the function as "hidden". The new registration will take up another slot in the (fixed-size) .xll export table, but will at least not appear in the worksheet function completion list anymore.
Is there any way I can import an xll into my C# WPF project? I require some of the functions that are usually called via the xll addin in Excel. I have read that xll performs like normal dlls, but sharpdevelop does not seem to be able to read any of its functions and methods. I know the formulas that are usually called in excel, can I access those same functions in my WPF app?
If, and only if :
you know the prototype of the function.
arguments are only primitives C type , (no xloper type).
the function is independent of Excel (does not require to be initialized by excel)
then yes you can call it from C# thanks to DllImport
I have written two addins , 1 for excel and 1 for word. However these addins have a lot of duplicates: Database handling, file handling,array handling which I would like to update 1 place instead of two.
We do have access to sharepoint, and could get access to visual studio. The thing is that people like to use file explorer and find the correct word or excel file, then open it then press a button inside the application which then should do things with the active document.
This is why we haven't written it as a .Net application yet, because that requires that people browse for the file inside the .NET application uless I am mistaken.
Is it possible to make an Addin which works both excel and word, or a dll? AnAnother important thing is that it should be easy to roll out a new version to the user, like stored on a network drive or similar.
Yes it is possible
The Hard Way
You can create a .Net DLL and call it from VBA. In visual studio a lot of people use Unmannaged Exports by Robert Giesecke to create DLLs that don't need to be registered (that way the DLL can be shipped with your document, and as long as it can be found you can use it).
Alternatively you might be able to do it manually as shown here by Hans Passant.
The Easy Way
Once the DLL is created you can declare it in a VBA module the same way you declare any other DLL for Late Binding and then call it from your code.
OR if you're happy to create the DLL and add it as a reference (possibly less portable) you can make it COM visible and register it for COM Interop in Visual Studio; this is probably the easiest way to go because you can then use Early Binding.
This is a walk through that might help: http://www.geeksengine.com/article/create-dll.html
But if you want to store the DLL on a network drive, well it might be that you really want to look at doing it the 'hard way', in which case look here: https://stackoverflow.com/a/5934745/3451115 and here: https://msdn.microsoft.com/en-us/library/bb687915.aspx
I need to create a .lib file from a C# DLL (I think it is C# becuase of this code which calls to the dll https://code.google.com/p/thunder-missile-api/downloads/detail?name=MissileLauncher.cs&can=2&q=) In other word's I need to create a .lib for DreamCheeky Thunder Missile Launcher DLL, which comes with their software .
Now, what I need to do? I need to operate this device using C++. Easiest way is using their own DLL. The above linked code does it in C#.
I tried importing the DLL file into the project C++, but it seems like some methods are missing, specially methods like moveMissileLauncher() which are called in the C# code.
And the best thing is, I might want to move to QT (most probably) so you know, having a .lib is a good idea.
Crating a lib from a managed dll will do no good. You need to use interop
http://msdn.microsoft.com/en-us/library/ms973872.aspx
In your specific case, I would write a C++ lib that exposes the methods you need/want to call and forwards them to the managed C# dll using interop
I would do that in C++/CLI, personally.
A good, more recent article on the options you have is here http://msdn.microsoft.com/en-us/magazine/dd315414.aspx, or look here on SO for COM/.NET interop and you will find plenty of answers.
You want to call managed C# code from your c++ application. Here is tutorial to make someway to call c# code from your c++ application, i have used this method before, and works fine for me.
Okey here's the situation: I've got a microsoft excel macro in vb that I want to call using C#. I've already tried creating a workbook using Microsoft.Office.Interop.Excel, however I don't want to have to run an excel process to run the macro.
So then I thought why not make a vb class library with my code in it so i can still run it and have a clean dll file. It's not needed to keep any sheet related functions since the macro reads a .lua(UTF-8)text file with some advanced regex functions that I just can't get recreated in C#.
Is it possible for me to make the library use interop as well so i can just call the function in my C#? Any examples would be greatly appreciated.
First I assume you are working with VB6 and not VB Script?
I have never worked with VB 6 or earlier, but I think your best be will be to create a COM object and then you can call the COM object from .NET using C#. Here is a quick link I found through BING that I believe will help you get started if this in an option for you.
Walkthrough: Implementing Inheritance with COM Objects (Visual Basic)
I noticed these two statements:
I don't want to have to run an excel process to run the macro
and
the macro reads a .lua(UTF-8)text file with some advanced regex functions that I just can't get recreated in C#
Those two goals are incompatible. The macro relies on excel functions to run. The only way provided by Microsoft to accomplish this is to completely load the Excel app. There is no way to only run the macro.