COM компоненты : Программирование для всех. Языки программирования, программирование баз данных, технологии. Статьи для програмиста скачать бесплатно учебники книги документация форум : Статьи

На сегодняшний день в мире насчитывается большое количество разработчиков, создающих приложения с использованием технологии COM. И по всей видимости, COM будет оставаться наиболее приемлемой платформой для реализации программных решений еще некоторое время, учитывая вложенные средства в разработку и обучение. Однако, принимая во внимания некоторые существенные недостатки COM и проблемы, возникающие при разработке приложений, Microsoft усовершенствовала компонентную модель программирования и механизм выполнения кода в своей новой платформе .NET с целью устранения существующих ограничений COM и повышения уровня совместной интеграции приложений. К недостаткам COM можно отнести: сложность разработки и поддержки приложений, а также сложность изучения. Стоит подчеркнуть, что Microsoft не отказывается от COM, данная технология будет существовать одновременно с .NET, реализуя базовые сервисы, к примеру, сервис доступа к данным (OLEDB), потому как управляемый код, при всех его преимуществах в большинстве случаев проигрывает неуправляемому по эффективности выполнения и потребляемой памяти. К тому же COM получит дальнейшее развитие в следующих версиях Windows. Соответственно будет обеспечена хорошая интеграция приложений на базе различных технологий. О планах Microsoft относительно .NET известно с июня 2000 года, многие из продуктов семейства .NET к настоящему времени находятся на стадии beta тестирования. Поэтому уже сегодня необходимо учитывать особенности новой платформы и планировать переход на нее.

Данная статья адресована разработчикам, создающим COM компоненты, которые в последствии могут быть использованы в управляемом коде. В основе статьи лежит документ "Building .Net Friendly COM Components" ("Создание дружественных для .NET COM компонентов"), в котором Microsoft дает рекомендации относительно взаимодействия управляемого кода .NET с COM компонентами. Проще говоря, статья рассматривает создание дружественных для .NET COM компонентов.

Статья преследует следующие цели:

Изложить основы взаимодействия .NET Runtime с COM
Научиться использовать существующие COM компоненты в приложениях для .NET Runtime
Выявить ключевые момент использования COM, которые могут привести к затруднительным ситуациям при доступе к COM компонентам из управляемого кода
Попытаться избежать подобных ситуаций, упростив использование COM компонентов в управляемом коде.

Учитывая особенности среды .NET Runtime при проектировании COM компонентов, вы минимизируете или вовсе устраните проблемы совместимости в дальнейшем.

Для начала мы рассмотрим как обеспечивается процесс доступа к COM типам из среды .NET Runtime. Создадим приложение, использующее существующий COM компонент. Затем, углубившись в данную тематику, рассмотрим основные проблемы, возникающие в этом процессе.

Терминология

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

Управляемый код (Managed Code) - код выполняющейся в среде .NET Runtime. Неуправляемый код (Unmanaged Code) - код COM компонентов, стандартных DLL и т.д., то есть код, выполняющийся не в среде .NET Runtime. Управляемый клиент (Managed Client) - клиент, написанный на управляемом коде. соответственно Неуправляемый клиент (Unmanaged Client) - клиент, написанный на неуправляемом коде. Управляемый компонент (Managed Component) - компонент, написанный на управляемом коде, выполняется в среде .NET Runtime, применительно к сборкам (assembly) Неуправляемый компонент (Unmanaged Component) - компонент, написанный на неуправляемом коде, применительно к COM компонентам. Управляемый класс (Managed Class) - класс, реализованный в управляемом коде. Неуправляемый класс (Unmanaged Class) - класс, реализованный в неуправляемом коде COM компонента (кокласс). Управляемый объект (Managed Object) - экземпляр управляемого класса. Неуправляемый объект (Unmanaged Object) - экземпляр неуправляемого класса (coclass).

Определение платформа .NET используется в контексте описания управляемой среды Common Language Runtime - .NET Runtime.

Доступ к COM компонентам из управляемого кода

У каждого разработчика, либо организации, использующей технологии разработки Microsoft, есть определенная база исходного кода, решающая поставленные задачи. Сюда могут входить компоненты от стандартных DLL до COM компонентов среднего уровня, выполняющихся в среде MTS. Подавляющее большинство из существующих компонентов основаны на COM. До недавнего времени технология COM была центром платформы Windows, и все средства разработки для Windows ориентировались в основном на COM. Но с выходом .NET ситуация изменилась. Именно платформу .NET теперь Microsoft представляет в качестве нового средства для построения компонентных решений с межъязыковой совместимостью, приписывая к этому еще десяток превосходств над COM. Естественно, что для плавного перехода Microsoft должна предоставить доступ к существующему коду из новой платформы, собственно, что и было обеспечено Microsoft.

Действительно, .NET Runtime имеет достаточно преимуществ над COM, чтобы перейти на нее. Многие решения, ранее реализуемые с использование COM, теперь более выгоднее, проще и удобнее реализовать на .NET. COM в свою очередь будет использоваться там, где ее применение действительно необходимо. Дабы не отходить от основной темы стати, мы не будет здесь сравнивать COM и .NET, расписывая достоинства и недостатки каждой, а сразу перейдем к делу.

В состав Microsoft .NET Framework входят все необходимые средства для взаимодействия с существующим кодом. В .NET Runtime имеется встроенная поддержка использования COM компонентов из управляемого кода. Доступ к COM компонентам абсолютно прозрачен, в следствии чего, пользователи вашего компонента даже могут не подозревать, что используют его функциональность. Для доступа к классам COM компонентов .NET Runtime поддерживает как раннее, так и позднее связывание.

Далее будут рассмотрены действия, которые необходимо выполнить разработчику для доступа к коду COM компонентов из управляемого кода. Разобравшись в этом процессе и в его ограничениях, вы сможете создавать COM компоненты, которые будет значительно проще использовать в управляемом коде.

Раннее связывание.

Каждый тип, который используется в управляемом коде, независимо от его реализации, требует описание (метаданные). Метаданные представляют особую форму информации о типе. Это похоже на информацию, хранящуюся в библиотеке типов COM компонента. Для типов данных в управляемом коде, метаданные автоматически генерируются компилятором, в процессе компиляции. Чтобы воспользоваться преимуществом раннего связывания (как и в случае управляемых типов) для COM типов также требуются .NET метаданные, описывающие данный тип. Получить .NET метаданные, описывающие COM типы можно, путем преобразования (импортирования) этих метаданных из библиотеки типов COM компонента.

В состав .NET Framework SDK входит утилита командной строки TlbImp.exe (Type Library Importer), предназначенная для преобразования информации о типах из библиотеки типов COM компонента, в метаданные описывающие типы в управляемом коде. По умолчанию утилита находиться в папке: C:Program FilesMicrosoft.NetFrameworkSDKBin

Библиотека типов может находиться либо в одиночном .tlb файле, либо быть встроенной в .dll, .ocx или .exe файл в виде ресурсов. Если у вас нет библиотеки типов, вы можете пойти другим путем (например, воспользоваться поздним связыванием), но значительно легче воспользоваться библиотекой типов.

Следовательно, если вы создаете COM компонент сегодня, настоятельно рекомендуется сразу же создать и библиотеку типов. В дальнейшем это значительно упростит использование вашего компонента в управляемой среде.

Такие средства разработки как Visual Basic и Delphi автоматически генерируют библиотеку типов встроенную в выполняемый или dll файл в виде ресурсов. В Visual C++, вам придется писать библиотеку типов самим на IDL, а затем воспользоваться компиляторам MIDL (Microsoft IDL) для компиляции кода в файл библиотеки.

Для преобразования библиотеки воспользуемся утилитой TlbImp. Утилита генерирует сборку, содержащую метаданные, описывающие COM типы. Для преобразования необходимо выполнить следующую команду:
TlbImp.exe msado15.dll

msado15.dll - файл содержащий библиотеку типов для COM компонента. По умолчанию сгенерированный файл сборки будет иметь имя библиотеки типов (с расширением dll) - adodb.dll. Он содержит описание метаданных для классов и интерфейсов, определенных в библиотеке типов.

В большинстве случаев, преобразование библиотеки типов не вызывает никаких затруднений. Коклассы найденные в библиотеки преобразуются в управляемые классы, а интерфейсы в интерфейсы.

Давайте рассмотрим простой пример. Нижеприведенный IDL код описывает библиотеку WidgetLib. При компиляции нижеприведенного кода получается файл библиотеки типов widget.tlb.

[uuid(…)]
library WidgetLib {
[uuid(…)]
	interface IGadget : IUnknown {
		HRESULT DoSomething();
	}

[uuid(…)]
	coclass Gadget {
		interface IGadget;
	}
}

При желании имя файла генерируемой сборки может быть изменено, но по умолчанию утилита генерирует файл, имя которого соответствует имени библиотеки типов, определенному в IDL коде (но не имени .tlb файла). Это важно заметить, поскольку данное имя получает не только файл сборки, но и пространство имен сборки (namespace).

В управляемом коде на типы ссылаются по имени пространства имен, которое содержит сборка. В данном случае пространство имен будет иметь имя WidgetLib. Это значит, что на класс Gadget можно будет ссылаться как WidgetLib.Gadget. Следовательно, необходимо осмысленно выбирать имя библиотеки типов. Выбирайте имя, которое проще для ссылки, но отличное от имени файла библиотеки типов. Не называйте библиотеку и файл сборки одним именем. Следуйте простому соглашению, добавляйте окончание "Lib" в конец файла. Имя файла сборки и имя пространства имен сборки можно изменить, используя ключ /out как параметр командной строки для утилиты TlbImp.

Импортировав библиотеку типов, часто бывает удобно просматривать метаданные, сгенерированные утилитой TlbImp. ILDasm - это удобное средство для просмотра метаданных .NET сборок. ILDasm представляет собой графическую утилиту, которая отображает метаданные в иерархическом виде. Она генерирует хорошо читаемое описание метаданных. Утилита эквивалентна хорошо известной OleView (отображающая данные библиотеки типов) за одним отличием: она показывает .NET метаданные.

Вам пригодиться эта утилита для просмотра метаданных при определении сигнатуры методов, вызываемых из вашего управляемого кода. На рисунке показана утилита ILDasm, отображающая импортированные метаданные.

Рис 1. Утилита ILDasm.

Использование COM компонентов из программ на C#

Если у вас есть метаданные, описывающие COM типы, то использование этих типов ничем не отличается от использования обычных управляемых типов. Фактически, однажды сгенерировав метаданные, разработчики могут даже не подозревать: типы какого вида они используют: управляемые .NET Runtime типы или неуправляемые COM типы. К примеру, можно написать класс Gizmo на C#, который использует класс Widget, импортируемый из вышеупомянутой библиотеки типов. Ниже приведенный код иллюстрирует пример.

// Gizmo.cs
using WidgetLib
public class Gizmo {
	public void Run ()
 {
		Gadget gadget = new Gadget();
		gadget.DoSomething();
	}
}

Воспользовавшись директивой using WidgetLib , на класс Gadget можно ссылаться, используя только имя класса. Без использования using вы должны были бы ссылаться на него как WidgetLib.Gadget . При компиляции вышеприведенного примера (Gizmo.cs), необходимо добавить ссылку на сборку WidgetLib, используя ключ командной строки /r.
csc Gizmo.cs /r:WidgetLib.dll

Позднее связывание (Late Binding)

Если существующий COM компонент не предоставляет библиотеку типов, для использования его классов можно воспользоваться поздним связыванием. В CLR это обеспечивается посредством использования рефлексии. Рефлексия - это способ работы с динамически связываемыми объектами.

Рассмотрим использования позднего связывания на примере:

using System;
using System.Reflection;

...

Type typ;
Object obj;
Object[] prms = new Object[2];

typ = Type.GetTypeFromProgID("Acme.Slingshot");
obj = Activator.CreateInstance(typ);

prms[0] = 10;
prms[1] = 150;

typ.InvokeMember("aim", BindingFlags.InvokeMethod, null, obj, prms);
typ.InvokeMember("SHOOT", BindingFlags.InvokeMethod, null, obj, null);
...

В этом случае .NET клиенту необходимо получить тип создаваемого объекта. Статический метод GetTypeFromProgID класса Type возвращает тип по программному идентификатору (ProgID). В процессе выполнения этого метода будет загружена соответствующая фабрика класса и создан экземпляр класса __COMObject.

После загрузки типа можно создать его экземпляр при помощи статического метода CreateInstance класса Activator. Далее клиент может вызывать методы COM сервера через метод InvokeMember объекта Type, который в качестве параметров берет имя метода, имя объекта и массив аргументов.

.NET Runtime маршалинг

В процессе выполнения управляемого кода, взаимодействующего с неуправляемыми компонентами приходиться преобразовывать вызовы управляемого кода в вызовы неуправляемого. Эту задачу на себя берет сервис маршалинга .NET Runtime (.NET Runtime Marshaling Services). Соответственно сам процесс преобразования вызовов и типов передаваемых аргументов называется маршалингом.

Проектирование COM компонентов

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

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

Используйте защищенные массивы взамен массивов с переменной длинной. Защищенные массивы (safe array) COM имеют важную характеристику: они содержат описательные атрибуты. В процессе проверки защищенного массива .NET маршаллер может определить размер, границы и тип данных элементов массива во время выполнения. Массивы с переменной длинной (в стиле языка C) не имеют такой характеристики, они не содержат описательных атрибутов. К примеру, сигнатура в неуправляемом коде:
      HRESULT DoSomething(int cb, [in] byte buf[]);
не говорит нам ничего о параметрах массива, кроме типа данных его элементов. Фактически, не возможно отличить массив от любого другого параметра, передаваемого по ссылке. Следовательно, импортируя информацию из библиотеки типов, параметр-массив метода DoSomething не будет преобразован в массив, он будет выглядеть как ссылка на тип Byte.
      public void DoSomething(int cb, ref Byte buf);
Дабы избежать этого, аргумент должен быть записан как SafeArray в неуправляемой сигнатуре.
      HRESULT DoSomething(SafeArray (Byte) buf);
В этом случае при импортировании SafeArray будет преобразован к типу управляемого массива:
      public void DoSomething(Byte[] buf);
Используйте совместимые с автоматизацией типы данных. Сервис маршалинга среды .NET Runtime поддерживает все типы данных совместимые с автоматизацией. Другие же, несовместимые с автоматизацией, типы могут не поддерживаться. Для уточнения, какие именно типы данных поддерживает маршалинг, обращайтесь к спецификации.

Обеспечьте информацию о версии библиотеки типов. При импортировании библиотеки типов версия библиотеки типов распространяется на генерируемую сборку. Управляемые клиенты могут привязываться к конкретной версии сборки или к последней версии сборки. Обеспечив информацию о версии в библиотеки типов, клиенты могут точно выбирать какую версию сборки использовать.

Используйте изоморфные типы. Каждый тип данных является либо изоморфным, либо не изоморфным. Изоморфные типы имеют общее представление, как в управляемом коде, так и в неуправляемом. К примеру, целые типы и типы с плавающей точкой являются примерами изоморфных типов данных. Массивы и структуры образованные из изоморфных типов также изоморфны. Примером не изоморфных типов являются: строки, даты и объекты.

Сервис маршалинга среды .NET Runtime поддерживает как изоморфные так и не изоморфные типы данных, но естественно типы, требующие преобразования в процессе маршалинга не будут преобразованы так же быстро как изоморфные типы. Хотя реально практически невозможно избежать использования не изоморфных типов данных, пользователь должен быть осведомлен о дополнительных потерях производительности связанных с маршалингом неизоморфных типов.

Сервис маршалинга .NET Runtime гарантируют корректное преобразование строк. Строки в среде .NET Runtime представлены в формате Unicode, следовательно, могут быть переданы в неуправляемый код, который более эффективно управляется с аргументами в формате Unicode. Везде где возможно избегайте использования строк в формате ANSI.

Реализуйте интерфейс IProvideClassInfo . Когда интерфейсы, определенные в неуправляемом коде преобразуются в интерфейсы управляемого кода, .NET Runtime маршаллер пытается обернуть интерфейс оберткой специального типа. Сигнатура метода обычно показывает тип интерфейса, но тип объекта, который реализует данный интерфейс сразу не известен. Если тип объекта определить невозможно, управляемая среда обернет интерфейс, используя общую для COM объектов оболочку. Рассмотрим следующий COM метод:

interface INeedSomethng {
HRESULT DoSomething(IBiz *ibiz);
}

После импортирования с помощью утилиты TlbImp метод станет таким:

interface INeedSomething {
void DoSomething(IBiz ibiz);
}

А теперь рассмотрим управляемый объект, реализующий интерфейс INeedSomethiing, и в качестве аргумента в методе использует IBiz интерфейс. Если первый раз интерфейс IBiz встретился в управляемом коде, то маршаллер попытается обернуть интерфейс с использованием оболочки специального типа. Для определения корректного типа оболочки, маршаллер должен знать тип объекта, который реализует данный интерфейс, то есть имя класса. Маршаллер попытается определить тип объекта, запросив его у IProvideClassInfo интерфейса. Если объект реализует IProvideClassInfo интерфейс, маршаллер определит тип объекта и обернет интерфейс в корректную оболочку.

Используйте "краткие" вызовы. Очевидно, что маршалинг выполняемый между управляемым и неуправляемым кодом требует дополнительные затраты времени, в результате чего понижается производительность. Следовательно, нужно попытаться на столько минимизировать количество переходов через границу, на сколько это возможно. Под пересечением границы подразумевается передача аргументов из управляемого кода методам неуправляемого. Очень важно учитывать затраты на маршалинг при проектировании интерфейса, который будет использоваться в управляемом коде.

Поясним сказанное на примере. Допустим у нас имеется определение COM интерфейса IPeople:

interface IPeople : IDispatch {
    [id(0x60030000)]
    HRESULT setLastName([in, out] BSTR* last_name);
    [id(0x60030001)]
    HRESULT setFirstName([in, out] BSTR* first_name);
};

Для установки значений свойств объекта, поддерживающего данных интерфейс необходимо сделать два вызова:

string last_name = "Иванов";
string first_name = "Александр";
People new_people = new People();
new_people.setLastName(last_name);	// первый вызов
new_people.setFirstName(first_name);	// второй вызов
Преобразовав интерфейс к виду:
interface IPeople : IDispatch {
    [id(0x60030002)]
    HRESULT setFullName(
                    [in, out] BSTR* last_name, 
                    [in, out] BSTR* first_name);
};

значение обоих свойств можно установить одним вызовом:

string last_name = "Иванов";
string first_name = "Александр";
People new_people = new People();
new_people.setFullName(last_name, first_name);	//единственный вызов

Класс People реализует интерфейс IPeople. Конечно, лучше установить значение свойств в конструкторе, но в нашем случае пример более нагляден. Если за один раз вы создаете по одному объекту, то вряд ли заметите изменения. Но если вам необходимо создать массив из 1000 объектов People и для каждого установить значение свойств, то вы почувствуете разницу.

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

Давайте соответствующие имена перечислениям и структурам . К элементам перечислений (enum) в управляемом коде всегда ссылаются по имени перечисления и имени элемента. Например:
DaysOfWeek dow = DaysOfWeek.Sunday;
В С++, элементы перечислений входят в глобальную область видимости, следовательно, имя перечисления обычно никогда не используется. Код, в котором используется перечисления с длинными именами, длина перечисления может стать избыточной в сравнении с COM эквивалентом, если не уделить должного внимания выбору имен.

Также важно называть структуры, которые присутствуют в библиотеки типов (даже структура определенная как typedef). Безымянным структурам автоматически назначается MIDL генерируемое имя в библиотеки типов при компиляции. Ссылаясь на типы сгенерированные MIDL компилятором очень неудобно. В результате присваивания имен всем типам, которые присутствуют в библиотеки типов управляемый код, использующий эти типы становиться значительно чище.

Регистрируйте библиотеку типов. В отличии от неуправляемого кода, среде исполнения управляемого кода необходимо иметь доступ к библиотеке типов, описывающей конкретный тип в период выполнения кода для корректного маршалинга вызовов. Чтобы предоставить .NET Runtime доступ к библиотеке типов, библиотека типов обязательно должна быть зарегистрирована. Зарегистрировать библиотеку можно вызовом Win32 API функции LoadTypeLibEx, установив флаг regkind в REGKIND_REGISTER. Или же воспользовавшись утилитой Regsvr32, которая автоматически регистрирует библиотеку типов встроенную в DLL.

Не злоупотребляйте использованием HRESULT. Когда вызовы выполняются между .NET и COM, неудачное возвращение в HRESULT отображается на исключение, генерируемое на возврате вызова произведенном маршаллером. Модель исключений .NET оптимизирована для неисключительных ситуаций. То есть, когда исключение не происходит, потери в производительности свойственные обработке исключений минимальны. С другой стороны, когда исключение происходит, обработка исключения может значительно снизить производительность приложения.

Следовательно, разработчики, где это возможно, должны избегать возвращения неудачи в HRESULT в оповестительных целях. Неудача в HRESULT должна быть зарезервирована только для исключительных ситуаций. Поймите, что чрезмерное использование неудачных результатов в HRESULT может значительно снизить производительность.

Обеспечьте возможность явного освобождения внешних ресурсов. Для некоторых объектов в процессе жизненного цикла иногда требуется использование внешних ресурсов. К примеру, соединение с базой данных, необходимо для обновления набора записей. Освобождение таких ресурсов должно быть выполнено явно, вместо неявного (во время разрушения объекта). Допустим, объект файл должен обеспечить метод Close, вместо того чтобы просто закрывать файл в деструкторе класса или в методе IUnknown.Reslease. Явное освобождение ресурсов очень важно, поскольку ссылки на COM типы содержатся в управляемых объектах, и могут быть уничтожены не сразу после уничтожения объекта.

Обеспечив метод, подобный Close, код реализующий объекта файл сможет освободить внешний файловый ресурс, даже если файловый объект еще не уничтожен.

Не переопределяйте неуправляемые типы. Корректным способом реализации существующих COM интерфейсов в неуправляемом коде является способ, описанный выше - использование утилиты TlbImp. Метаданные, генерируемые TlbImp, будут содержать совместимое определение COM интерфейсов (одинаковые IID, DispID и т.д.)

Альтернативным же способом импортирования интерфейса является - переопределение интерфейса в управляемом коде. Постарайтесь избежать переопределения интерфейса таким образом. Очень трудно вручную определить интерфейс в управляемом коде, который совместим с существующим COM интерфейсом. Единственный способ гарантировать совместимость определений управляемого и неуправляемого интерфейса - это импортировать его из библиотеки типов.

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

Все возвращаемые значения HRESULT вызова COM метода удаляется из сигнатуры управляемого кода и заменяются на параметры [out, retval]. Рассмотрим на примере COM метода:
HRESULT DoSomething ([in] int i, [out, retval] long * retval);
Сигнатура метода преобразуется таким образом public long DoSomething ([in] int i);

Когда вызывается метод DoSomething из управляемого кода, .NET Runtime проверяет возвращаемое значение HRESULT, до возвращения управления вызвавшему коду. Если HRESULT возвращает неудачное значение (определяется по установленным битам), .NET Runtime отображает это значение на класс исключения и генерирует соответствующие исключение. Если же метод в HRESULT возвращает удачное значение, то просто возвращается управление вызвавшему коду с возвратом значения возвращаемое в выходящих параметрах. Сам же HRESULT устраняется. Таким образом становиться очень трудно для управляемых клиентов проверить значение, помещенное в HRESULT в случае успешно выполненного метода. Следовательно, передачу значение в HRESUTL следует избегать везде, где это возможно. То есть вы должны вернуть информацию о статусе вызова через выходной параметр.

Не используйте DLL функции. Библиотека может содержать функции определенные в DLL. Обычно эти функции используются для предоставления информации для входной точки в DLL. Утилита TlbImp не импортирует эти функции.

Не используйте имена членов входящих в System.Object в default - интерфейсе класса (интерфейсе по умолчанию). Когда COM класс (кокласс) импортируются из библиотеки типов, для него создается оболочка управляемого класса. Управляемые клиенты используют эту класс-оболочку для взаимодействия с COM классом. Во время импортирования, методы default-интерфейса кокласса, добавляются к класс-оболочке. Класс-оболочка, как и все классы в .NET наследуется от System.Object. В этом случае может возникнуть конфликт имен между членами родительского класса для класса оболочки (System.Object) и членами default-интерфейса кокласса. Тогда импортируемый метод просто переопределит метод класса System.Object, и вы не получите доступ к членам данного класса (ToString и т.д.). Однако это может быть полезно, в том случае если конфликтующие методы обеспечивают одинаковую функциональность. Но это может привести к проблемам, если заранее не предусмотреть использования методов default-интерфейса. Чтобы предотвратить конфликты имен, избегайте использования следующих имен в default-интерфейсе: Object, Equals, Finalize, GetHashCode, GetType, MemberwiseClone, и ToString.

HTML 5: пять вещей вызывающих особый интер....

HTML 5 — это грядущее обновление гипертекстового языка разметки, основного способа создания контента для размещения его во всемирной паутине. Разработка HTML остановилась в 1999 году, на версии HTML 4.01 и с тех пор web-содержимое изменилось так, что текущие спецификации HTML перестали соответствовать сегодняшним требованиям. HTML 5 нацелен на то, чтобы увеличить функциональную совместимость HTML и соответствовать растущим требованиям разнообразного и смешанного web-контента. HTML 5 так же нацелен на устранение недостатков четвертой версии. В этой статье мы взглянем на 5 новых интересных вещей в HTML 5.

Элемент управления ListView был представлен в .Net Framework 3.5 как замена устаревшему GridView. Новый элемент имеет более расширенный функционал, чем его предшественник, но в тоже время лишен некоторых внутренних механизмов, что впрочем целиком следствие из расширенной универсальности ListView. Среди отличий ListView и GridView можно назвать и гибкую настройку разметки, что позволяет выводить данные не только в табличном виде, но и вообще в любом каком пожелает программист. Благодаря шаблонам ItemTemplate, EditItemTemplate, InsertItemTeplate можно настроить внешний вид при любом из состояний ListView: редактировании или выборе элемента.

Компания Стимулсофт предоставляет для разработчиков мощный набор инструментов для создания отчетов для Microsoft Visual Studio .Net 2005 и 2008; эти инструменты доступны как для Windows Forms, так и для Web Forms. Это генератор отчетов Stimulsoft Reports.Net. Генератор отчетов Stimulsoft Reports.Net имеет ряд особенностей: простая работа с дизайнером отчетов, полная поддержка экспорта в PDF, Word, Excel и многие другие форматы. Crystal Report и Microsoft Reporting Service – очень хорошие программные продукты для повседневной работы, но, если Вам необходимо создать отчеты с поддержкой кросс-табов, drill down, Ajax, штрих-кодов и возможностью подключения одновременно более одного источника данных, то Stimulsoft Reports.Net поможет Вам сэкономить массу времени. Также, данный генератор отчетов позволяет пользователям создавать свои собственные отчеты любой сложности. И все эти особенности делают Stimulsoft Reports.Net хорошим выбором в сфере программных продуктов для Business Intelligence.