Что.NET является управляемым модулем?
Я знаю, что это - Windows PE32, но я также знаю, что единица развертывания в.NET является блоком, который в свою очередь имеет декларацию и может быть составлен из нескольких управляемых модулей.
Мои вопросы:
1) Как Вы создали бы несколько управляемых модулей при разрабатывании проекта, таких как lib класса или консольное приложение и т.д.
2) Есть ли способ указать это к компилятору (через свойства проекта, например) для разделения файлов исходного кода в несколько управляемых модулей. Раз так, каково преимущество выполнения так?
3) Управляемые модули могут охватить блоки?
4) Отдельный файл создается на диске, когда исходный код компилируется, или они создаются в памяти и непосредственно встраиваются в блок?
Править:
@Jon:
Для 2): Так, действительно ли компиляция/здание получает в Visual Studio, всегда создают единственный управляемый модуль? Раз так затем мне не удается понять относительно того, почему VS не обеспечивает механизм, чтобы сделать так несмотря на то, что.NET поддерживает выполнение так. Я соглашаюсь, что это было бы неуправляемо для создания блока с модулями с различных языков. Это - единственная причина, почему.NET позволяет создавать много модульные конструкции? Я читал в CLR Richter через C#, что модули могут также охватить блоки, и это помогает, может подавить размеры блока и уменьшить объем потребляемой памяти загрузкой, собирается по требованию, когда определенная функциональность вызывается впервые, но я не совсем уверен относительно того, почему можно было бы хотеть охватить модуль через блоки, почему не только создают новый блок, какой implicity создает новый модуль в процессе. Вы все еще получили бы ту же выгоду.
Объект 4) был в отношении ".netmodule" файлов. Как часть процесса сборки VS я не видел ".netmodule" файлов, созданных в obj каталоге. Я обычно замечал .pdb, .dll/.exe и *файл FileListAbsolute и следовательно вопрос на том, создаются ли какие-либо отдельные файлы для управляемых модулей.
Править: @Jon: Вот является выборка от CLR через C# (3-й выпуск) Pg 43: Возможно, я неправильно читаю это, но это звучит мне, что модуль (который является файлом, принадлежащим блоку) может быть загружен по требованию.
"Например, блок может состоять из нескольких типов. Вы могли поместить часто используемые типы в один файл и менее часто используемые типы в другом файле. Если Ваш блок развертывается путем загрузки его через Интернет, файл с нечасто используемыми типами никогда не, возможно, придется загружать на клиент, если клиент никогда не получает доступ к типам. Например, независимый поставщик программного обеспечения (ISV), специализирующийся на средствах управления UI, мог бы принять решение реализовать Активные типы Доступности в отдельном модуле (для удовлетворения требований Логотипа Microsoft). Только пользователи, которые требуют дополнительных функций доступности, потребовали бы, чтобы этот модуль был загружен.
Вы настраиваете приложение для загрузки файлов блока путем определения элемента кодовой базы (обсужденный в Главе 3) в конфигурационном файле приложения. Элемент кодовой базы определяет URL, указывающий туда, где все файлы блока могут быть найдены."
2 ответа
1) Вы не можете сделать это в Visual Studio. Вы можете сделать это из командной строки, используя:
csc /target:module Foo.cs Bar.cs
В этом случае вы получите файл с именем Foo.netmodule
2) Смотрите вопрос 1 - вы не можете сделать это из Visual Studio, но можете сделать это из командной строки. Я не знаю никаких преимуществ. EDIT: Я согласен с утверждением Эндрю, что вы можете создать сборку из нескольких языков таким образом - но я считаю, что это было бы непрактично. Вам придется разработать соответствующую цепочку зависимостей, чтобы вы могли сначала собрать один полный модуль, затем следующий и т.д... и тогда, почему бы просто не создавать отдельные сборки в первую очередь? Это, конечно, будет дополнительным доменом доступности... но не более того. Я считаю, что недостатки этого, скорее всего, перевесят преимущества почти во всех сценариях. Если вы действительно хотите собрать единую сборку, вы всегда можете использовать ilmerge после создания отдельных сборок.
3) Ну, теоретически один модуль может быть включен в несколько сборок, но смысла в этом нет - это создаст очень запутанную систему.
4) Я не совсем понимаю, что вы имеете в виду. Visual Studio создает некоторые промежуточные файлы в каталоге obj, если это то, что вы имеете в виду. Компилятор командной строки не оставляет никаких дополнительных файлов, но он может создавать промежуточные файлы, которые он удаляет по завершении работы - я не знаю.
EDIT: Я не верю, что VS создает модули как промежуточный шаг. Компиляция в Visual Studio всегда создает одну сборку на проект, и эта сборка имеет один модуль. Когда вы говорите, что CLR через C# говорит, что "модули могут охватывать сборки", вы уверены, что не имеете в виду, что сборки могут охватывать несколько модулей? Вы можете загружать модули сборки по требованию, но не наоборот. Если у вас есть конкретная ссылка, я могу посмотреть...
Вы не можете создавать модули с помощью VS, но вы можете сделать это с помощью компилятора. Модули - это отдельные файлы в файловой системе, в одной сборке может быть несколько модулей, написанных на разных языках.
EDIT: Также вы можете поместить редко используемые классы в отдельные модули. Такие модули будут загружаться только тогда, когда классы будут нужны.