sergey vasin

The IT blog

Используем сборки .NET Framework в Windows PowerShell – Hey, Scripting Guy! Blog

leave a comment »

Резюме: Приглашенные блогеры Microsoft PFE Adam Haynes и Shubert Somer продолжают свою серию статей об основах .NET Framework.

Microsoft Scripting Guy Ed Wilson на связи. Сегодня я публикую четвертую из пяти статей, написанных Adam Haynes с некоторой помощью его друга Shubert Somer. Перед прочтением данной статьи рекомендуется ознакомиться с частью 1, частью 2 и частью 3.

Итак, Адам.

Шуберт предупреждал меня, каким «простой» может оказаться эта серия статей. Мы правда старались сделать ее проще, и пока что мы говорили о таких вещах, как тип/класс, объект, метод, конструктор, свойство и член. И хотя это не является полным списком терминов .NET, мы пропустили одну довольно важную вещь.

Помните, как я сказал, что для работы скрипта из предыдущих статей вам потребуется модуль Active Directory? Для этого есть вполне определенная причина. Да, скрипт действительно использует некоторые командлеты, входящие в модуль ActuveDirectory, однако, то о чем мы не упомянули – это сборка (assembly) System.DirectoryServices.ActiveDirectory. Когда мы загружаем модуль ActiveDirectory в консоль Windows PowerShell, также загружается и эта сборка.

Я не хочу заставлять вас переключаться между этим и предыдущими постами, поэтому мы приведем новый пример, чтобы представить вам эту концепцию, а также вспомнить то, о чем говорилось ранее. Этот новый скрипт позволит нам получить доступ к объектам Windows Forms. Я знаю о чем вы можете подумать: мы все это время рассуждали о том, какая замечательная вещь PowerShell, а теперь вы предлагаете нам вернуться к использованию графического интерфейса? Ну, это не совсем так. И я вам объясню: хотя мне безумно нравится PowerShell, некоторые из пользователей моих скриптов испытывают некоторую робость при виде мерцающего курсора на фоне синего экрана.

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

[reflection.assembly]::loadwithpartialname(«System.Windows.Forms») | Out-Null

$openFile = New-Object System.Windows.Forms.OpenFileDialog

$openFile.Filter = «txt files (.txt)|.txt|All files (.)|.»

If($openFile.ShowDialog() -eq «OK»

{get-content $openFile.FileName}

01

Большая часть скрипта должна быть вам понятна, но первая строка вызывает смешанные чувства – я не имею ни малейшего представления, что такое reflection.assembly, но выглядит все это как вызов статического метода. Вы можете спросить, почему это так важно? Потому, что без этой строки скрипт возвратит нам следующее:

02

Похоже, что по какой-то причине Windows PowerShell не обладает информацией о конструкторе OpenFileDialog. А я думал, что PowerShell все знает и все видит. Сейчас я передам слово Шуберту, поскольку объяснение одной этой строки займет большую часть поста. Кроме того, эта строка позволит вам войти в мир .NET Framework и получить доступ к управлению любой технологией Microsoft, с которой вы работаете.

Shubert: Об этой одной строке можно сказать очень многое, так что сначала я немного углублюсь в историю. Способ организации модульного кода, т.е. такого кода, функциональность которого поделена на небольшие части, допускающие возможность его повторного использования – это хранение его в DLL (DLL – это аббревиатура для Dynamic Link Library, динамически подгружаемой библиотеки, содержащей код, который может быть загружен в память и использован по требованию). Во времена, предшествующие .NET, я порой сравнивал программы для Windows с корзинкой шариков, где каждый шарик представляет из себя DLL. Когда вы устанавливаете программу – вы вываливаете содержимое корзинки на пол. Удаление же программы представляло из себя ситуацию, когда вы просите одного из своих детей пойти и собрать все шарики зеленого цвета. Любые попытки проконтролировать все эти шарики были настолько трудоемкими, что получили название DLL Hell.

С появлением .NET… вместо корзинки шариков появились сумки с шариками, на каждой из который есть небольшая записка с описанием содержимого. Установка программы теперь представляется мне в виде размещения сумки на некой полке, где все разложено в алфавитном порядке. В основном.

Вы можете сказать – и что изменилось? Но на самом деле разница есть. Теперь гораздо проще найти нужную вам сумку с шариками, а записка на сумке скажет вам, какие шарики находятся внутри и что они делают. Эти сумки с шариками представляют из себя сборки .NET, а записки на каждой их этих сумок – это то же самое, что и reflection для .NET Framework.

Как и все остальное в .NET, reflections – это еще один набор объектов, и поэтому они обладают своими собственными свойствами и методами. Поскольку в основном они представляют из себя нечто вроде утилит, большинство из них статические. Технически reflection определяется как пространство имен (namespace), и поэтому очень важно понимать разницу между пространством имен (namespace), сборкой (assembly) и классом (class).

Пространства имен – это фактически обозначения, используемые для того, чтобы классы из различных сборок могли иметь одинаковые имена и при этом никак не влияли друг на друга. Так же, как классы представляют из себя контейнеры для их членов (например, множество классов обладают методом Open()), пространства имен представляют из себя контейнеры для классов, которые могут обладать одинаковыми именами. Пространства имен .NET начинаются с “System” (это корень пространств имен .NET). Пространства имен приложений принято именовать в виде {ИмяКомпании}.{ИмяПриложения}… Поэтому для классов, имеющих отношение к Microsoft Office свойственны имена Microsoft.Office.{еще что-то}.

Сборка – это набор некоторой функциональности (.NET-эквивалент DLL). Практически всегда сборка состоит из одного файла (DLL или EXE). Для того, чтобы все стало еще запутаннее, структура имен сборок (assembly) очень похожа на структуру имен для пространств имен (namespace). Однако помните: это не одно и то же. Сборка может содержать в себе классы из нескольких пространств имен, а пространство имен может охватывать несколько сборок. Хотя это и не совсем верно, однако вы можете считать сборку физическим файлом, содержащим исполняемый код, а пространство имен – категорией, используемой для организации всего кода, относящегося к определенной области.

Итак, строка понемногу начинает обретать смысл. Reflection – это пространство имен, которое сообщает Windows PowerShell какую именно сборку использовать (полное имя – “System.Reflection”, однако левая часть пространства имен может быть отброшена если это не ведет к неопределенности – в ином случае Windows PowerShell сообщит нечто вроде “unable to resolve object path”). Класс assembly обладает набором статических методов для работы со сборками. Мы используем метод, который загружает требуемую сборку (некоторый файл на жестком диске) в память, чтобы она могла быть использована в Windows PowerShell. Используя аналогию с шариками, вы просите одного из своих детей принести сумку “System.Windows.Forms”, чтобы вы все вместе могли поиграть с шариками.

Далее в коде вы увидите, что System.Windows.Forms это также и пространство имен, и это может слегка добавить путаницы. Если вы просматриваете MSDN с целью узнать, как загрузить нужную сборку, чтобы использовать все те классы, которые вы нашли – обратите внимание на имя сборки – оно может отличаться (иногда – совершенно) от пространства имен.

03

Ссылка MSDN: http://msdn.microsoft.com/en-us/library/ms973231.aspx

Adam: Я должен сказать, что после того, как я прослушал все это лично, я почувствовал себя менее умным, чем до этого. После того, как я перечитал все это несколько раз, мне кажется я ухватил суть. В примере из первой статьи нам не требовалось ничего подобного, потому что командлет Import-Module делал все за нас. Разработчики, создавшие модуль ActiveDirectory знали, что им понадобится пространство имен DirectoryServices, так что модуль содержит в себе эту часть кода.

Теперь, когда мы знаем, чем так важна первая строка нашего нового примера, вы можете спросить – почему мы говорим об этом в самом конце? Ну, если бы мы с этого начали, как вы думаете, сколько администраторов дочитали бы до этого места? Когда Шуберт начал мне это рассказывать, мне хотелось притвориться, что мне срочно нужно сделать телефонный звонок. Однако, мы почти закончили. В последнем посте мы воспользуемся нашим новым знанием и строка за строкой разберем скрипт, приведенный в начале этого поста.

~Adam.

Автор:

Ed Wilson, Microsoft Scripting Guy

Оригинал:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/21/using-net-assemblies-from-within-windows-powershell.aspx


Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell


Реклама

Written by Сергей Васин

Март 10, 2013 в 11:55

Опубликовано в HeyScriptingGuyBlog, PowerShell

Tagged with ,

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s