COM Interop.NET в Windows 7 64Bit дает мне головную боль
.NET, взаимодействующая с COM до сих пор всегда, работала вполне приятно. Так как я обновил до Windows 7 I, не заставляют мои COM-объекты.NET больше работать.
Мой COM-объект так же легок как:
namespace Crap
{
[ComVisible(true)]
[Guid("2134685b-6e22-49ef-a046-74e187ed0d21")]
[ClassInterface(ClassInterfaceType.None)]
public class MyClass : IMyClass
{
public MyClass()
{}
public void Test()
{
MessageBox.Show("Finally got in here.");
}
}
}
namespace Crap
{
[Guid("1234685b-6e22-49ef-a046-74e187ed0d21")]
public interface IMyClass
{
}
}
блоком является отмеченный ComVisible также.
Я регистрирую использование блока
regasm /codebase /tlb "path"регистры успешно (администраторский режим). Я попробовал regasm 32 и 64 бита. В оба раза я получаю ошибку
"Наклон компонента ActiveX создает объектное Дерьмо. MyClass", использующий этот vbscript:
dim objReg
Set objReg = CreateObject("Crap.MyClass")
MsgBox typename(objReg)
fuslogvw не дает мне подсказок также. Тот COM-объект работает отлично над моей машиной Vista 32 битов.
Я не понимаю, почему я не смог погуглить решение для той проблемы.. я - действительно единственный человек, который когда-нибудь входил в ту проблему?
Рассмотрение OleView, я вижу свой объект, регистрируется успешно. Я могу создать другие COM-объекты также.. это только не работает с моими собственными.
Спасибо, Kevin
2 ответа
Я не специалист по C#, но вот пример, который я преобразовал из VB.net. Обратите внимание, мне пришлось убедиться, что у меня есть одно пространство имен на уровне проекта, а затем этот класс в проектах VB. Я понимаю, что в проектах C# все по-другому.
[ComClass(MyClass.ClassId, MyClass.InterfaceId, MyClass.EventsId)]
public class MyClass {
// These GUIDs provide the COM identity for this class
// and its COM interfaces. If you change them, existing
// clients will no longer be able to access the class.
public const string ClassId = "f58411e1-1689-4bf3-a0e1-b49f479e28ba";
public const string InterfaceId = "f4a575c6-62d2-44eb-af0f-f5b2bb65ad51";
public const string EventsId = "ad56e4f9-3512-4233-aae4-7d1c2457c08f";
// A creatable COM class must have a Public Sub New()
// with no parameters, otherwise, the class will not be
// registered in the COM registry and cannot be created
// via CreateObject.
public SalePayStatus() : base()
{
}
}
Если я беспокоюсь о COM, я всегда сначала проверяю реестр, чтобы убедиться, что соответствующие записи были созданы. Я обнаружил, что версионность и установка MSI вызывают проблемы, особенно удаление (не очищает реестр) или повторная установка и MSI с .net COM объектами, который перезаписывает существующую COM запись, вызывают всевозможные проблемы.
Я вообще считаю, что нужно внимательно относиться к x64 и x32 сборкам .net DLL. Например, вам придется явно ссылаться на C:\Windows\SysWow64\ или C:\Windows\System32\ версии VBS движка.
Наконец, если вы используете VBS в ASP веб сайте на x64 сервере с x32 COM .net компонентом, то вам нужно убедиться, что расширенная опция IIS 7 Application Pool Is 32 bit application правильно установлена True/False.
Спасибо! Не знал, что есть 2 реестра, о которых я должен позаботиться ... пора было перейти на 64-битную Win7, я думаю :)
Спасибо.
Для всех, кто сталкивается с той же проблемой: wscript (клиент, который обычно выполняет файлы vbs) выполняется в 64-битном режиме => 64-битный RegAsm должен использоваться.
Другие распространенные клиенты, такие как Excel, выполняется в 32-битном режиме => будет использоваться 32-битный RegAsm.
Visual Studio выполняется в 32-битном режиме => Регистр для COM-взаимодействия регистрирует только COM-объект в 32-битном реестре.
Единственное, что мне теперь нужно выяснить, это как убедиться, что программа установки VS регистрирует обе версии