VS2017 Компилировать NetCoreApp как EXE

Я создал NetCoreApp (v1.1) в Visual Studio 2017. Когда я его компилирую, вместо ожидаемого EXE-файла для встроенного проекта я получаю DLL, созданную. Я проверил csproj файл и подтвердил, что тип вывода установлен на exe, но без игры в кости.

Есть идеи, почему VS2017 все еще производит DLL? Я уверен, что это быстрое место где-то, что я забыл... это также 1 час ночи.:)

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>AnyCPU</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\Core.EF.SqlServer\Core.EF.SqlServer.csproj" />
  </ItemGroup>

</Project>
Источник

3 ответа

Решение

Приложения.NET Core должны быть .dllфайлы. OutputType установлен в Exe в этом случае означает "исполняемый файл" и делает все необходимое, чтобы обеспечить работоспособность вывода (точка входа из Main() метод, .runtimeconfig.json файл). Полученный файл DLL предназначен для запуска с использованием:

dotnet yourapp.dll

Этот файл dll работает на всех платформах, которые поддерживаются средой выполнения.net (windows, linux, macOS). Это называется "переносимым" или "зависимым от фреймворка" развертыванием.

Если вы хотите действительно .exe файл, рассмотрим автономные развертывания. Это создаст вывод, который содержит свою собственную копию среды выполнения ядра.net и yourapp.exe файл, но он также увеличивает размер опубликованного приложения и требует обновления при выпуске новых версий среды выполнения. Кроме того, результирующее приложение работает только в операционной системе, опубликованной для.

Обратитесь к развертыванию приложения.NET Core для получения дополнительной информации о параметрах развертывания и о том, как их настроить.

Источник

В VS2017

  1. Щелкните правой кнопкой мыши свой проект и выберите "Опубликовать".
  2. Выберите "Папка" и создайте новый профиль
  3. На вкладке "Опубликовать" нажмите "Настроить..."
  4. Выберите режим развертывания: автономный, время выполнения цели: win-x86 (или win-x64)
  5. Сохранить
  6. Публиковать

в папке \bin\Debug\netcoreapp2.1\win-x86\ вы увидите файл EXE

Настройки публикации

Источник

Начиная с.NET Core 2.2 вы можете создавать зависимые от платформы исполняемые файлы.

Хотя создание автономного развертывания может быть хорошим решением, у него есть свои недостатки. (См. Ответы Р. Титова и Мартина Ульрихса о SCD-s.)

К счастью, .NET Core 2.2 поддерживает создание так называемых зависимых от платформы исполняемых файлов, которые, по сути, представляют собой двоичную оболочку (.exe в Windows) вокруг стандартных dll.

Таким образом, у вас есть все преимущества (и недостатки) стандартного развертывания, зависящего от фреймворка (опять же, см. Ответ Мартина), но у вас есть удобный способ запустить его, не вызывая его через интерфейс командной строки dotnet.

Вы можете опубликовать свое приложение как зависимый от платформы исполняемый файл, используя следующий синтаксис:

dotnet publish -c Release -r <RID> --self-contained false

Где RID - это обычный идентификатор среды выполнения, например win-x64или любую другую платформу, для которой вы хотите создать (см. каталог здесь).

Источник

Вот как вы делаете автономную публикацию с помощью командной строки в любой ОС: dotnet publish C: \ src \ App \ App.csproj -c release -r win-x64 -o output-win-x64

Кроме того, при использовании ILLink может потребоваться уменьшить объем вывода с типичных ~ 60 МБ для простого приложения Hello World до ~ 30 МБ.

Кроме того, вы можете пойти дальше и получить один.exe-файл размером около 5 Мб и использовать ILCompiler. Смотрите этот ответ.

Источник

Другие ответы хороши, но иногда мне кажется удобным:

  • Он не должен быть автономным, потому что на целевой машине, скорее всего, установлено ядро ​​.net правильной версии. Это сокращает количество DLL, которые мне нужно отправить.
  • Не нужно указывать dotnet в командной строке

Для этого можно использовать оболочку bat-файла, подобную этим:

@ECHO OFF
REM see http://joshua.poehls.me/powershell-batch-file-wrapper/

SET SCRIPTNAME=%~d0%~p0%~n0.dll
SET ARGS=%*

dotnet "%SCRIPTNAME%" %ARGS%
EXIT /B %ERRORLEVEL%

Если ваше приложение заканчивается в yourapp.dll назвать файл летучей мыши yourapp.bat и поместите его вдоль стороны DLL. Сейчас вместо dotnet yourapp.dll params ты можешь позвонить yourapp params

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

Источник
Другие вопросы по тегам