Не могу создать экземпляр COM-объекта, написанного на C # из VBA (VB6 нормально) - PullRequest
11 голосов
/ 17 декабря 2008

Используя VS 2008, вот мой COM-объект

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace TestCom
{    
    [Guid("9E5E5FB2-219D-4ee7-AB27-E4DBED8E123E")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    [ProgId("Test9.COMINT")]
    public class TestComClass  
    { 
        public void Init(string userid, string password)
        {
            MessageBox.Show(string.Format("{0}/{1}", userid, password));
        }       
    }
}

Если я соберу это и зарегистрирую на производственном компьютере следующим образом

REGASM /CODEBASE TESTCOM.DLL

В простом приложении VB6 это прекрасно работает

Private Sub Form_Load()
  Dim o As Object
  Set o = CreateObject("Test9.COMINT")
  o.Init "A", "B" 
End Sub

Этот точно такой же код, вызываемый из VBA в Excel, дает

«ошибка автоматизации» (0x80131700)

Все отлично работает на компьютере разработчика, только не на рабочем компьютере с установленными только .NET и MS Office.

Обновление

Я думаю, что это связано с тем, что платформа .NET не инициализируется должным образом при работе в Excel. Если я использую Filemon, я вижу, что он пропускает поиск MSCORWKS.DLL. Когда я вызываю тот же объект из VBScript, он находит MSCorwks.dll в порядке.

Когда я вызывал CorBindToCurrentRunTime из VBA, чтобы попытаться принудительно загрузить CLR, интересно, что я получаю точно такой же HRESULT (0x80131700), как когда я делаю CreateObject() в VBA.

Поэтому я думаю, что это проблема инициализации фреймворка.

Ответы [ 5 ]

13 голосов
/ 17 декабря 2008

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

Если вы получите это, то будет , потому что COM-сборка на основе .NET не может найти .NET framework

Решение простое. Создайте файл, содержащий следующее

<?xml version="1.0"?>
<configuration>
  <startup>
   <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

Назовите его «Excel.Exe.Config» и поместите в тот же каталог, что и «EXCEL.EXE»

Проблема решена!

2 голосов
/ 08 июля 2010

установка следующего исправления решит эту проблему http://www.microsoft.com/downloads/details.aspx?FamilyID=1b0bfb35-c252-43cc-8a2a-6a64d6ac4670&displaylang=en

1 голос
/ 17 декабря 2008

RC1, я проверил это с вашим кодом из VBScript и из Office 2007 Excel, все работает нормально.

Так как вы можете создать COM-объект из формы VB6, мы должны предположить, что ваша .net Framework в порядке. Можете ли вы исключить проблемы с VBA? Можете ли вы создать файл .vbs и поместить его в него:

Dim o As Object  
Set o = CreateObject("Test9.COMINT")  
o.Init "A", "B"

Сохраните файл и дважды щелкните по нему. Если вы получите сообщение об ошибке, то я думаю, что есть проблема с его регистрацией, если вы не получите сообщение об ошибке, я бы посмотрел на Office и VBA и увидел, что что-то отсутствует или установлено неправильно.

Другой вариант - добавить ссылку на COM-объект и использовать раннее связывание? Я думаю, что вам может понадобиться сначала экспортировать библиотеку типов, но вы сможете добавить ссылку и просто создать новый объект.

0 голосов
/ 23 августа 2011

rc1 является верным в том смысле, что является ошибкой .net, возникающей, когда Office не может решить, какую версию Framework использовать. Тем не менее, Office не создает шатких просто потому, что он избалован выбором. Существует ошибка в том, как Office 2003 взаимодействует с .net 2.0.

Установка исправления от Microsoft ( KB908002 ) является более гибким способом решения проблемы, чем принудительное выполнение Excel в определенной версии .net.

Смотри также: http://www.biopdf.com/guide/trouble_shoot_microsoft_office_2003.php

0 голосов
/ 17 декабря 2008

Это работает для меня из VBA ... Я попробовал это с помощью Word & Excel 2003 (SP3).

Я не уверен, что вы подразумеваете под "производственной" машиной. Потому что это «клиентское» приложение, которое должно выполняться на клиенте с использованием Excel.

Если вы автоматизируете Excel на сервере и запускаете это «взаимодействие» с помощью вызова VBA, у вас возникают проблемы:)

Предполагая, что под производством вы подразумеваете клиентскую машину, на которой пользователь будет использовать шаблон / документ Excel, это следующие указатели:

  1. Убедитесь, что у вас есть соответствующий .Net framework
  2. Что у вас установлены последние пакеты обновлений для Office
  3. Попробуйте выяснить, если это проблема с правами.

Если вы чувствуете себя авантюристом, вы можете использовать обозреватель процессов [с сайта Microsoft sysinternals], чтобы увидеть, какие библиотеки DLL загружены и где именно вы получаете сообщение об ошибке, и сравнить его со списком на вашем устройстве разработчика.

Надеюсь, это поможет.

...