Как получить Сервер COM для Excel, записанного в VB.NET, установленном и зарегистрированном в списке Серверов автоматизации?

Я попытался развернуть надстройку автоматизации на выходных. Оказывается, это чрезвычайно сложно (для вас это не сюрприз!), И я не смог найти в Интернете абсолютно никаких источников о том, как это сделать правильно. Никто.

Существуют источники, описывающие, как использовать RegAsm , но нет ни одного, как правильно использовать проект установки для регистрации надстройки автоматизации, которая немного отличается от стандартной надстройки COM.

К счастью, мне удалось ее решить. Вот что я узнал:

Если вы читали некоторые статьи о том, как создать и зарегистрировать надстройку автоматизации C #, вы: Вы увидите, что вам нужно добавить раздел реестра с именем Programmable в HKEY \ _CLASSES \ _ROOT \ CLSID \\ {GUID} , где {GUID} - это GUID вашего COM-видимого класса.

Обычно это делается путем добавления пары методов, отмеченных ComRegisterFunctionAttribute и ComUnregisterFunctionAttribute . Хорошим примером этого является статья Габана Берри Написание пользовательских функций Excel на C # :

// C#:

[ComRegisterFunctionAttribute]
public static void RegisterFunction(Type type) {
  Registry.ClassesRoot.CreateSubKey(GetSubKeyName(type));
}

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

private static string GetSubKeyName(Type type) {
  string s = @"CLSID\{" + type.GUID.ToString().ToUpper() + @"}\Programmable";
  return s;
}

В переводе на VB.NET это работает так:

'VB.NET:

<ComRegisterFunctionAttribute()> _
Public Shared Sub RegisterFunction(ByVal type As Type)
    Registry.ClassesRoot.CreateSubKey(GetSubKeyName(type))
End Sub

<ComUnregisterFunctionAttribute()> _
Public Shared Sub UnregisterFunction(ByVal type As Type)
    Registry.ClassesRoot.DeleteSubKey(GetSubKeyName(type), false)
End Sub

Private Shared Function GetSubKeyName(ByVal type As Type) As String
    Dim s As String = ("CLSID\{" _
                + (type.GUID.ToString.ToUpper + "}\Programmable"))
    Return s
End Function

Метод, отмеченный ] ComRegisterFunctionAttribute автоматически вызывается RegAsm при регистрации сборки для этого класса. Метод, отмеченный атрибутом ComUnregisterFunctionAttribute , автоматически вызывается RegAsm , когда сборка для этого класса отменяется с помощью переключателя / u .

Проблема в том, что что ComRegisterFunctionAttribute и ComUnregisterFunctionAttribute полностью игнорируются при установке через проект установки Visual Studio.

Сначала это кажется удивительным, потому что проект установки Visual Studio работает ] RegAsm с помощью переключателя / regfile для создания файла .REG, содержащего все необходимые ключи реестра. Именно этот файл .REG затем используется, после чего пакет .MSI запускается на сайте клиента.

Из Сборка и развертывание сборки .NET COM Фил Уилсон: Регистрационные записи класса COM? Хорошо, если вы настроили Fusion Log Средство просмотра (Fuslogvw.exe в .NET 2.0 SDK) для записи загрузки сборки, запустите это после сборки вашей установки и вы заметите, что Regasm.exe на самом деле запускается во время сборки вашей установки проект. Однако это не работает любая регистрация. Что происходит, так это Visual Studio запускает Regasm с / regfile параметр для создания файла .reg содержащие записи реестра требуется для получения информации о шаг 1, и этот файл .reg внутренне импортировано в установку проект. Итак, если вы хотите увидеть, что записи о регистрации класса Visual Studio создаст в настройке MSI, вы можете запустить Regasm самостоятельно с / regfile option

Однако при запуске RegAsm с переключателем / regfile я заметил, что переключатель Programmable был не включены. Затем я включил ведение журнала в свои методы, отмеченные атрибутами ComRegisterFunctionAttribute и ComUnregisterFunctionAttribute , и обнаружил, что они оба вызываются при запуске RegAsm без / regfile ], но они не вызываются при запуске с переключателем / regfile , а также не вызываются при запуске через пакет .MSI, созданный проектом установки Visual Studio.

файлы справки для Regasm.exe подтверждают это (выделено мной):

Вы можете использовать параметр / regfile , чтобы сгенерировать файл .reg, содержащий записи в реестре вместо того, чтобы изменения прямо в реестр. Вы можно обновить реестр на компьютере путем импорта файла .reg с Инструмент редактора реестра (Regedit.exe). Обратите внимание, что файл .reg не содержит обновлений реестра, которые могут производиться с помощью определяемого пользователем реестра функций.

Тогда решение состоит в том, чтобы добавить Программируемую клавишу самостоятельно. Это можно сделать следующим образом:

1. В проекте установки откройте редактор реестра. Создайте новый ключ с именем CLSID в HKEY_CLASSES_ROOT , щелкнув правой кнопкой мыши папку HKEY_CLASSES_ROOT , затем выбрав «Новый», а затем «Ключ».
2. Под ключом CLSID добавьте новый ключ с именем вашего GUID, включая фигурные скобки.
3. Под новым ключом GUID, который вы добавили, добавьте ключ с именем Programmable . Вам не нужно вводить никакого значения в этот ключ; однако нам нужно заставить его создать. Поэтому щелкните правой кнопкой мыши программируемую кнопку и выберите «Окно свойств». Затем измените свойство AlwaysCreate на True .

После того, как вы это сделаете, вам больше не нужны методы, отмеченные атрибутами ComRegisterFunctionAttribute и ComUnregisterFunctionAttribute, но я бы все равно оставил их для в тех случаях, когда вы выполняете вход через RegAsm, а не через Setup Project.

На этом этапе вы готовы к развертыванию. Создайте свое решение, а затем щелкните правой кнопкой мыши свой проект установки и выберите «Сборка». Затем вы можете использовать созданные файлы Setup.exe и .MSI для развертывания на клиентском компьютере.

Однако следует учесть еще одно: при добавлении надстройки автоматизации через диалоговое окно надстроек Excel появляется сообщение об ошибке будет показано, что "Mscoree.dll не может быть найден, вы хотите удалить надстройку?" или что-то очень похожее. Это сообщение об ошибке можно проигнорировать, и ваша надстройка будет работать независимо от того, что вы ответите, но это может вызвать тревогу у клиента, устанавливающего вашу надстройку.

Эта ситуация и объяснение того, как ее решить, хорошо описаны в статье Написание пользовательских функций для Excel в .NET Эриком Картером.

Проблема в том, что значение по умолчанию для ключа InprocServer32 просто mscorree.dll , что .NET достаточно, чтобы его найти, но вызывает недовольство Excel. Решение состоит в том, чтобы убедиться, что значение по умолчанию для ключа InprocServer32 включает полный путь к вашей системной директории. Например, в 32-битных окнах он должен читать C: \ Windows \ system32 \ mscoree.dll . Однако этот путь должен варьироваться в зависимости от системы, в которой он установлен. Таким образом, этот путь не должен быть жестко запрограммирован.

Эрик Картер обрабатывает это, изменяя методы, отмеченные ComRegisterFunctionAttribute и ComUnregisterFunctionAttribute , чтобы они были следующими:

// C#: 

[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();
}  

В переводе на VB.NET это эквивалентно:

'VB.NET:

<ComRegisterFunctionAttribute()> _
Public Shared Sub RegisterFunction(ByVal type As Type)
    Registry.ClassesRoot.CreateSubKey(GetSubKeyName(type, "Programmable"))
    Dim key As RegistryKey = Registry.ClassesRoot.OpenSubKey(GetSubKeyName(type, "InprocServer32"), true)
    key.SetValue("", (System.Environment.SystemDirectory + "\mscoree.dll"), RegistryValueKind.String)
End Sub

<ComUnregisterFunctionAttribute()> _
Public Shared Sub UnregisterFunction(ByVal type As Type)
    Registry.ClassesRoot.DeleteSubKey(GetSubKeyName(type, "Programmable"), false)
End Sub

Private Shared Function GetSubKeyName(ByVal type As Type, ByVal subKeyName As String) As String
    Dim s As System.Text.StringBuilder = New System.Text.StringBuilder
    s.Append ("CLSID\{")
    s.Append(type.GUID.ToString.ToUpper)
    s.Append ("}\")
    s.Append (subKeyName)
    Return s.ToString
End Function

Это работает, но имеет ту же самую проблему, когда сборка правильно регистрируется при запуске RegAsm на локальном компьютере, но терпит неудачу при попытке использовать это в рамках проекта установки Visual Studio.

Решение, Опять же, это добавить наши собственные ключи реестра. Однако на этот раз нам нужно будет создать значение по умолчанию, которое будет использовать свойство [SystemFolder] , которое эквивалентно вызову System.Environment.SystemDirectory , используемому в Eric Код Картера, см. Выше.

Для этого добавьте ключ с именем InprocServer32 под ключ CLSID \\ {GUID} , который мы создали ранее. Затем щелкните правой кнопкой мыши новый ключ InprocServer32 и выберите «Создать», затем «Строковое значение». Результатом будет новое значение с именем Новое значение # 1 , но вы будете в режиме редактирования, позволяющем переименовать его. Здесь вы хотите удалить все символы и затем нажать Enter . Удаляя все символы из имени, вы создаете значение по умолчанию, а значок для значения реестра будет автоматически переименован в «(По умолчанию)». Затем щелкните правой кнопкой мыши этот значок значения по умолчанию и выберите «Окно свойств». В окне свойств установите для свойства Value значение «[SystemFolder] mscoree.dll» (без кавычек).

Затем вы можете щелкнуть правой кнопкой мыши на своем Setup Project и выбрать «Build», после чего вы будете готовы к развертыванию.

Осталось только одно, о чем нужно беспокоиться. Если вы устанавливаете Excel 2007 или более позднюю версию, все вышесказанное будет работать на 100%. Однако при установке в Excel 2003 или более ранней версии вам необходимо будет включить следующее:

ИСПРАВЛЕНИЕ: надстройки, смарт-документы или смарт-теги, созданные с помощью Microsoft Visual Studio 2005, не работают в Office

Подробное объяснение того, как его развернуть, дано Диво здесь .

Если вы не примените это исправление, все будет зарегистрировано правильно, и вы даже сможете успешно добавить надстройку автоматизации - вроде все в порядке, - но функции вашего рабочего листа не будут работать, и вы все равно получите #NAME? ошибки в результате. (Но, опять же, вам это не нужно для Excel 2007 и более поздних версий. )

Итак, в конце концов, TLB не имеет значения. Во всех своих тестах я использовал RegAsm без переключателя / TLB и не включал TLB при регистрации через Setup Project. Так что у меня не было проблем с этим в Vista, , у которой есть проблемы при попытке добавить TLB-файл в проект установки .

Я надеюсь, что это поможет, Хью, и, надеюсь, всем, кто может наткнуться на это нить в будущем ...

Майк