Объединение всех зависящих от приложения файлов в один двоичный файл предоставляет разработчику приложения привлекательный вариант развертывания и распространения приложения в виде одного файла. Однофайловое развертывание доступно как для модели развертывания, зависящей от платформы , так и для автономных приложений.
Размер одного файла в автономном приложении велик, так как он включает в себя среду выполнения и библиотеки платформы. В .NET 6 можно опубликовать trimmed , чтобы уменьшить общий размер приложений, совместимых с обрезкой. Вариант развертывания в виде одного файла можно сочетать с параметрами публикации ReadyToRun и Обрезка.
[ВАЖНО] Чтобы запустить одно файловое приложение в Windows 7, необходимо использовать среду выполнения .NET 6.0.3 или более поздней версии.
Пример файла проекта
Ниже приведен пример файла проекта, который указывает публикацию одного файла:
Exe net6.0 true true win-x64
Эти свойства имеют следующие функции:
Компилирование всех файлов проекта в один EXE | Wpf
- PublishSingleFile . Включает публикацию одного файла. Кроме того, включает предупреждения для одного файла во время dotnet build .
- SelfContained . Определяет, является ли приложение автономным или зависящим от платформы.
- RuntimeIdentifier . Указывает тип операционной системы и ЦП , на которые вы ориентируетесь. Также задает по true умолчанию.
Приложения с одним файлом всегда зависят от операционной системы и архитектуры. Необходимо опубликовать для каждой конфигурации, например Linux x64, Linux Arm64, Windows x64 и т. д.
Файлы конфигурации среды выполнения, такие как *.runtimeconfig.json и *.deps.json, включаются в один файл. Если требуется дополнительный файл конфигурации, его можно разместить рядом с одним файлом.
Публикация однофайловых приложений
Опубликуйте приложение с одним файлом с помощью команды dotnet publish.
-
Добавьте true в файл проекта. Это изменение создает одно файловое приложение при автономной публикации. В нем также отображаются предупреждения о совместимости с одним файлом во время сборки.
true
Необходимо задать в файле проекта, чтобы включить анализ файлов во время сборки, но также можно передать эти параметры в качестве dotnet publish аргументов:
dotnet publish -r linux-x64 -p:PublishSingleFile=true —self-contained false
Visual Studio создает многократно используемые профили публикации, которые управляют процессом публикации приложения.
- Добавьте true в файл проекта.
- В обозревателе решений щелкните правой кнопкой мыши проект, который нужно опубликовать. Нажмите кнопку Опубликовать.
Если у вас еще нет профиля публикации, следуйте инструкциям по его созданию и выберите Папка в качестве типа целевого объекта. - Нажмите кнопку Изменить.
- В диалоговом окне Параметры профиля задайте следующие параметры.
- Параметру Режим развертывания задайте значение Автономное или Зависимое от платформы.
- В качестве значения параметра Целевая среда выполнения укажите платформу, на которую будет выполнена публикация. Должно быть чем-то, отличное от переносимого.
- Выберите Создать отдельный файл.
Visual studio где exe. Как сделать exe файл в visual studio. Как скомпилировать cpp в exe. Урок #20.
Нажмите кнопку Сохранить, чтобы сохранить параметры и вернуться в диалоговое окно Публикация.
В Visual Studio для Mac отсутствует возможность публикации приложения в виде одного файла. Вам потребуется опубликовать вручную, следуя инструкциям на вкладке CLI. Дополнительные сведения см. в статье Публикация приложений .NET с помощью .NET CLI.
Исключить файлы из внедрения
Некоторые файлы можно явно исключить из внедрения в один файл, задав следующие метаданные:
true
Например, чтобы поместить некоторые файлы в каталог публикации, но не объединить их в файл, выполните следующие действия.
PreserveNewest true
Добавление PDB-файлов в пакет
PDB-файл для сборки можно внедрить в саму сборку ( .dll ), используя параметр, приведенный ниже. Так как символы являются частью сборки, они также являются частью приложения:
embedded
Например, добавьте следующее свойство в файл проекта сборки, чтобы внедрить PDB-файл в эту сборку:
embedded
Другие замечания
Приложения с одним файлом имеют все связанные PDB-файлы вместе с приложением, а не в пакете по умолчанию. Если вы хотите включить PDB-файлы в сборку для проектов, которые вы создаете DebugType , задайте для параметра значение embedded . См . раздел Включение PDB-файлов в пакет.
Управляемые компоненты C++ не подходят для развертывания одного файла. Рекомендуется создавать приложения на C# или другом неуправляемом языке C++, чтобы обеспечить совместимость с одним файлом.
Собственные библиотеки
Только управляемые библиотеки DLL объединяются с приложением в один исполняемый файл. При запуске приложения управляемые библиотеки DLL извлекаются и загружаются в память, что позволяет избежать извлечения в папку. При таком подходе управляемые двоичные файлы внедряются в пакет с одним файлом, но собственные двоичные файлы самой основной среды выполнения являются отдельными файлами.
Чтобы внедрить эти файлы для извлечения и получить один выходной файл, задайте для свойства IncludeNativeLibrariesForSelfExtract значение true .
При указании IncludeAllContentForSelfExtract извлекаются все файлы, включая управляемые сборки, перед запуском исполняемого файла. Это может быть полезно при редких проблемах совместимости приложений.
Если используется извлечение, файлы извлекаются на диск перед запуском приложения:
- Если для переменной DOTNET_BUNDLE_EXTRACT_BASE_DIR среды задан путь, файлы извлекаются в каталог по такому пути.
- В противном случае при запуске в Linux или macOS файлы извлекаются в каталог в папке $HOME/.net .
- При запуске в Windows файлы извлекаются в каталог в разделе %TEMP%/.net .
Чтобы предотвратить незаконное изменение, эти каталоги не должны быть доступны для записи пользователями или службами с разными привилегиями. Не используйте /tmp или /var/tmp в большинстве систем Linux и macOS.
В некоторых средах Linux, например в systemd , извлечение по умолчанию не работает, так как $HOME не определено. В таких случаях рекомендуется задать $DOTNET_BUNDLE_EXTRACT_BASE_DIR явно.
Для systemd рекомендуется определить DOTNET_BUNDLE_EXTRACT_BASE_DIR в файле %h/.net единиц службы значение , которое systemd правильно расширяется $HOME/.net до учетной записи, на которой выполняется служба.
[Service] Environment=»DOTNET_BUNDLE_EXTRACT_BASE_DIR=%h/.net»
Несовместимость API
Некоторые API несовместимы с развертыванием с одним файлом. Приложения могут потребовать изменения, если они используют эти API. Если вы используете стороннюю платформу или пакет, возможно, они используют один из этих API и нуждаются в изменении.
Распространенная причина многих проблем — это зависимость от путей к файлам или библиотекам DLL, поставляемых с приложением.
В таблице ниже приведены сведения об API библиотеки среды выполнения для использования с одним файлом.
| Assembly.CodeBase | Выдает исключение PlatformNotSupportedException. |
| Assembly.EscapedCodeBase | Выдает исключение PlatformNotSupportedException. |
| Assembly.GetFile | Выдает исключение IOException. |
| Assembly.GetFiles | Выдает исключение IOException. |
| Assembly.Location | Возвращает пустую строку. |
| AssemblyName.CodeBase | Возвращает null . |
| AssemblyName.EscapedCodeBase | Возвращает null . |
| Module.FullyQualifiedName | Возвращает строку со значением или вызывает исключение. |
| Marshal.GetHINSTANCE | Возвращает -1. |
| Module.Name | Возвращает строку со значением . |
Вот некоторые рекомендации по исправлению для распространенных сценариев:
- Чтобы получить доступ к файлам, расположенным рядом с исполняемым файлом, используйте AppContext.BaseDirectory.
- Чтобы найти имя файла исполняемого файла, используйте первый элемент Environment.GetCommandLineArgs()или, начиная с .NET 6, используйте имя файла из ProcessPath.
- Чтобы не допустить доставку свободных файлов в целом, используйте внедренные ресурсы.
После обработки двоичных файлов перед объединением
Для некоторых рабочих процессов требуется постобработка двоичных файлов перед объединением. Распространенный пример — подписывание. Пакет SDK dotnet предоставляет точки расширения MSBuild, позволяющие обрабатывать двоичные файлы непосредственно перед объединением одного файла. Доступные API:
- Целевой объект PrepareForBundle , который будет вызван до GenerateSingleFileBundle
- Объект , содержащий все файлы, которые будут объединяться в пакет
- Свойство AppHostFile , указывающее шаблон apphost. После обработки может потребоваться исключить apphost из обработки.
Чтобы подключиться к этому, необходимо создать целевой объект, который будет выполняться между PrepareForBundle и GenerateSingleFileBundle .
Рассмотрим следующий пример узла проекта Target .NET:
Вполне возможно, что инструментарию потребуется копировать файлы в процессе подписывания. Это может произойти, если исходный файл является общим элементом, не принадлежащим сборке, например, файл поступает из кэша NuGet. В этом случае ожидается, что средство изменит путь к соответствующему FilesToBundle элементу, указав измененную копию.
Сжатие сборок в однофайловых приложениях
Однофайловые приложения можно создавать с включенным сжатием во внедренных сборках. Задайте свойству EnableCompressionInSingleFile значение true . В одном создаваемом файле будут сжаты все внедренные сборки, что может значительно уменьшить размер исполняемого файла.
Однако из-за этого может снизиться производительность. При запуске приложения сборки распаковываются в память, что занимает некоторое время. Перед использованием рекомендуется измерить как изменение размера, так и стоимость запуска при включении сжатия. Влияние может значительно различаться в разных приложениях.
Проверка однофайловых приложений
Приложения с одним файлом можно проверить с помощью средства ILSpy. Средство может отображать все файлы, упакованные в приложение, и проверять содержимое управляемых сборок.
См. также
- Развертывание приложений .NET Core
- Публикация приложений .NET с помощью .NET CLI
- Публикация приложений .NET Core с помощью Visual Studio
- Команда dotnet publish
Источник: learn.microsoft.com
Как собрать программу в visual studio в один файл
Добрый вечер, всем)
Минут 20 назад, задался вопросом, как не таскать дллки за проектом в С#.
В общем-то, решение нашлось, и довольно простое.
Это компилить проект с ипользованием ILMerge.
ILMerge — программа от Microsoft Research.
Я думаю, многие сталкивались с тем, что ситуация такая, когда:
something.exe
one.dll
two.dll
А хотелось бы не таскать .dll, и просто распространять один .exe
Для этого нужно просто скачать и установить ILMerge.
В его папке создать merge_all.bat файл
с кодом из под Кода:
«$(SolutionDir)ILMergemerge_all.bat» «$(SolutionDir)» «$(TargetPath)» $(ConfigurationName)
После скопилить. В папке Release появится папка Output в ней будет один .exe без длл, он спокойно запускается и полностью работоспособен.
[ Ссылки могут видеть только зарегистрированные пользователи. ]
[ Ссылки могут видеть только зарегистрированные пользователи. ]
[ Ссылки могут видеть только зарегистрированные пользователи. ]
Немного пруфов
[ Ссылки могут видеть только зарегистрированные пользователи. ]
а было
[ Ссылки могут видеть только зарегистрированные пользователи. ]
Надеюсь, что кому-то данная статья помогла.
крайслер (02.08.2016), малина (15.04.2015)
 |
 |
 |
 |
| 30.05.2016, 22:14 | #2 |
|
Источник: zhyk.org Как скомпилировать все проекты солюшена в один .EXE?Есть солюшен (Solution). В нем 4 проекта. Один главный, три второстепенных. Главный проект использует типы из второстепенных и наоборот. Короче все они переплетены. Как все это скомпилировать в один .EXE файл для последующего распространения? UPD Т.к. похоже,что не все поняли о чем речь, то постараюсь дополнить свой вопрос.
Вот небольшой пример: В solution Explorer видно, что в Solution добавлено два проект. Проект App2 зависит от проекта App1. App1 добавлен в References.
Так же прописаны соответствующие зависимости. Если просто откомпилировать этот Solution, то на выходе получим два файла — App2.exe и App1.dll. Таким образом, чтобы приложение заработало, скажем на другом компьютере, нужно переписать туда два этих файла. Иначе произойдет ошибка времени выполнения. Что-то вроде Could not load file or assembly. The system cannot find the file specified. Так вот хотелось бы откомпилировать приложение таким образом, чтобы в итоге получился только один файл — App2.exe. И чтобы распространять это приложение можно было одним файлом. А файл App1.dll была как бы встроена в него. Ответы (4 шт):Поправлю сам себя, решить проблему Вам поможет маленькая утилита от Microsoft — ILMerge. Добавлю, что есть хорошая статья на данную тему Есть ещё и костыльный способ: создать новый проект и в него добавить как существующие все файлы с кодом, после чего скомпилировать. Слияние сборок в одну после компиляцииНесколько сборок можно склеить в одну уже после компиляции, используя утилиту ILMerge. Install-Package ilmerge перед использованием пути стоит подправить на актуальные. Включение DLL в EXE в виде Embedded Resource с подменой стандартного механизма загрузки:
using System; using System.Reflection; using System.Windows.Forms; namespace WindowsFormsApplication7 < static class Program < [STAThread] static void Main() < AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve; Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); >private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) < var assemblyName = new AssemblyName(args.Name).Name; if (assemblyName == «someassembly») < using (var stream = typeof(Program).Assembly.GetManifestResourceStream( «WindowsFormsApplication7.» + assemblyName + «.dll»)) < byte[] assemblyData = new byte[stream.Length]; stream.Read(assemblyData, 0, assemblyData.Length); return Assembly.Load(assemblyData); >> else < return null; >> > > Это минимальный рабочий пример. Если не работает — запускайте под отладчиком. Скорее всего вы не угадали с именем ресурса, и GetManifestResourceStream возвращает null . Убедитесь, что тип у айтема выставлен именно в Embedded Resource (а не просто в Resource). Просмотреть имена всех доступных ресурсов можно прямо в отладчике, вызовом typeof(Program).Assembly.GetManifestResourceNames() Включение сборок в виде ресурсов, автоматический вариантУстанавливаете пакет Costura.Fody через nuget и получаете один exe на выходе. > PM> Install-Package Costura.Fody Альтернативы:Для .NET 5.0* есть более простое, поддерживаемое Microsoft решение: single file deployment. Вам нужно настроить публикацию. Зайдите в Build → Publish, создайте профиль публикации. Обязательно выберите конкретный target runtime (например, Windows 64 bit), не оставляйте portable.
Вы сможете также выбрать deployment mode = self-contained, при этом в файл добавится и весь используемый .NET, устанавливать на пользовательском компьютере .NET Runtime не придётся (но размер файла существенно вырастет). Также можно запросить ReadyToRun-компиляцию (то есть, AOT). *На самом деле, должно работать и с .NET Core 3.0, но я не проверял. Источник: husl.ru |
