Работа с компонентами не из .NET

Вспомните, что при компиляции объектов в.NET Framework они должны выдать описываюшие их метаданные. Эти данные используются системой Common Language Lntime (CLR), чтобы загружать объекты без всякого вмешательства разработчика. от вас требуется — это только поместить объекты в каталог /bin. E Впрочем, более старые объекты, которые не были созданы в.NET Framework, та-|>й способностью не обладают. (Их часто называют объектами Component Object toodel (объектная модель компонентов) или СОМ-объектами.) CLR не может автома-Ечески управлять этими объектами или выполнять их автоматическую загрузку, да и Ьт таких метаданных, которые могли бы "рассказать" CLR об этих объектах. Разработчикам приходится регистрировать такие объекты вручную. Для этого используется Ьограмма REGSVR32.exe, которая помешает соответствующую информацию в системный реестр Windows (это такое место, где хранится информация обо всех приложениях и компонентах, которые установлены на машине).

Эти СОМ-объекты не создаются в среде.NET, поэтому с помощью CLR они не управляются и называются неуправляемым кодом. Из-за этого системе ASP.NET сейчас приходится напряженно работать, чтобы разобраться с использованием этих объектов. Кроме того, во время проектирования устанавливать значения СОМ-объектов нельзя.

В ASP.NET до сих пор поддерживается использование этих объектов с помощью метода CreateObject (создать объект) класса HttpServerUtility (серверная утилита HTTP). Названный метод принимает строку, которая описывает местоположение объекта в системном реестре, и использует это местоположение для установки свойств объектов. Эта строка называется progld. Вот соответствующий синтаксис: Server.CreateOb ject(progld)

Например, в страницах классической ASP операции ввода-вывода выполняются с помощью FileSystemObject (объект файловой системы) из библиотеки Scripting (создание сценариев). Этот метод осуществляет некоторые из действий, выполняемых также теми классами, которые вы изучали в 13-й главе, "Чтение и запись файлов на Web-сервере". Чтобы использовать этот объект в своей странице, необходимо применить примерно такой фрагмент:

dim objFSO as object

objFSO = Server.CreateObject("Scripting.FileSystemObject")

Например, в листинге 15.9 показано, как отображать путь к данному файлу. Листинг 15.9. Использование СОМ-объектов______________________________ ,...,,.,..^.

1: <%В Page Language="VB" %> 2:

3: <script runat="server">

4: sub Page_Load{obj as object, e as eventargs)

5: dim objFSO, objFile

6: objFSO = Server.CreateObject _

7: ("Scripting.FileSystemObject")

8: objFile = objFSO.File _

9: (Server.MapPath("../dayl3/log.txt")}

10:

11: IblMessage.Text = objFile.Path

12: end_sub

13: </script>

14: - '

15: <htmlxbody>

16: <asp:Label id="lblMessage" runat="server"/>

17: </bodyx/html>

B строках 6 и 8 соответственно создаются два объекта: Scripting.File SystemObject и Scripting.File. Эти объекты потом можно использовать для выполнения некоторых действий ввода/вывода — таких, например, как отображение полного пути к файлу. Вывод, полученный при выполнении этого листинга, показан на рис. 15.7.

Рис. 15.7. Система ASP.NET поддерживает использование старых, неуправляемых СОМ-объектов

Впрочем, использовать FileSystemObject не слишком интересно, потому что в.NET Framework есть объекты и получше. Это, например, такие объекты, как TextReader (читатель текста) и TextWriter (записыватель текста), которые являются полностью объектно-ориентированными. Кто действительно получает пользу от способности.NET применять СОМ-объекты, так это разработчики, которые уже создали множество специальных СОМ-объектов. Во многих организациях, имеющих собственные Web-узлы, используется несколько СОМ-объектов. Эти СОМ-объекты выполняют операции, аналогичные тем, которые сегодня уже делались с помощью бизнес-объектов. Представляете, какая получилась бы огромная неразбериха, если бы пришлось переписывать все эти СОМ-объекты?

Кроме того, с помощью СОМ-объектов также доступны возможности многих других приложений. Например, в своих страницах ASP.NET вы можете создавать документы Microsoft Word и выполнять с ними различные действия. Такая возможность имеется благодаря СОМ-методам, предоставляемым приложением Word. Все СОМ-объекты этого приложения являются неуправляемым кодом, но их все равно можно использовать в.NET Framework.

j Впрочем, использование СОМ-объектов имеет определенный недостаток.

! Из-за того что нет метаданных, связанных с этими объектами, системе ASP.NET приходится напряженно работать, чтобы определить, данные какого типа объект принимает и отдает назад, и часто этой системе приходится заниматься преобразованием типов данных. Такой процесс называется подгонкой (marshalling). При ее выполнении из-за роста накладных расходов, требуемых на обработку, производительность, наоборот, уменьшается. Поэтому подгонки надо стараться, по возможности, избегать.

К счастью, в комплекте с.NET Framework также поставляется программа, которая может преобразовывать неуправляемые СОМ-объекты в управляемые.NET-объекты. Эта программа, которая называется Type Library Importer (импорт библиотек типов),

аначизирует СОМ-объект и создает соответствующие метаданные, с помощью которых вы можете этот объект использовать в своих приложениях ASP.NET. Тогда каждое такое приложение следует выполнять с помощью файла tlbimp.exe.

Предположим, например, что в ваших страницах ASP.NET надо, не прибегая к подгонке, использовать объект FileSystemObject. Он хранится в файле scrrun.dll, который обычно находится в каталоге c:\winnt\system32. Откройте окно командной строки и перейдите в названный каталог. Затем введите в этом окне следующую команду:

tlbimp scrrun.dll /out:scrrun_net.dll

В результате ее выполнения из СОМ-файла scrrun.dll будет создан другой файл, scrrun net.dll, причем вместе с соответствующими метаданными. Вы должны будете.^видеть нечто похожее на вывод, который показан на рис. 15.8.

Рис. 15.8. Программа tlbhnp.exe импортирует старые СОМ-объекты в систему.NET Framework

Копируйте этот новый файл в ваш кэш сборки (c:\inetpub\wwwroot\tyaspnet21days\bin). Теперь в предыдущем листинге нужно кое-что изменить, чтобы он использовал новый, управляемый, объект FileSystemObject. Пример использования этого нового объекта показан в листинге 15.10.

Листинг 15.10. Использование импортированных СОМ-объектов

1: <%@ Page Language="VB" %>

2:

3: <script runat="server">

4: sub Page Loadfobj as object, e as eventargs)

5: dim objFSO as new Scrrunjiet.FileSystemObject

6: dim objFile as Scrrun_net.File

7: objFile = objFSO.GetFile(Server.MapPath _

8: {Server.MapPath("../dayl371og.txt "})

9:

10: IblMessage.Text = objFile.Path

П: end sub

12: </script>

13:

14: <htmlxbody>

15: <asp:Label id="lblMessage^H runat="server"/>

16: </bodyx/html>

Теперь вы возвращаетесь к уже знакомому вам созданию экземпляров объектов. Обратите внимание, что FileSystemObject теперь принадлежит пространству имен Scrrun_net, и имя этого пространства такое же, как и у созданного вами файла. Благодаря этому у нового-листинга по сравнению с предыдущим резко возрастает производительность, что, в свою очередь, дает возможность использовать старые СОМ-объекты точно так же, как и любые.NET-объекты.

На самом же деле система.NET Framework никакого преобразования СОМ-объектов в.NET-объекты не делает. Она имеет упаковщик (wrapper), который генерирует необходимые метаданные, но при этом никаких изменений в самом объекте не делает. Так что CLR все равно в полной мере СОМ-объекты не поддерживает.