Главная » C#, Компоненты » Связь свойств между собой

0

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

Добавим на форму два компонента — строковое поле textboxi и метку labeil. Задача заключается в отображении в метке количества символов, введенных в textBoxi. Самый очевидный вариант решения — обработка собы i ия Textchanged. Но есть и другой, более изящный вариант. С помощью простой привязки данных мы свяжем значение метки и длину текста в строковом поле:

label1.DataBxndxngs.Add("Text", texcBoxl, "Text.Length");

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

Три составляющие и позднее связывание

Создание программы заключается в написании некоторого кода, форм и т. п., создаваемых в режиме разработки. Логично предположить, что код, необходимый для работы в режиме разработки, не всегда нужен в режиме выполнения. Действительно, расположив элементы на форме, на самом деле мы создаем код, получающийся с помощью сериализации (см. главу 10). И именно этот код будет выполнен при запуске программы, а сам дизайнер в этот момент уже не нужен. То же самое рассуждение справедливо для кода компонента и кода его дизайнера.

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

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

Во-вторых, нужно разделить код самих компонентов и код приложения для того, чтобы появилась возможность распространять компоненты без исходного кода.

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

Теперь посмотрим, как мы подключали дизайнер к компоненту:

[DesignerAttribute(typeof(GradientLabelDesigner))]

public partial class GradientLabel ; Label {

}

Основная проблема, связанная с таким кодом,— нельзя разделить код компонента и код дизайнера, т. к. компонент использует явное определение типа typeof. Если компилятор не сможет найти нужный тип, код компилироваться не будет. И здесь на помощь приходит второй конструктор атрибута Designer:

[Designer{"MyControl Designer.GradientLabelDesigner, MyControl_Designer")]

public partial class GradientLabel : Label

{

}

Привязка дизайнера к компоненту с помощью имени типа, а не самого типа, называется поздним связыванием. В этом случае нет необходимости держать код дизайнера рядом с кодом компонента. Прямой ссылки на тип нет, компилятор создаст код, а уже на этапе запуска дизайнера формы (не запуска программы, а именно выполнения кода дизайнера!) произойдет привязка указанного дизайнера к компоненту. В следующих разделах мы обсудим вопрос, где должна располагаться сборка, чтобы дизайнер Visual Studio смог ее "увидеть" и загрузить.

Теперь остается разделить компонент и код программы. Действительно, ведь я же обещал, что компоненты можно использовать в разных программах, а значит, храниться они должны независимо. Вообще говоря, нет никакой причины держать код компонента рядом с кодом программы, но… Как тогда компонент появится в палитре компонентов? Чтобы ответить на этот и предыдущий вопрос, мне нужно немного отвлечься и рассказать, где Visual Studio ищет сборки.

Где Visual Studio ищет сборки

Чтобы среда Visual Studio могла найти файл сборки, сборка должна быть расположена в одной из определенных папок:

?          сборка может быть расположена в папке, где установлена сама среда Visual Studio. По умолчанию этот путь выглядит как C:\Program FilesVMicrosoft Visual Studio .NET 2003\Common7\lDE. Это не лучшее место для расположения сборок просто потому, что мусорить в системных папках — не очень хорошая идея;

?          сборка может быть расположена в каталоге PublicAssemblies вышеуказанной папки. Этот каталог специально предназначается для дополнительных сборок;

?          сборка может быть расположена в одном из каталогов, описанных в ключе реестра HKEY_LOCAL_MACHlNE\SOFTWARE\Microsoft\VisualStudio\8.0 \AssemblyFolders (рис. 14.1);

?    сборка может быть расположена в глобальном кэше сборок.

Глобальный кэш сборок (GAC, global assembly cache) был разработан для хранения сборок, предназначенных для общего пользования. Сборки в .NET могут иметь одинаковые названия, но разные версии, поэтому хранилище общедоступных сборок в виде простого каталога не подходит. Физически GAC представляет собой каталог на диске (обычно это скрытый каталог C:\WlNDOWS\assembly\GAC_32), структура подкаталогов которого позволяет хранить все версии сборок (рис. 14.2). Разумеется, никто не копирует сборки в GAC вручную, для этого существуют специальные инструменты (см. разд. 14.2.2).

Рис. 14.1. Ключ AssemblyFolders описывает дополнительные каталоги для поиска сборок

Рис. 14.2. Физическое расположение GAC

Подпись сборок

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

О сборка должна иметь цифровую подпись;

О сборка должна иметь версию.

Именно наличие подписи и версии позволяет строго идентифицировать сборку.

Версия сборки указывается в диалоге Assembly Information (рис. 14.3), который открывается при нажатии на кнопку Assembly Information на вкладке Application диалога свойств проекта.

Цифровая подпись представляет собой файл, имеющий расширение snk. Обычно имя файла совпадает с именем сборки, но это не обязательно. Дл« добавления подписи нужно выбрать вкладку Signing в свойствах проекта и установить флажок Sign the assembly (рис. 14.4). В выпадающем списке можно выбрать существующий файл цифровой подписи или создать новый (рис. 14.5).

Файл цифровой подписи можно также сгенерировать с помощью утилита SN.exe, входящей в состав .NET Framework SDK.

Рис. 14.8. Оснастка управления GAC

Программная установка сборок в GAC

Для программного управления сборками в GAC можно использовать методы класса System.EnterpriseServices. Internal. Publish. Метод Gaclnstall () устанавливает сборку в GAC, а метод GacRemove о удаляет ее (листинг 14.1).

Дополнительную информацию об GAC API можно найти в документации Microsoft по адресу http.’//support.microsoft.com/defauIt.aspx?scid=kb; en-us;317540.

Листинг 14.1 Программное управление сборками в GAC

using System;

using System.Collections.Generic; using System.Text;

// Для работы требуется подключить System.EnterpriseServices.dll using System.EnterpriseServices.Internal;

namespace GacManagement

{

class Program {

static void Main(string[] args) [

if [args.Length != 2) return;

publish publisher = new PublishO;

switch (args[0]) <

case "i":

// Установка в GAC publisher.Gaclnstall(args[1]); break; case "u":

// Удаление из GAC publisher.GacRemove(args[1]); break;

}

}

}

}

Работа со сборками в GAC

Хотя сборки, расположенные в GAC, доступны всем приложениям, среда Visual Studio не позволяет делать прямые ссылки на них. Если нужно как-то использовать сборку, расположенную в GAC, во время разработки, то придется скопировать ее в локальную папку и делать ссылку на локальную копию. Для сборок, требующихся только в режиме разработки, можно выставить свойство Copy Local в значение False. Такие сборки не будут копироваться в выходную папку проекта. В режиме выполнения проблем нет — сборки будут загружены из GAC.

Литература:

Агуров П. В. C#. Разработка компонентов в MS Visual Studio 2005/2008. – СПб.: БХВ-Петербург, 2008. — 480 е.: ил.

По теме:

  • Комментарии