Выполняют ли .NET-проекты в Visual Studio в одном файле?

Question

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

Я создавал несколько автономных приложений .NET, а также несколько подключаемых модулей на основе DLL для других программ. Я заметил, что проект в Visual Studio, по крайней мере с приложениями Windows и библиотеками классов, компилируется в один файл (EXE или DLL).

Это всегда так? Что касается организации более крупного приложения, я должен всегда думать о проектах в Visual Studio, соответствующих одному файлу в финальной программе?

Answer 1

Каждый проект компилируется в один файл. (За исключением проектов веб-сайтов)

Однако, если вы установите для «Действие сборки» для любого файла в проекте «Копировать всегда» или «Копировать», если «Создать», проект скопирует этот файл в выходную папку.
Кроме того, если проект EXE имеет файл App.config, он также будет скопирован в выходную папку.

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

Кроме того, в дополнение к DLL и EXE, Visual Studio также создаст файл .pdb, содержащий символы отладки в выходной папке. Этот файл используется отладчиком и не должен быть распространен среди ваших пользователей. (Если вы не хотите, чтобы они отлаживали ваш код для вас)

Answer 2

Для Visual Studio, да. Найдите в Интернете «netmodule», и вы найдете документацию, которую ищете. Мне довелось встретить их сегодня, когда мы собирались собрать несколько проектов в одну DLL.

MSDN: http://msdn.microsoft.com/en-us/library/226t7yxe(VS.80).aspx

Answer 3

Не обязательно. Если ваш проект имеет ориентированные на культуру ресурсы, они, как правило, собираются в отдельные сборки (dll). Кроме того, проекты ASP.Net не собираются в единую сборку, вы всегда будете иметь либо файлы aspx/ascx, либо их эквиваленты маркеров, оставленные отдельно от скомпилированного кода.

Answer 4

Для ваших простых проектов, да, вы всегда получите одну сборку для каждого проекта. Однако, если вы переходите к более готовому программному обеспечению, ответ другой. Предположим, вы хотите доставить DLL, но он содержит текст, который должен отображаться для пользователя. Вероятно, вы захотите локализовать этот текст (предоставить английскую и немецкую версии или даже англо-английскую и британскую английскую версию [think program vs. program]). Вы поместите свой текст в ресурсы и затем скомпилируете эти ресурсы в так называемые спутниковые сборки. Вы получите одну сателлитную сборку для каждого региона, который вы решите поддержать.

Вот быстренько о том, как создавать и использовать спутниковые сборки: http://sanjaysainitech.blogspot.com/2007/08/satellite-assemblies.html

Я вижу, как люди говорят о netmodules и ILMerge. Я думаю, что если вы беспокоитесь о сетевых модулях, вы делаете что-то неправильно, потому что не используете инструменты, предоставленные Microsoft (или вы закончили на земле Mono, и в этом случае у вас нет инструментов от Microsoft). Я не использовал ILMerge, но, прочитав об этом, я не уверен, что я этому доверяю. This person говорит, что он отлично работает, за исключением кода WPF/XAML; У this person возникли проблемы с доступом к встроенным ресурсам после запуска ILMerge; this person видел оптимизированный код, который нельзя было выполнить, используя отладчик после запуска ILMerge.Это достаточно информации, чтобы сказать мне, что ILMerge не является готовым к производству инструментом для всех сценариев. Часть программного обеспечения для разработки выясняет, как вы его разворачиваете. Если вы хотите развернуть меньшее количество сборок, вы должны разработать свое программное обеспечение таким образом, а не обманывать в IL после того, как вы его скомпилировали. Как говорили картографы: «Вот драконы».

Answer 5

Пример как создать несколько модулей и ссылку темы в одну DLL:

csc /t:module RarelyUsedTypes.cs 
csc /out:AllTypes.dll /t:library /addmodule:RarelyUsedTypes.netmodule AllTypes.cs 

Для получения дополнительной информации см книгу Рихтера CLR via C#.

Вы можете автоматизировать этот процесс для Visual Studio.

Для каждого из ваших проектов создайте netmodule или сборку и скомпилируйте/объедините их все в единую сборку.

Первый вариант. Это было предложено Jay R. Wren:

Это мило хак, но с CSC и VBC и поддерживая /target:module и /addmodule варианты, вы могли бы на самом деле сделать это без ILMerge только с помощью сценария оболочки или сделать файл.

Visual Studio не поддерживает тип «netmodule», но MSBuild делает это.

Добавьте проект VB в свое решение. Выгрузите проект и отредактируйте файл проекта.

Изменение OutputType к модулю:

<OutputType>module</OutputType> 

Вместо того, чтобы добавить ссылку на желаемый проект, мы добавим модуль. К сожалению, снова VStudio здесь не работает, но MSBUILD работает отлично. Выгрузите проект и отредактируйте файл проекта. Добавьте группу элементов с директивами AddModules include.

<ItemGroup><AddModules Include="..\VbXml\bin\Debug\VbXml.netmodule" /></ItemGroup> 

Это скажет MSBuild сказать CSC использовать /addmodule директивы, так же, как Reference Item Group, который студия делает управление.

Основной недостаток: нет Visual Studio Intellisense для добавленного модуля. У нас уже есть ссылки, слишком плохо, что у нас нет модулей. [ОБНОВЛЕНИЕ: Как отметил Арк-кун, Visual Studio может ссылаться на проекты и иметь Intellisense. Просто добавьте ссылку на проект ПЕРЕД заменой типа вывода.]

SharpDevelop имеет первый шаг, но на втором этапе GUI «Добавить модуль» был открыт как элемент с низким приоритетом с SD 2.0.

Вторая альтернатива. Это great article (автор Scott Hanselman) описывает, как сборка megre автоматически, если вы используете Visual Studio.Это делает дает вам поддержку IntelliSense , в отличие от первого варианта .