Доброго времени суток, господа!
Однажды, разработал дин.библиотеку при помощи ATL (регистрация в реестре, используется как внешняя компонента в 1С). Сейчас появилось желание переписать её, на C# (что-то добавить, что-то убрать), но чтобы также регистрировать в реестре. Подозреваю, что нужно создать библиотеку классов, но что нужно объявить на экспорт (типа DllRegisterServer и т.д.), и что задействовать в проекте?
Заранее благодарен за ответ.

Aximp.exe

The ActiveX Control Importer converts type definitions in a COM type library for an ActiveX control into a Windows Forms control.

В технологии .net регистрация в регистре не применяется. Тут существуют сборки, которые сами описывают в манифесте, в каких компонентах нуждаются.
acutil поможет записать твой компонент в директорию глобальных сборок C:\WINDOWS\assembly.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>и что задействовать в проекте?

Статьи на rsdn: http://www.rsdn.ru/article/dotnet/net2com.xml

Автор(ы): Алексей Дубовцев
Дата: 19.11.2001

Здравствуйте, Аноним, Вы писали:

А>Доброго времени суток, господа!
А>Однажды, разработал дин.библиотеку при помощи ATL (регистрация в реестре, используется как внешняя компонента в 1С). Сейчас появилось желание переписать её, на C# (что-то добавить, что-то убрать), но чтобы также регистрировать в реестре. Подозреваю, что нужно создать библиотеку классов, но что нужно объявить на экспорт (типа DllRegisterServer и т.д.), и что задействовать в проекте?
А>Заранее благодарен за ответ.

Есть одна нерешенная проблема (по крайней мере для меня) при написании COM DLL на C#. Допустим есть DLL, которая написанна на C/С++ и реализует какую то COM библиотеку интерфейсов. Раз есть такая библиотека — значит кто то её уже использует (есть клиенты). Возможно даже используя .NET, или даже используя .NET 2.0.

Теперь, переписав всю эту DLL на C# и даже оставив интерфейс к ней как у старой DLL (это отдельная проблема

Автор: sergey_shandar
Дата: 24.10.05

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

Автор: sergey_shandar
Дата: 16.12.05

).

Выводы:
— нельзя реализовывать старую COM библиотеку переписывая её .NET. Cоздать новую — можно, при этом, .NET клиенты должны будут использовать новую DLL только как .NET, а не как COM.
— даже создав новую DLL с новым интерфесом на .NET и рассказав всем своим клиентам как использовать эту DLL, есть еще проблема совместимости .NET версий. Т.е., если новая DLL будет написанна на .NET 2, то про клиентов использующих .NET 1 можно просто забыть

Автор: sergey_shandar
Дата: 16.12.05

.
— итого: крайне не рекомендую переписывать существующущие COM DLL на .NET если нужна хоть капелька совместимости.

PS: Прежде чем поставить мне минус, посмотрите внимательно, что мои выводы базируются на том, что я смог найти в интернете и в том числе задавая эти вопросы здесь

Автор: sergey_shandar
Дата: 16.12.05

, на которые не было ни одного ответа. Если вы знаете решение описанных выши проблем, буду рад выслушать.

Аттрибуты

System.Runtime.InteropServices.ComRegisterFunctionAttribute()

[System.Runtime.InteropServices.ComUnregisterFunctionAttribute()]

вкупе с regasm.exe помогут