Немного шокирует, что эта штука будет работать :)
using System; using System.Runtime.InteropServices; namespace ConsoleApplication1 { class Program { static void Main(string[] args) { // ухты !!! IFoo i = new IFoo("Hello"); i.Print(); Console.WriteLine(i.GetType()); Console.ReadLine(); } [Guid("40DCF1C3-C39D-4BB0-B967-1391C56E2852")] [CoClass(typeof(Foo))] [ComImport] interface IFoo { void Print(); } class Foo : IFoo { private string _message; public Foo(string message) { _message = message; } public void Print() { Console.WriteLine(_message); } } } }К интерфейсу (во время компиляции!) "подвязывается" экземпляр дефолтового класса (что-то типа Activator.CreateInstance(Type.GetTypeFromClsid(GUID OF COCLASSTYPE)), и дальше все работает так, будто бы мы явно создавали экземпляр конкретного класса. Вникать историю развития COM особого желания нету, но пример забавный. К сожалению, трудно представить реальное применение этой фичи.
3 комментария:
Вот, например, нету в Framework клаcса работы с сетевыми дисками такого как WScript.Network, тогда можно его по GUID вызвать, это конечно неудобно (удобней Createbject), но не уверен что все COM- объекты можно привязать по наименованию. Хотя тогда не понятно чем .NET будет от скрипта отличаться. Я конечно в .NET не эксперт, но иногда формочками балуюсь 4fun.
Вот, например, нету в Framework клаcса работы с сетевыми дисками такого как WScript.Network, тогда можно его по GUID вызвать, это конечно неудобно (удобней Createbject), но не уверен что все COM- объекты можно привязать по наименованию. Хотя тогда не понятно чем .NET будет от скрипта отличаться. Я конечно в .NET не эксперт, но иногда формочками балуюсь 4fun.
Спасибо за пример. То, что это можно использовать для работы с COM - понятно. Меня сама конструкция new Interface приколола:) Имхо, это синтаксический сахар, который только сбивает с толку.
Отправить комментарий