Link to home
Start Free TrialLog in
Avatar of dcr25568
dcr25568

asked on

Using a C# library in Excel (Calling C# functions in VBA or Excel Spreadsheet)

I am porting a legacy pricing engine to C# and I would like to expose this newly created library to Excel spreadsheet users.  I've looked on the EE board and see that there have been questions like this in the past:

https://www.experts-exchange.com/questions/20515723/Using-C-to-Build-a-COM-Add-In-Function-as-an-Excel-Worksheet-function.html?query=excel+worksheet+function&searchType=topic

Lets assume for now that my class is very simple:

using System;

namespace FinLibary.FI
{
      public class Bond
      {
            private double _Coupon;

            public Bond()
            {
            
            }
            public double Coupon
            {
                  get
                  {
                        return(_Coupon);
                  }
                  set
                  {
                        _Coupon = value;
                  }
            }
      }
}

Could someone point me in the best direction for getting this class exposed to an Excel user?

I'd like to allow the user to call this library from VBA (so I'll need a declaration and a wrapper). For now, lets just assume that all I want to do is return the "Coupon" property from the Bond Class.  

I am more interested in the methodology/approach/syntax for bulilding/registering/referencing the DLL , declaring the C# class and Calling it from VBA.  I've done something similar in the past w/ C/C++, but not since .NET.  Its been awhile and I'm hoping that there is a simple approach out there.

I've looked at using the Microsoft Office System Project templates in VS2003 and the Extensibility project Templates.  Unlclear to me what value the Office Sytem Project templates have in this case.  It would be nice just to be able to have this class libary available for multiple purposes (calling it from a Web project, command line interface and Excel), so keeping the library clean is important to me.

I'd eventually like produce an XLL for pure spreadsheet users (beyond the scope of this question) as well as a DLL for VBA users, but for now I would settle for a DLL that I could have VBA users call.

I have a lot of legacy code here and I am eager to get moving on this, so I am setting the point value high to encourage those of you who have been through this to give me a hand.

Much appreciated.  Would be happy to clarify if anyone out there has questions.

Thanks.
ASKER CERTIFIED SOLUTION
Avatar of vascov
vascov
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of dcr25568
dcr25568

ASKER

Thanks.  This is a good start for me and I appreciate the quick turnaround.

You commented that "To make it VBA friendly, you should be using the System.Runtime.InteropServices namespace in order to make it COM friendly."

Curious if you meant that I should chage the namespace to System.Runtime.InteropServices or should I just add:

using System.Runtime.InteropServices;

i'd like to keep the namespace clean and keep it standard with the rest of my library.  Does it make more sense to write a wrapper in C# that uses the System.Runtime.InteropServices namespace and implement an interface to the FinLibrary.FI C# library?

Thanks.
DCR, you can keep you namespaces :)

I meant to say that you could be using the attributes within the System.Runtime.InteropServices namespace. These include attributes to control what is visible or not, as well as which progids, Dual interfaces, event interfaces, etc... your com objects should have. There are also some more advanced attributes that can control how the data is "transformed" from COM <-> .NET.
(have a look at this page to see the attributes i'm speaking about:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemRuntimeInteropServices.asp?frame=true)

Rest assured, you can keep your namespaces :)

HTH