C# для профессионалов. Том II
вернуться

Ватсон Карли
Шрифт:

intFactorial*=i;

}

return intFactorial;

 }

 }

}

После компиляции класса примера в сборку .NET можно зарегистрировать эту сборку в службах COM с помощью

RegAsm.exe
:

Теперь, когда сборка зарегистрирована в службах COM с помощью

RegAsm
, можно выполнить позднее связывание со сборкой .NET через службы COM. С целью демонстрации создадим простой сценарий VB, который это делает. (Сценарий VB можно создать с помощью текстового редактора, такого как Notepad; введите просто следующий код и сохраните файл с расширением
.vbs
. Предполагая, что Windows Script Host установлен, файл при вызове будет выполняться как сценарий. Помните, что сценарий VB выполняет позднее связывание для компонентов COM.)

Option Explicit

Dim objFactorial

Dim lngResult

Dim lngInputValue

Set objFactorial=CreateObject("Factorial.Factorial")

lngInputValue=InputBox("Numbers?")

IngResult=objFactorial.ComputeFactorial(CLng(lngInputValue))

Call MsgBox(lngResult)

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

sn -k Factorial.dll

Далее необходимо создать файл

AssemblyInfo.cs
со следующим содержимым:

using System.Reflection;

[assembly: AssemblyKeyFile("factorial.snk")]

Затем это надо откомпилировать с помощью следующей команды, чтобы превратить в модуль:

CSC /t:module /out: AssemblyInfo.dll AssemblyInfo.cs

После этого компилируется файл

Factorial.cs
, и полученная DLL устанавливается в глобальный кэш с помощью
gacutil
следующим образом:

csc /t:library /addmodule:assemblyinfо.dll Factorial.cs gacutil /i Factorial.dll

При выполнении сценарий VB воспользуется службами COM для создания объекта .NET, вызовет метод на этом объекте и выведет возвращаемое из объекта .NET значение в окне сообщения:

Интересная техника, не правда ли? Но она не решает ни одной из упомянутых выше проблем, связанных с поздним связыванием. К счастью, другой член набора инструментов SDK .NET может в этом помочь. Это утилита

TlbExp.exe
.

Однако, прежде чем попрощаться с

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

TlbExp.exe

TlbExp
обозначает Type Library Exporter (экспортер библиотеки типов). При выполнении на файле сборки .NET
TlbExp
может запросить внутренний манифест этой сборки и вывести соответствующий файл библиотеки типов COM (
*.tlb
). Когда TlbExp создаст файл библиотеки типов для компонента .NET, языки разработки не принадлежащие .NET, такие как VB6, смогут ссылаться на него, используя для того, чтобы получить эффективное раннее связывание с компонентами .NET:

Как можно было уже догадаться, утилиты

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

Службы вызова платформы

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

PInvoke
.

Неуправляемый код и ненадежный код

Первое, о чем необходимо знать, — термины неуправляемый и ненадежный не являются синонимами.

Ненадежный код C# является кодом, который встроен в блок с префиксом в виде ключевого слова

unsafe
. Код в таком блоке может использовать весь диапазон идиом C++, таких как указатели и массивы на основе стека. Он считается ненадежным, так как такие идиомы часто ассоциируются с ошибками, но такой код по-прежнему управляется средой времени выполнения .NET.

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

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