Сборки имеют следующие составляющие:
Манифест, который содержит метаданные сборки
Метаданные типов. Используя эти метаданные, сборка определяет местоположение типов в файле приложения, а также места размещения их в памяти
Собственно код приложения на языке MSIL, в который компилируется код C#
Все эти компоненты могут находиться в одном файле, и тогда сборка представляет один единственный файл в формате exe или dll.
Манифест сборки
Манифест хранит следующие данные:
Номер версии : основной и дополнительный номера. Используется для управления версиями
Язык и региональные параметры : информация о языке и региональных параметрах, которые поддерживает сборка
Информация о строгом имени : открытый ключ издателя
Список всех файлов сборки : хэш и имя каждого из входящих в сборку файлов
Таким образом, манифест позволяет системе определить все файлы, входящие в сборку, сопоставить ссылки на типы, ресурсы, сборки с их файлами, управлять контролем версий.
Атрибуты сборки
По умолчанию Visual Studio при создании проекта добавляет файл AssemblyInfo.cs, который можно найти в узле Properties:
Это обычный файл на языке C# и в моем случае выглядит так:
Смысл этого файла состоит в том, что он задает настройки манифесту сборки. Через атрибуты типа [assembly: AssemblyVersion(«1.0.0.0»)] можно установить значения в манифесте. Префикс assembly: перед атрибутом указывает на то, что это атрибут уровня сборки, в данном случае атрибут номера версии сборки.
В принципе, исходя из названия, я думаю, предназначение многих атрибутов итак понятно:
AssemblyCompany : название компании
AssemblyConfiguration : конфигурация сборки (Retail или Debug)
AssemblyCopyright : авторское право на программу
AssemblyDefaultAlias : псевдоним по умолчанию, используемый при ссылке на данную сборку из других сборок
AssemblyDescription : краткое описание сборки
AssemblyProduct : информация о продукте
AssemblyTitle : название сборки как информационного продукта
AssemblyTrademark : сведения о торговой марке
AssemblyCulture : задает язык и региональные параметры, поддерживаемые сборкой (например, установка русской культуры: [assembly:AssemblyCultureAttribute(«ru»)] )
AssemblyInformationalVersion : полная версия сборки
AssemblyVersion : версия сборки
AssemblyFileVersion : номер версии файла Win32. По умолчанию совпадает с версией сборки.
Сборки имеют следующие свойства.
Сборки реализованы как файлы EXE или DLL.
Сборки загружаются в память только в том случае, если они реально используются. Если они не используются, то они не загружаются. Благодаря этому свойству сборки могут быть эффективным средством для управления ресурсами в крупных проектах.
Сведения о сборке можно получить программным путем с помощью отражения. Дополнительные сведения см. в статьях Отражение (C#) и Отражение (Visual Basic).
Сборки в среде CLR
Сборки предоставляют сведения для среды CLR, которые нужны для распознавания реализаций типов. Для среды выполнения тип не существует вне контекста сборки.
Сборка определяет следующие сведения:
Граница безопасности. Сборка представляет собой единицу, для которой запрашиваются и предоставляются разрешения. Дополнительные сведения о границах безопасности в сборках см. в разделе Вопросы безопасности сборок.
Граница области действия ссылок. Манифест сборки содержит метаданные, используемые для разрешения типов и для выполнения связанных с ресурсами запросов. Манифест указывает типы и ресурсы, предоставляемые за пределами сборки, а также перечисляет другие сборки, от которых она зависит. При отсутствии связанного манифеста сборки код на промежуточном языке MSIL, находящийся в переносимом исполняемом (PE) файле, выполняться не будет.
Граница версий. Сборка является наименьшей единицей с поддержкой версий в среде CLR. Версия для всех типов и ресурсов в одной сборке назначается как единому целому. В манифесте сборки описываются зависимости определенных версий от других сборок. Дополнительные сведения об управлении версиями см. в разделе Управление версиями сборки.
Единица развертывания. При запуске приложения могут присутствовать лишь сборки, первоначально вызываемые приложением. Другие сборки, например, содержащие ресурсы локализации или вспомогательные классы, могут извлекаться по требованию. Это позволяет приложениям сохранять простую структуру и малый размер при первоначальном скачивании. Дополнительные сведения о развертывании сборок см. в разделе Развертывание приложений.
Единица параллельного выполнения. Дополнительные сведения о выполнении нескольких версий сборок см. в разделе Сборки и параллельное выполнение.
Создание сборки
Сборки могут быть статическими или динамическими. Статические сборки хранятся на диске в виде переносимых исполняемых (PE) файлов. Статические сборки могут включать интерфейсы, классы и ресурсы, такие как точечные рисунки, файлы JPEG и другие файлы ресурсов. Кроме того, можно создавать динамические сборки, которые запускаются непосредственно из памяти и не сохраняются на диск перед выполнением. Динамические сборки можно сохранить на диске после выполнения.
Существует несколько способов создания сборок. Можно использовать средства разработки, такие как Visual Studio, позволяющие создавать файлы DLL или EXE. Чтобы создать сборки с использованием модулей из других средств разработки, можно воспользоваться средствами из Windows SDK. Для создания динамических сборок также можно использовать интерфейсы CLR такие, как System.Reflection.Emit.
Чтобы создать сборку в Visual Studio, выберите пункт Сборка в меню Сборка.
Манифест сборки
Каждая сборка имеет файл манифеста сборки. Манифест сборки выполняет роль оглавления и содержит следующее:
Идентификатор сборки (ее имя и версию).
Таблица с описанием всех файлов, входящих в сборку. Например, сюда относятся другие ваши сборки, от которых зависит файл EXE или DLL, а также растровые изображения или файлы сведений.
Добавление ссылки на сборку
Чтобы использовать сборку в приложении, нужно добавить ссылку на нее. Когда вы добавите ссылку на сборку, в вашем приложении станут доступны все предоставленные в сборке типы, свойства, методы и другие члены пространств имен, как если бы их код являлся частью файла с исходным кодом вашего приложения.
На C# вы можете использовать две версии одной и той же сборки в одном приложении. Дополнительные сведения см. в разделе Псевдоним extern.
Пожалуйста объясните, что такое сборка на простом примере
Здравствуйте товарищи специалисты. Почитал статейки про сборки, и ни как в голове не укладывается, что это такое. Вот например есть ехе файл моей программы, у него есть ресурс в виде иконок. Говорят что это уже сборка, тогда из чего она состоит?
Мне кажется что это ехе файл, с точкой входа и описанием необходимых библиотек (с описанием GUI). Но сама сборка называется сборкой только в момент работы ее в памяти. то есть области памяти, в которой лежит мой экзешник и скопированные в эту область памяти необходимые мне компоненты.
И кстати, каком образом моя программа находит необходимые мне компоненты по GUI, ведь записей в реестре больше не делается?
Поправте меня пожалуйста если я ошибаюсь.
P.S. Пожалуйста не отсылайте меня на читание статеек.
Объясните, пожалуйста, создание экземпляра класса в примере
Добрый день, имеем пример кода: using System; // Абстрактный класс может быть унаследован от.
Что такое стек, объясните подробно на примере Delphi
Ну в общем я объявляю указатель на переменную например a: integer; ukaz: ^a; понимаю что для.
Сборки могут содержать один или несколько модулей. Например, крупные проекты могут быть спланированы таким образом, чтобы несколько разработчиков работали каждый над своим модулем, а вместе эти модули образовывали одну сборку. Дополнительные сведения о модулях см. в разделе Практическое руководство. Создание многофайловой сборки.
Сборки имеют следующие свойства.
-Сборки реализованы как EXE- или DLL-файлы.
-Сборки можно поместить в глобальный кэш сборок, чтобы обеспечить их использование несколькими приложениями. В глобальный кэш сборок могут быть включены только сборки со строгими именами. Дополнительные сведения см. в разделе Сборки со строгими именами.
-Сборки загружаются в память только по мере необходимости. Если сборки не используются, они не загружаются. Благодаря этому сборки обеспечивают эффективное управление ресурсами в крупных проектах.
.
немного обобщая можно сказать, что сборка это приложение состоящее из нескольких исполняемых файлов (модулей), один из них exe, остальные dll.
Build Systems — Intro
Что это?
Данный пост будет об автоматических системах сборки. Думаю, интуитивно понятно что это и зачем нужно, но для формальности написать нужно — это такие программные продукты, которые на основе некоторой конфигурации могут «собрать» ваш проект.
Под словом «собрать» здесь может скрываться очень обширный объем работы, который при «ручном» подходе требует значительных затрат времени.
Путаница
На хабре есть ряд статей о Maven, но, к сожалению, все они находятся в разных хабах, т.к. отдельного хаба для билд систем не существует.
Поэтому, я решил «не быть как все» и выбрать именно общий хаб «Программирование», а не «Java», «Веб-разработка» и др.
Поэтому не заинтересованный читатель может продолжить свой поиск интересного, а заинтересованный — читать далее.
Я специально начал пост с пояснений и описания возможностей, так как данные системы могут делать сборки не только для «Java» и применимы не только в веб-разработке. Возможности и варианты использования данных систем значительно шире.
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё время.
High-level архитектура
На этом общую часть о build-системах закончу и перейду к более конкретным вещам.
Maven
Так как переписывать то, что написали другие было бы неправильно, поэтому приведу перечень статей по теме, которые уже есть на хабре о Maven и где описано конкретно об этой системе — что это, как работает и на каких принципах основана.
Заключение
Целью данной статьи было донести до читателя информацию о системах сборки в целом, зачем они нужны и какие задачи способны выполнять.
На этом откланиваюсь и надеюсь, что данная статья найдет своего читателя, который не побоится использовать подобные системы для своих повседневных задач, и покажет простоту и эффективность систем сборки проектов.
Сборки
Следует отметить, что одна и та же структура сборки используется как для исполняемого кода, так и для кода библиотек. Единственное реальное отличие исполняемой сборки заключается в том, что она содержит главную точку входа программы, тогда как библиотечная сборка — нет.
Важное свойство сборок состоит в том, что они содержат метаданные, которые описывают типы и методы, определенные в ее коде. Помимо этого сборка хранит в себе метаданные, описывающие ее саму. Эти метаданные, хранимые в области манифеста, позволяют выполнять проверку номера версии сборки и ее целостность.
Тот факт, что сборка содержит метаданные программы, означает, что приложение или другие сборки, которые вызывают код данной, не нуждаются в обращении к реестру или любому другому источнику данных, чтобы узнать, как конкретную сборку следует использовать. Это существенный прорыв по сравнению со старым способом работы СОМ, когда GUID-идентификаторы компонентов и интерфейсов необходимо было извлекать из реестра, а подробности методов и свойств в некоторых случаях читать из библиотеки типов.
Сборки бывают двух видов: разделяемые и приватные.
Приватные сборки
Это простейший тип сборок. Обычно они поставляются с определенным программным обеспечением и предназначены для применения только в его составе. Обычный сценарий получения приватной сборки — это когда приложение поставляется в виде исполняемой программы и множества библиотек, код которых может быть использован только этим приложением.
Система гарантирует, что приватные сборки не будут применяться другим программным обеспечением, потому что приложение может загружать только приватные сборки, находящиеся в той же папке, где хранится и главная исполняемая программа, которая их загружает, либо во вложенных папках.
Поскольку обычно можно рассчитывать на то, что коммерческое программное обеспечение всегда устанавливается в собственный каталог, значит, нет опасности того, что один программный пакет перепишет, модифицирует или непреднамеренно загрузит приватные сборки, принадлежащие другому пакету. Поскольку приватные сборки могут быть использованы только тем пакетом программного обеспечения, для которого они предназначены, имеется возможность управлять тем программным обеспечением, которое их использует. Отсюда уменьшается необходимость в некоторых предосторожностях для обеспечения безопасности, поскольку нет риска, например, того, что какое-то коммерческое программное обеспечение перепишет сборки их новыми версиями (за исключением случаев, когда программное обеспечение специально разработано для нанесения определенного вреда). Не существует также проблемы коллизии имен. Если окажется, что классы в приватной сборке имеют те же имена, что и классы в чьей-то чужой приватной сборке, то это не имеет значения, поскольку каждое приложение будет в состоянии видеть только один набор собственных приватных сборок.
Поскольку приватная сборка полностью самодостаточна, процесс ее развертывания весьма прост. Вы просто помещаете соответствующий файл (или файлы) в соответствующую папку системы (никаких записей вносить в реестр не потребуется). Этот процесс известен как установка с нулевым воздействием или установка с помощью хсору (zero impact (хсору) installation).
Разделяемые сборки
Назначение разделяемых сборок — служить библиотеками общего применения, которые могут использоваться любым другим приложением. Поскольку любое другое приложение может получить доступ к разделяемой сборке, возникает необходимость в некоторых предосторожностях, чтобы исключить описанные ниже риски.
Коллизия имен, когда разделяемая сборка, поставленная другой компанией, реализует типы с теми же именами, что используются в вашей сборке. Поскольку клиентский код теоретически может иметь доступ к двум таким сборкам одновременно, это может представлять серьезную проблему.
Риск того, что данная сборка будет перезаписана другой версией той же сборки, и новая версия окажется несовместимой с некоторым существующим клиентским кодом.
Чтобы исключить коллизии имен, разделяемым сборкам назначаются имена, основанные на шифровании индивидуальным ключом (в отличие от приватных сборок, которым дается имя, совпадающее с именем главного файла). Это имя, известное как строгое имя, гарантированно является уникальным, и оно должно указываться приложением, ссылающимся на данную разделенную сборку.
Проблемы, связанные с риском перезаписи сборки, решаются указанием информации о версии в манифесте сборки, а также возможностью параллельных установок различных версий данной сборки.