VS2017 NetCoreApp을 EXE로 컴파일
Visual Studio 2017에서 NetCoreApp (v1.1)을 만들었습니다. 컴파일 할 때 빌드 된 프로젝트에 대해 예상되는 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>
2019 업데이트 :
.NET Core 3.0+ 프로젝트에는 이제 기본적으로 빌드하는 플랫폼에 대한 실행 파일이 포함됩니다. 이것은 단지 shim 실행 파일이며 주 논리는 여전히 .dll
파일 안에 있습니다.
그러나 .NET Core 3.0은 단일 파일 배포도 도입 했으므로
dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false
모든 종속성을 포함하는 단일 .exe 파일을 생성합니다. .NET Core 런타임도 포함 --self-contained
하도록 true
로 변경할 수 있으므로 .NET Core를 대상 머신에 전역으로 설치할 필요가 없습니다.
실물
.NET Core 애플리케이션은 .dll
파일 이어야 합니다. 이 경우로 OutputType
설정하면 Exe
"실행 가능"을 의미하며 출력이 실행 가능한지 확인하는 데 필요한 모든 작업을 수행합니다 ( Main()
메서드, .runtimeconfig.json
파일의 진입 점 ). 결과 dll 파일은 다음을 사용하여 실행됩니다.
dotnet yourapp.dll
이 dll 파일은 .net 코어 런타임 (windows, linux, macOS)에서 지원하는 모든 플랫폼에서 작동합니다. 이를 "휴대용"또는 "프레임 워크 종속"배포라고합니다.
실제로 .exe
파일 을 원한다면 자체 포함 배포를 고려하십시오. 이렇게하면 .net 코어 런타임의 자체 복사본과 yourapp.exe
파일 이 포함 된 출력이 생성 되지만 게시 된 앱의 크기도 증가하며 런타임의 새 버전이 출시 될 때 업데이트해야합니다. 또한 결과 응용 프로그램은 게시 된 운영 체제에서만 작동합니다.
참조 .NET 핵심 응용 프로그램 배포 더 배치 옵션에 대한 자세한 내용과 설정 방법에 대한.
VS2017에서
- 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 게시를 선택합니다 (VS2019에서 빌드-> 게시 클릭).
- '폴더'를 선택하고 새 프로필을 만듭니다.
- '게시'탭에서 '구성 ...'을 클릭합니다.
- 배포 모드 선택 : 자체 포함, 대상 런타임 : win-x86 (또는 win-x64)
- 저장
- 게시
\ bin \ Debug \ netcoreapp2.1 \ win-x86 \ 폴더에 EXE 파일이 있습니다.
.NET Core 2.2부터는 프레임 워크 종속 실행 파일을 빌드 할 수 있습니다.
자체 포함 된 배포를 구축하는 것이 좋은 솔루션이 될 수 있지만 자체적 인 단점이 있습니다. (SCD-s에 대한 R. Titov 및 Martin Ullrichs의 답변을 참조하십시오.)
다행히 .NET Core 2.2 는 기본적으로 표준 dll-s 주위의 래퍼 바이너리 ( Windows의 .exe ) 인 Framework-Dependent Executable -s 의 빌드를 지원합니다 .
이렇게 하면 표준 Framework-Dependent Deployment의 모든 장점 (및 단점)을 얻을 수 있지만 (다시 Martin의 답변 참조) dotnet CLI를 통해 호출 할 필요없이 편리하게 시작할 수 있습니다.
다음 구문을 사용 하여 앱을 프레임 워크 종속 실행 파일 로 게시 할 수 있습니다 .
dotnet publish -c Release -r <RID> --self-contained false
여기서 RID는 일반적인 런타임 식별자입니다 (예 : win-x64
빌드하려는 플랫폼) ( 여기에서 카탈로그 참조 ).
이것이 모든 OS에서 명령 줄을 사용하여 자체 포함 된 게시를 수행하는 방법입니다. dotnet publish C : \ src \ App \ App.csproj -c release -r win-x64 -o output-win-x64
Besides, you might want to get the output decreased from typical ~60MB for a simple Hello World app to ~30Mb by using ILLink.
Also, you might want to go further and get a single .exe file of a size at around 5Mb and use ILCompiler. See this reply.
The other answers are good, but what I find sometimes convenient is:
- Not have it self-contained because the target machine is likely to have .net core of the correct version installed. This cuts on number of the dlls I need to ship.
- Not have to specify
dotnet
on the command line
For this a bat file wrapper can be used similar to these lines:
@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%
If your app ends up in yourapp.dll
name the bat file yourapp.bat
and place it along side the dll. Now instead of dotnet yourapp.dll params
you can call yourapp params
이 답변의 컨텍스트는 사내 도구이므로 유틸리티를 사용하는 모든 개발자는 꽤 표준 개발 시스템 설정을 갖습니다. 이것이 자신의 상자에 무엇이 있는지 알고있는 외부 고객에게 배포되는 경우 자체 포함 옵션이 훨씬 우수합니다.
참고 URL : https://stackoverflow.com/questions/44038847/vs2017-compile-netcoreapp-as-exe
'programing tip' 카테고리의 다른 글
0보다 큰 숫자에 대한 정규식? (0) | 2020.11.30 |
---|---|
git push rejected : 오류 : 일부 참조를 푸시하지 못했습니다. (0) | 2020.11.30 |
데이터베이스 구성이 어댑터를 지정하지 않습니다. (0) | 2020.11.30 |
C #에서 큰 따옴표와 작은 따옴표의 차이점은 무엇입니까? (0) | 2020.11.30 |
Eclipse Index 정리, 코드와 동기화되지 않음 (0) | 2020.11.30 |