Call dll from excel

Доступ к библиотекам DLL в Excel

Относится к: Excel 2013 | Office 2013 | Visual Studio

Вы можете получить доступ к функции или команде DLL в Microsoft Excel несколькими способами:

с помощью модуля кода Microsoft Visual Basic для приложений (VBA), в котором функция или команда была сделана доступной с помощью выражения Declare;

через лист макросов XLM, используя функции CALL или REGISTER;

непосредственно с листа или из настроенного элемента в пользовательском интерфейсе.

В этой документации не рассматриваются функции XLM. Рекомендуется использовать любой из двух остальных подходов.

Для доступа к функции или команде непосредственно с листа или из настроенного элемента в пользовательском интерфейсе необходимо сначала зарегистрировать ее в Excel. Сведения о регистрации команд и функций см. в статье Доступ к коду XLL в Excel.

Вызов функций и команд DLL из VBA

Вы можете получать доступ к функциям и командам DLL в VBA с помощью оператора Declare. В случае этого оператора предусмотрен один синтаксис для команд, а другой — для функций.

Синтаксис 1: команды

Синтаксис 2: функции

Необязательные ключевые слова Public и Private определяют область импортированной функции (весь проект Visual Basic и модуль Visual Basic соответственно). Имя — это имя, которое вы хотите использовать в коде VBA. Если оно отличается от имени в библиотеке DLL, необходимо использовать указатель Alias «aliasname» и предоставить имя функции, экспортируемое библиотекой DLL. Для доступа к функции DLL с помощью ссылки на порядковый номер DLL необходимо предоставить псевдоним, который является порядковым номером с префиксом #.

Команды должны возвратить void. Функции должны возвращать типы, которые VBA может распознавать с помощью ByVal. Это означает, что некоторые типы легче возвращаются за счет изменения имеющихся аргументов (строк, массивов, определяемых пользователем типов и объектов).

VBA не может проверить совпадение списка аргументов и возвращаемого значения в модуле Visual Basic со значениями, закодированными в DLL. Это необходимо внимательно проверить самостоятельно, поскольку ошибка может привести к сбою Excel.

Если аргументы команды или функции не передаются с помощью ссылки или указателя, они должны стоять после ключевого слова ByVal в объявлении arglist. Когда функция C/C++ принимает аргументы указателя или функция C++ принимает аргументы ссылки, они должны передаваться ByRef. Ключевое слово ByRef можно пропустить в списке аргументов, так как оно используется по умолчанию в VBA.

Типы аргументов в C/C++ и VBA

Следует помнить об указанных ниже фактах при сравнении объявлений типов аргументов в C/C++ и VBA.

Тип String в VBA передается как указатель на структуру BSTR байтовых строк в режиме ByVal и как указатель на указатель в режиме ByRef.

Тип Variant в VBA, содержащий строку, передается как указатель на структуру BSTR строк Юникода из двухбайтовых знаков при передаче в режиме ByVal и как указатель на указатель в режиме ByRef.

Integer VBA — это 16-битный тип, эквивалентный signed short в C/C++.

Long VBA — это 32-битный тип, эквивалентный signed int в C/C++.

VBA и C/C++ допускают определяемые пользователем типы данных (применяются операторы Type и struct соответственно).

VBA и C/C++ поддерживают тип данных Variant, заданный для C/C++ в файлах заголовка Windows OLE/COM как VARIANT.

Массивы VBA — это объекты OLE SafeArrays, определенные для C/C++ в файлах заголовка Windows OLE/COM как SAFEARRAY.

Тип данных Currency в VBA передается как структура типа CY, определенная в файле заголовка Windows wtypes.h, в режиме ByVal и как указатель на него в режиме ByRef.

В VBA элементы данных в определяемых пользователем типах данных упаковываются с учетом 4-байтовых границ, тогда как в Visual Studio по умолчанию они упаковываются с учетом 8-байтовых границ. Поэтому необходимо заключить определение структуры C/C++ в блок #pragma pack(4) … #pragma pack() , чтобы избежать несовпадения элементов.

Ниже приведен пример определений эквивалентных пользовательских типов.

В некоторых случаях VBA поддерживает более широкий диапазон значений, чем Excel. Тип данных Double в VBA соответствует требованиям IEEE и поддерживает субнормальные числа, которые в настоящее время на листе округляются до нуля. Тип Date в VBA представляет даты от 1 января 0100 года, которые можно задать с помощью отрицательных сериализованных значений дат. Excel поддерживает сериализованные даты не меньше нуля. Тип Currency в VBA (64-битное масштабированное целое число) позволяет добиться точности, не поддерживаемой 8-байтовыми значениями Double, и поэтому не имеет совпадений на листе.

Excel передает только значения Variant указанных ниже типов в определяемую пользователем функцию VBA.

Тип данных VBA	Битовые флаги типа Variant C/C++	Описание
Double	VT_R8
Boolean	VT_BOOL
Date	VT_DATE
String	VT_BSTR	Строка байтов OLE Bstr
Диапазон	VT_DISPATCH	Ссылки на ячейку и диапазон
Переменная, содержащая массив	VT_VARIANT VT_ARRAY	Литеральные массивы
Ccy	VT_CY	64-битное целое число, масштабированное для достижения точности 4 знака после запятой.
Переменная, содержащая ошибку	VT_ERROR
VT_EMPTY	Пустые ячейки или пропущенные аргументы

Вы можете проверить тип переданного значения Variant в VBA с помощью VarType, если функция не возвращает тип значений диапазона при вызове с использованием ссылок. Чтобы определить, является ли Variant объектом ссылки Range, используйте функцию IsObject.

В VBA можно создавать Variant, содержащие массивы переменных, назначая свойство ValueRange для Variant. Ячейки в исходном диапазоне, отформатированные с использованием стандартного денежного формата для действующих региональных параметров, преобразуются в элементы массива типа Currency. Ячейки, отформатированные как даты, преобразуются в элементы массива типа Date. Ячейки, содержащие строки, преобразуются в Variant BSTR с расширенными символами. Ячейки, содержащие ошибки, преобразуются в Variant типа VT_ERROR. Ячейки, содержащие значения True или False типа Boolean, преобразуются в объекты Variants типа VT_BOOL.

В Variant значение True сохраняется как -1, а False — как 0. Числа, не отформатированные как даты или денежные суммы, преобразуются в Variant типа VT_R8.

Аргументы строк и переменных

Excel поддерживает внутреннюю работу со строками Юникода с расширенными символами. Когда определяемая пользователем функция в VBA объявлена как принимающая аргумент String, Excel преобразует передаваемую строку в байтовую строку в соответствии с языковым стандартом. Чтобы функции передавалась строка Юникода, определяемая пользователем функция в VBA должна принимать Variant вместо аргумента String. При выполнении этого условия функция DLL сможет принимать строку Variant BSTR с расширенными символами VBA.

Чтобы из DLL возвращались строки Юникода в VBA, следует изменить имеющийся аргумент строки Variant. Для этого следует объявить функцию DLL как принимающую указатель на Variant в коде C/C++, а также объявить аргумент в коде VBA как ByRef varg As Variant . Память предыдущей строки следует освободить, а значение новой строки, созданное с использованием строки OLE Bstr, работает только в DLL.

Чтобы байтовая строка возвращалась в VBA из DLL, следует изменить имеющийся аргумент BSTR байтовой строки. Для этого следует объявить функцию DLL как принимающую указатель на BSTR в коде C/C++, а также объявить аргумент в коде VBA как ByRef varg As String.

Чтобы избежать проблем, связанных с памятью, необходимо обеспечить обработку только строк, которые передаются этими способами из VBA, используя функции строки OLE BSTR. Например, необходимо обеспечить вызов SysFreeString для освобождения памяти перед перезаписью переданной строки, а также SysAllocStringByteLen или SysAllocStringLen, чтобы назначить место для новой строки.

Вы можете обеспечить создание сообщений об ошибках на листе Excel как Variant в VBA при помощи функции CVerr с аргументами, как показано в приведенной ниже таблице. Ошибки на листе также могут быть возвращены в VBA из DLL при помощи Variant типа VT_ERROR, а также с указанными ниже значениями в поле ulVal.

Ошибка	Значение Variant ulVal	Аргумент CVerr
#NULL!	2148141008	2000
#ДЕЛ/0!	2148141015	2007
#ЗНАЧ!	2148141023	2015
#ССЫЛКА!	2148141031	2023
#ИМЯ?	2148141037	2029
#ЧИСЛО!	2148141044	2036
#Н/Д	2148141050	2042

Обратите внимание на то, что значение Variant ulVal эквивалентно значению аргумента CVerr с шестнадцатеричным значением x800A0000.

Вызов функций DLL непосредственно с листа

Вы не сможете получить доступ к функциям DLL Win32 с листа, если не используете, к примеру, интерфейсы VBA или XLM либо не сообщите Excel заранее о функции, ее аргументах и типе возвращаемого значения. Этот процесс называется регистрацией.

Ниже приведены способы, которыми можно получить доступ к функциям DLL на листе.

Объявите функцию в VBA, как показано выше, и получите доступ к ней через пользовательскую функцию VBA.

Сначала обеспечьте вызов функции DLL с помощью CALL на листе макросов XLM, а затем — доступ к ней с помощью определяемой пользователем функции XLM.

Используйте команду XLM или VBA, чтобы вызвать функцию XLM REGISTER, которая предоставляет сведения, необходимые Excel для опознания функции при ее вводе в ячейке листа.

Преобразуйте DLL в XLL и зарегистрируйте функцию с помощью функции xlfRegister C API после активации XLL.

Четвертый подход изолированный: код, регистрирующий функции, и код функций хранятся в одном объекте кода. Изменение надстройки не включает изменение листа XLM или модуля кода VBA. Чтобы сделать это с широкими возможностями управления, оставаясь в рамках возможностей API C, необходимо преобразовать DLL в XLL и загрузить получившуюся надстройку с помощью диспетчера настроек. Это позволяет Excel вызывать функцию, предоставленную библиотекой DLL, при загрузке или активации надстройки, из которой затем можно зарегистрировать все функции, которые содержит XLL, и выполнять другие задачи инициализации DLL.

Вызов команд DLL непосредственно из Excel

Команды DLL Win32 недоступны напрямую из диалоговых окон и меню Excel без интерфейса, например VBA, или без предварительной регистрации команд.

Получать доступ к командам DLL можно следующими способами:

Объявите команду в VBA так, как описано выше, и получите к ней доступ с помощью макроса VBA.

Сначала обеспечьте вызов команды DLL с помощью CALL на листе макросов XLM, а затем — доступ к ней с помощью макроса XLM.

Используйте команду XLM или VBA, чтобы вызвать функцию XLM REGISTER, которая предоставляет сведения, необходимые Excel для опознания команды при ее вводе в диалоговом окне, которое запрашивает имя команды макроса.

Преобразуйте DLL в XLL и зарегистрируйте команду с помощью функции xlfRegister C API.

Как упоминалось ранее в контексте функций DLL, четвертый подход является самым изолированным, так как код регистрации хранится наряду с кодом команд. Для этого необходимо преобразовать DLL в XLL и загрузить получившуюся надстройку с помощью диспетчера надстроек. Регистрация команд таким способом также позволяет присоединить команду к элементу пользовательского интерфейса, например пользовательскому меню, или настроить перехват события с вызовом команды по нажатию определенной клавиши или другому событию.

Приложение Excel обрабатывает все команды XLL, зарегистрированные в нем, как имеющие такой вид:

Excel игнорирует возвращаемое значение, если оно не было вызвано с листа макросов XLM. Если оно было вызвано так, возвращаемое значение преобразуется в TRUE или FALSE. Поэтому следует обеспечить возвращение 1 при успешном выполнении команды и 0 при ошибке или отмене команды.

Память DLL и многочисленные экземпляры DLL

Когда приложение загружает DLL, исполняемый код DLL загружается в глобальную кучу для выполнения, а для его структур данных назначается место в глобальной куче. Windows использует сопоставление памяти, чтобы эти области памяти отображались, как в процессе приложения. Таким образом приложение может получать к ним доступ.

Если второе приложение загружает эту библиотеку DLL, Windows не создает дополнительную копию исполняемого кода DLL, так как эта память доступна только для чтения. Windows сопоставляет память исполняемого кода DLL с процессами обоих приложений. Но при этом Windows выделяет другое место для частной копии структур данных DLL и сопоставляет эту копию только со вторым процессом. Благодаря этому одно приложение не может конфликтовать с данными DLL другого.

Это означает, что разработчикам DLL не следует беспокоиться, что несколько приложений (или несколько экземпляров одного приложения) будут получать доступ к статическим и глобальным переменным и структурам данных. Каждый экземпляр всех приложений получает собственную копию данных DLL.

Разработчикам DLL следует позаботиться о том, чтобы один и тот же экземпляр приложения не вызывал DLL много раз из разных потоков, так как это может привести к состязанию за данные этого экземпляра. Дополнительные сведения см. в статье Управление памятью в Excel.

Источник

The default policy is preventing the CLR 4 from excuting the legacy code from the CLR 2 :

Set clr = New mscoree.CorRuntimeHost

To enable the legacy execution, you can either create the file excel.exe.config in the folder where excel.exe is located:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

Or you can call the native function CorBindToRuntimeEx instead of New mscoree.CorRuntimeHost :

Private Declare PtrSafe Function CorBindToRuntimeEx Lib "mscoree" ( _
    ByVal pwszVersion As LongPtr, _
    ByVal pwszBuildFlavor As LongPtr, _
    ByVal startupFlags As Long, _
    ByRef rclsid As Long, _
    ByRef riid As Long, _
    ByRef ppvObject As mscoree.CorRuntimeHost) As Long

Private Declare PtrSafe Function VariantCopy Lib "oleaut32" (dest, src) As Long


''
' Creates a .Net object with the CLR 4 without registration.  '
''
Function CreateInstance(assembly As String, typeName As String) As Variant
  Const CLR$ = "v4.0.30319"

  Static domain As mscorlib.AppDomain
  If domain Is Nothing Then
    Dim host As mscoree.CorRuntimeHost, hr&, T&(0 To 7)
    T(0) = &HCB2F6723: T(1) = &H11D2AB3A: T(2) = &HC000409C: T(3) = &H3E0AA34F
    T(4) = &HCB2F6722: T(5) = &H11D2AB3A: T(6) = &HC000409C: T(7) = &H3E0AA34F

    hr = CorBindToRuntimeEx(StrPtr(CLR), 0, 3, T(0), T(4), host)
    If hr And -2 Then err.Raise hr

    host.Start
    host.GetDefaultDomain domain
  End If

  VariantCopy CreateInstance, domain.CreateInstanceFrom(assembly, typeName).Unwrap
End Function

I’m not sure if this was just a coincidence or because I posted related question. SO showed me your question and I think I could also contribute something.

When working with VBA and DLL, most solutions that I’ve seen so far is telling me to register the DLL and make it com/gac visible. If you are doing this in your PC that’s absolutely fine but if you are distributing your VBA application, you don’t really want to install DLLs in their system. You might not have permission or you don’t really want to go through install/uninstall process or messing with referencing issues.

However you can load dlls dynamically using some windows APIs.

DLL

Now the question is how to access .NET dll from vba? if your clients have mixed os architecture x86 x64 you need to handle this accordingly. Lets assume we are working on 32bit office/Excel.

If you create a .NET dll and would like to access it from VBA it will throw an error message similar to «Can’t find the dll entry point». thankfully Robert Giesecke has created an abstract wrapper which will allow you to create simple DLL consumable via VBA.

A template can be found here.

All you have to do

1. Create a new class project in visual studio
2. Set the project platform either x86 for 32bit and otherwise
3. Create your methods within a main class.
4. create another class which will return your main class as object (is returning to vba)
5. (follow the template from his website)

Lets assume you have followed his template and created a test method as following.

[ComVisible(true), ClassInterface(ClassInterfaceType.AutoDual)]
public class YOUR_MAIN_CLASS
{
    [return: MarshalAs(UnmanagedType.BStr)]
    public string FN_RETURN_TEXT(string iMsg)
    {

        return "You have sent me: " + iMsg + "...";
    }
}

and your unmanagedexport class:

static class UnmanagedExports
{
    [DllExport]
    [return: MarshalAs(UnmanagedType.IDispatch)]
    static object YOUR_DLL_OBJECT()
    {
        return new YOUR_MAIN_CLASS();
    }
}

Preparing to access the dll from vba side

Add the DLL to your root folder:

#If VBA7 Then 
    Public Declare PtrSafe Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As LongPtr
    Public Declare PtrSafe Function YOUR_DLL_OBJECT Lib "YOUR_DLL.dll" () As Object
#Else
    Public Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal strFilePath As String) As Long
    Public Declare Function YOUR_DLL_OBJECT Lib "YOUR_DLL.dll" () As Object
#End If

Now It’s all about loading the dll and creating & accessing objects it in vba.
that would be:

LoadLibrary (FN_APP_GET_BASE_PATH & "YOUR_DLL.dll")
dim mObj as object
set mObj = YOUR_DLL_OBJECT()
debug.print mObj.FN_RETURN_TEXT("Testing ..")

the output should be

"You have sent me: Testing ....."

Advantages
I personally don’t like installing and referencing dlls. By following above template, you don’t need to reference anything, you don’t need to install anything just load and work with your the DLL with full freedom.

NOTE: I assume the dll/.net code is yours and you can compile it again with above templates to.

I had success with above template and created a .NET non-blocking notifications for vba you can have a look here: non-blocking «toast» like notifications for Microsoft Access (VBA)

Here’s your solution, tested for .NET 2.0 and .NET 4.0, 32 bit and 64 bit, courtesy of Soraco Technologies.

The solution proposed below uses late binding and does not require registration of the .NET assemblies.

Declarations

Add the following declarations to your project:

#If VBA7 Then
Private Declare PtrSafe Function GetShortPathName Lib “Kernel32.dll” Alias “GetShortPathNameW” (ByVal LongPath As LongPtr, ByVal ShortPath As LongPtr, ByVal Size As Long) As Long
Private Declare PtrSafe Function SetDllDirectory Lib “Kernel32.dll” Alias “SetDllDirectoryW” (ByVal Path As LongPtr) As Long
Private Declare PtrSafe Sub LoadClr_x64 Lib “QlmCLRHost_x64.dll” (ByVal clrVersion As String, ByVal verbose As Boolean, ByRef CorRuntimeHost As IUnknown)
Private Declare PtrSafe Sub LoadClr_x86 Lib “QlmCLRHost_x86.dll” (ByVal clrVersion As String, ByVal verbose As Boolean, ByRef CorRuntimeHost As IUnknown)
#Else
Private Declare Function GetShortPathName Lib “Kernel32.dll” Alias “GetShortPathNameW” (ByVal LongPath As Long, ByVal ShortPath As Long, ByVal Size As Long) As Long
Private Declare Function SetDllDirectory Lib “Kernel32.dll” Alias “SetDllDirectoryW” (ByVal Path As Long) As Long
Private Declare Sub LoadClr_x64 Lib “QlmCLRHost_x64.dll” (ByVal clrVersion As String, ByVal verbose As Boolean, ByRef CorRuntimeHost As IUnknown)
Private Declare Sub LoadClr_x86 Lib “QlmCLRHost_x86.dll” (ByVal clrVersion As String, ByVal verbose As Boolean, ByRef CorRuntimeHost As IUnknown)
#End If ‘ WinAPI Declarations

' Declare variables
Dim m_myobject As Object
Dim m_homeDir As String

Initialization

You must initialize the m_homeDir variable to the path where the .NET assemblies are located.

For example, if you install the .NET assemblies in the same folder as the Excel or MS-Access files, you should initialize m_homeDir to:

Excel: m_homeDir = ThisWorkbook.Path

Access: m_homeDir = CurrentProject.Path

.NET Object Creation

Add the following code to your project.

Private Function GetMyObject(dllPath As String, dllClass As String) As Object
    Dim LongPath As String
    Dim ShortPath As String

    LongPath = “\?” & m_homeDir
    ShortPath = String$(260, vbNull)

    PathLength = GetShortPathName(StrPtr(LongPath), StrPtr(ShortPath), 260)
    ShortPath = Mid$(ShortPath, 5, CLng(PathLength – 4))

    Call SetDllDirectory(StrPtr(ShortPath))
    Dim clr As mscoree.CorRuntimeHost

    If Is64BitApp() Then
        Call LoadClr_x64(“v4.0”, False, clr)
    Else
        Call LoadClr_x86(“v4.0”, False, clr)
    End If

    Call clr.Start

    Dim domain As mscorlib.AppDomain
    Call clr.GetDefaultDomain(domain)

    Dim myInstanceOfDotNetClass As Object
    Dim handle As mscorlib.ObjectHandle

    Set handle = domain.CreateInstanceFrom(dllPath, dllClass)

    Dim clrObject As Object
    Set GetMyObject = handle.Unwrap

    Call clr.Stop
End Function

Private Function Is64BitApp() As Boolean

    #If Win64 Then
        Is64BitApp = True
    #End If
End Function

Instantiate the .NET object

Now you are ready to instantiate your .NET object and start using it. Add the following code to your application:

m_homeDir = ThisWorkbook.Path 

m_myobject = GetMyObject(m_homeDir & “yourdotnet.dll”, “namespace.class”)

The first argument is the full path to the .NET DLL.

The second argument is the fully qualified name of the requested type, including the namespace but not the assembly, as returned by the Type.FullName property.

Required DLLs

The solution requires deployment of 2 DLLs that are responsible for hosting the .NET CLR. The DLLs are expected to be deployed in the same folder as your Excel or MS-Access file.

The DLLs can be downloaded from Soraco’s web site: https://soraco.co/products/qlm/QLMCLRHost.zip

Licensing LGPL-2.1

We hereby grant you the right to use our DLLs as long as your application does not compete directly or indirectly with Quick License Manager. You can use these DLLs in your commercial or non-commercial applications.

Here is a canonical answer on the 3 main methods to call .Net from Excel (or VBA).

All three ways work in .Net 4.0.

1. XLLs

The 3rd party vendor Add-In Express offer XLL functionality, however its free and easy to use Excel-DNA the author is here https://stackoverflow.com/users/44264

Here is an extract from the Excel-DNA page: https://excel-dna.net/

Introduction

Excel-DNA is an independent project to integrate .NET into Excel. With Excel-DNA you can make native (.xll) add-ins for Excel using C#, Visual Basic.NET or F#, providing high-performance user-defined functions (UDFs), custom ribbon interfaces and more. Your entire add-in can be packed into a single .xll file requiring no installation or registration.

Getting Started

If you are using a version of Visual Studio that supports the NuGet Package Manager (including Visual Studio 2012 Express for Windows Desktop), the easiest way to make an Excel-DNA add-in is to:

Create a new Class Library project in Visual Basic, C# or F#.
Use the Manage NuGet Packages dialog or the Package Manager Console to install the Excel-DNA package:

PM> Install-Package Excel-DNA

Add your code (C#, Visual Basic.NET or F#):

using ExcelDna.Integration;
public static class MyFunctions
{
    [ExcelFunction(Description = "My first .NET function")]
    public static string SayHello(string name)
    {
        return "Hello " + name;
    }
}

Compile, load and use your function in Excel:

=SayHello("World!")

---

2. Automation AddIns

This article by Eric Carter shows how to do it, the article is missing heaps of images so I am copy / pasting the entire article and have recreated the images for preservation.

REF: https://blogs.msdn.microsoft.com/eric_carter/2004/12/01/writing-user-defined-functions-for-excel-in-net/

Excel enables the creation of user defined functions that can be used in Excel formulas. A developer must create a special kind of DLL called an XLL. Excel also allows you to write custom functions in VBA that can be used in Excel formulas. Unfortunately, Excel does not support or recommend writing an XLL that uses managed code. If you are willing to take your chances that your XLL might not run in current or future versions of Excel, there are solutions available that enable this scenario—search the web for “managed XLL”.

Fortunately, there is an easier way to create a user defined function that doesn’t require you to create an XLL dll. Excel XP, Excel 2003, and Excel 2007 support something called an Automation Add-in. An Automation Add-in can be created quite simply in C# or VB.NET. I’m going to show you an example in C#.

First, launch Visual Studio and create a new C# class library project called AutomationAddin for this example.

Then, in your Class1.cs file, enter the code shown below. Replace the GUID with your own GUID that you create by using Generate GUID in the Tools menu of Visual Studio.

using System;
using System.Runtime.InteropServices;
using Microsoft.Win32;

namespace AutomationAddin
{

  // Replace the Guid below with your own guid that
  // you generate using Create GUID from the Tools menu
  [Guid("A33BF1F2-483F-48F9-8A2D-4DA68C53C13B")] 
  [ClassInterface(ClassInterfaceType.AutoDual)]
  [ComVisible(true)]
  public class MyFunctions
  {
    public MyFunctions()
    {

    }

    public double MultiplyNTimes(double number1, double number2, double timesToMultiply)
    {
      double result = number1;
      for (double i = 0; i < timesToMultiply; i++)
      {
        result = result * number2;
      }
      return result;
    }

    [ComRegisterFunctionAttribute]
    public static void RegisterFunction(Type type)
    {
      Registry.ClassesRoot.CreateSubKey(GetSubKeyName(type, "Programmable"));
      RegistryKey key = Registry.ClassesRoot.OpenSubKey(GetSubKeyName(type, "InprocServer32"), true);
      key.SetValue("", System.Environment.SystemDirectory + @"mscoree.dll",RegistryValueKind.String);
    }

    [ComUnregisterFunctionAttribute]
    public static void UnregisterFunction(Type type)
    {
      Registry.ClassesRoot.DeleteSubKey(GetSubKeyName(type, "Programmable"), false);
    }

    private static string GetSubKeyName(Type type, string subKeyName)
    {
      System.Text.StringBuilder s = new System.Text.StringBuilder();
      s.Append(@"CLSID{");
      s.Append(type.GUID.ToString().ToUpper());
      s.Append(@"}");
      s.Append(subKeyName);
      return s.ToString();
    }  
  }
}

With this code written, show the properties for the project by double clicking on the properties node under the project in Solution Explorer. Click on the Build tab and check the check box that says “Register for COM Interop”. At this point you have an extra step if you are running on Windows Vista or higher. Visual Studio has to be run with administrator privileges to register for COM interop. Save your project and exit Visual Studio. Then find Visual Studio in the Start menu and right click on it and choose “Run as Administrator”. Reopen your project in Visual Studio. Then choose “Build” to build the add-in.

Now launch Excel and get to the Automation servers dialog by following these steps:

1.  Launch Excel and click the Microsoft Office button in the top left corner of the window. 
   

2.  Choose Excel Options.
   

3.  Click the Add-Ins tab in the Excel Options dialog. 
   

4.  Choose Excel Add-Ins from the combo box labeled Manage.  Then click the Go button.
   

5.  Click the Automation button in the Add-Ins dialog.
   

You can find the class you created by looking for AutomationAddin.MyFunctions in the list of Automation add-ins:

Now, let’s try to use the function MultiplyNTimes inside Excel. First create a simple spreadsheet that has a number, a second number to multiple the first by, and a third number for how many times you want to multiply the first number by the second number. An example spreadsheet is shown here:

Click on an empty cell in the workbook below the numbers and then click on the Insert Function button in the formula bar. From the dialog of available formulas, drop down the “Or select a category” drop down box and choose “AutomationAddin.MyFunctions.

Then click on the MultiplyNTimes function as shown here:

When you press the OK button, Excel pops up a dialog to help you grab function arguments from the spreadsheet as shown here:

Finally, click OK and see your final spreadsheet as shown here with your custom formula in cell C3.

---

3. Calling .Net from Excel VBA

REF: Calling a .net library method from vba

Using the code from the Automation.AddIn project we can easily call the MultiplyNTimes function from Excel VBA.

First Add a reference to the DLL from Excel, to do this you will need to be in the VB Editor. Press Alt + F11, then click Tools menu and References:

Select the AutomationAddIn DLL:

Add VBA code to call the .Net DLL:

Sub Test()

Dim dotNetClass As AutomationAddIn.MyFunctions
Set dotNetClass = New AutomationAddIn.MyFunctions

Dim dbl As Double
dbl = dotNetClass.MultiplyNTimes(3, 2, 5)

End Sub

And hey presto!

---

Please note if you’re working with Classes in C# you will need to mark them with ClassInterface, with an Interface marked with ComVisible = true: Use CLR classes from COM addin in Excel VBA?

Finally there are some excellent MSDN articles about Excel and .Net by «Andrew Whitechapel» — google them