Runtime: 단일 exe 자체 포함 된 콘솔 앱

이 시나리오는 현재 지원되지 않습니다. https://github.com/dotnet/corert 리포지토리에서이 경로를 따라갈 작업을 주시하십시오.

CoreRT는이 솔루션을 검색하기에 적합한 곳입니다.

감사. CoreRT가 정확히 내가 찾던 것 같습니다.

이에 대해 우연히 발견 할 수있는 다른 사람들을 위해 여기를 읽으십시오.

나는 특별히 사전 컴파일 없이이 기능

.NET Framework는 OS에 이미 많은 파일이 있으므로 "속임수"입니다.
원하는 경우 머신 전체 공유 .NET Core를 설치하여 .NET Core에서도 동일한 결과를 얻을 수 있습니다.

CoreCLR을 리팩토링하여 모든 파일을 하나로 병합 (기본 + 관리 포함)하는 것은 사소한 작업이 아니며 너무 많은 고객에게이 시나리오가 그다지 흥미 롭다고 생각하지 않습니다.

차이점은 모든 Windows 컴퓨터에는 .NET Framework가 있지만 .NET Core는 포함되지 않는다는 것입니다. 따라서 배포를 더 복잡하게 만들 가치가있는 특별한 이유가 없다면 그 자리에 머물게 될 것 같습니다.
고객은 일반적으로 단일 exe 유틸리티를 작성하지 않습니다. 아마도 언젠가. :-)

배포를 더 복잡하게 만들 가치가있는 특별한 이유가 없다면

.NET Framework보다 .NET Core를 선호하는 데는 여러 가지 이유가 있습니다. 성능, 모듈성, 서비스 용이성, 격리 등. 그리고 그것은 교차 플랫폼 성을 무시하고 있습니다.

단일 exe 유틸리티를 갖는 것은 대부분 외관상의 문제입니다. 실행 파일이 단일 파일이거나 그 안에 몇 개의 파일이있는 단일 폴더 인 경우에는 (관련된 모든 사람에게) 실제 기능적 차이가 없습니다.

@mellinoe 오, 나는 일반적으로 프로젝트에 동의합니다. 그것은 확실히 사실입니다. 이 외형이 바람직한 작은 유틸리티에서 .NET Framework는 지금까지 충분한 작업을 수행했습니다. 어셈블리 회사와 저작권 메시지를 지정할 수 있다는 것과 같은 의미에서 화장품이라는 데 동의합니다. 그러나 미용적인 것이 나를 덜 좋아하게 만드는 것은 아닙니다. 분명히 여기서 우선 순위는 아니지만 꽤 이해할 수 있습니다.

관련 가능성 있음 : https://github.com/dotnet/core/issues/600

대부분 화장품이 아닙니다. Idsrv4 또는 RavenDb와 같은 여러 구성 요소가 내부에 포함 된 응용 프로그램을 배포하고 싶다고 가정 해보십시오. 그들은 aspnet 코어 비트에 의존합니다. 동일한 버전의 aspnet 코어에 의존하는 한이 모든 것이 잘 작동합니다. 그들 중 하나가 다음 버전으로 롤 포워드하자마자 더 이상 작동하지 않을 것입니다. OTOH라면 각 구성 요소를 단일 .dll로 ilmerge 할 수 있으면 문제가 사라집니다.

명심해야 할 한 가지는 ILMerge가 작동하지 않는 것보다 더 많은 기술적 문제가 있다는 것입니다. 런타임 자체는 기본적으로 여러 파일로 분할되며 CLR 호스트, 런타임 종속성 텍스트 파일 등과 같은 보조 파일도 있습니다. 단일 파일 실행 파일이 과거에 작동했던 유일한 이유는 전역 시스템 전체 설치 인 .NET Framework가 의존했기 때문입니다. .NET Framework에는 실제로 "독립형"옵션이 없기 때문에 두 시나리오를 비교하는 것은 약간 불공평합니다.

동일한 버전의 aspnet 코어에 의존하는 한이 모든 것이 잘 작동합니다. 그들 중 하나가 다음 버전으로 롤 포워드하자마자 더 이상 작동하지 않을 것입니다.

이것은 사실이 아닙니다. 다른 런타임 버전에 대해 여러 다른 애플리케이션을 게시 한 다음 동일한 "uber-app"에 번들로 제공 할 수 있습니다. 종속성을 단일 폴더로 혼합 할 수는 없습니다. 프레임 워크 종속 게시 옵션을 사용하더라도 버전을 혼합하고 일치시킬 수 있습니다. 나는 이것이 말 그대로 단일 파일을 갖는 것보다 덜 편리하다는 것을 이해하고 PE에 리소스로 exe를 포함하는 것과 같은 것을 방지 할 수 있습니다. 그래도 파일을 실행하려면 파일을 추출해야하므로 디렉토리를 사용하여 수행 할 수 있기 때문에 그게 당신이 말하는 것인지 확실하지 않습니다.

런타임 버전이 아니라 작동하지 않을 것임을 알고 있습니다. 내 말은, 각 구성 요소가 [email protected]에 종속 될 때 내 시나리오에서 어떤 일이 발생 [email protected] 로 업데이트됩니다

@thefringeninja 관련 지점뿐만 아니라 배포 가능한 단일 바이너리 단위로 작업 오버 헤드를 줄이는 것이 좋습니다. 배포시 문제가 발생할 가능성을 줄이고 배송 한 항목을인지 적으로 인식해야하는 부담을 줄이고 스크립팅 또는 원하는 상태와 같은 작업 도구에 대한 구성을 줄입니다.

dotnet 도구가 초기 단계이고 2.0에 불과했지만, golang과 같은 대안에 비해이 기능이 너무 부족하다는 점에 감사드립니다. 로드맵에 추가 하시겠습니까?

lib 개발자로서 ILMerge를 Core로 되돌려 주셔서 감사합니다. 👍

Dotnet.exe 는 단일 파일입니다. NuGet.exe는 단일 파일입니다. 나는 화장품이 중요하다고 생각하고, 단일 파일 exe는 100 개의 파일이 들어있는 폴더는 그렇지 않은 방식으로 단순함을 외칩니다! dotnetcore로 이것을 달성하는 방법을 찾는 것이 좋을 것입니다.

나는 이것이 가능하다고 생각했고, 몇 주 동안의 작업 끝에 CLI 콘솔 도구를 단일 .exe에 게시하기 위해 왔습니다.
이것이 자체 핵심 앱의 핵심이라고 생각 했나요?

뿡뿡

이것이 자체 핵심 앱의 핵심이라고 생각 했나요?

자체 포함 된 앱의 요점은 자체 포함되어 있다는 것입니다. 즉, 앱 자체에 실행에 필요한 모든 것이 포함되어 있기 때문에 대상 컴퓨터에 .Net Core를 설치할 필요가 없습니다.

이러한 앱을 배포하려면 전체 파일 디렉터리를 복사해야합니다. 하나의 파일 만 있으면 배포가 더 쉬워 지지만 그게 다가 아니더라도 여전히 자체 포함 된 앱입니다.

크고 서비스와 같은 앱의 경우 이것은 그다지 중요하지 않을 수 있지만 명령 줄 도구와 작은 앱은 가능한 한 간단하고 COPY 배포에 친숙해야합니다.

나는 정기적으로 .NET에서 명령 줄 도구를 작성하고이를 1 EXE로 사용하면 업그레이드 / 배포 / 패키징 방법이 더 간단 해집니다. 나는 항상 모든 .config 및 기타 필수 파일을 EXE 안에 압축합니다.

단일 EXE를 미니 컨테이너로 생각하십시오. 컨테이너 기반 배포의 거의 모든 이점이 여기에 적용됩니다.

이것은 끔찍한 일입니다. 왜 이것이 디자인 프로세스 중에 승인되었는지 궁금합니다. 응용 프로그램을 클라이언트 중 한 명에게 배포하고 싶고, 무엇을 열어야할지 그에게 행운을 빕니다.

이것은 단지 추악하고 완전한 엉망입니다.

실행 시간/
MyProgram.exe
MyLib.dll

이것은 더 나은 생각이었을 것입니다

Java도 더 잘 처리합니다.

그렇습니다. 자체 포함 된 앱에는 런타임 파일이 포함되어야하므로 (분명히!) (그리고 병합 할 방법이 없음) 동일한 라인을 따라 생각하고 있었으며, 폴더 분리만으로도 충분하다고 생각했습니다. 깔끔하고 예, 또한 런타임 파일이 런타임 폴더에 저장되어야한다고 생각합니다. 따라서 코어로 작성된 명령 줄 도구를 사용하려는 사람은 적어도 실행할 대상이 조금 더 직관적이라는 것을 알 수 있습니다.

@Scellow @PRIMETSS 동의해야합니다

이것이 어떻게 여전히 문제입니까? 이에 대한 수요는 지붕을 통해 이루어집니다.

예를 들어이 별도의 폴더에 추가하여 bin에 압축하고 exe와 bin의 두 파일을 포함합니다. 간편한 배포.

다시 열고 기능으로 가질 또 다른 +1.

자 급식 배포가 자급 자족이 될 것으로 예상하고 여기에서 제 길을 찾았습니다. 나는 또한 이것이 일어나는 것을보고 싶다.

어떻게 이것이 단지 외관상의 문제라고 말할 수 있습니까? (프레임 워크 개발자 만 ...)
아무도 설치되지 않은 도구를 생각하지 않았습니까? (.NET은 dll-hell을 해결했으며 .net 코어는 다시 가져옵니다)

내 명령 줄 도구가 자체 포함되기를 원합니다.

이건 정말 나쁘다!

+1

+1 .net 코어 런타임이없는 클러스터에서 Azure Batch에서 사용자 지정 활동을 실행하려고했는데 "자체 포함"버전에서 생성하는 많은 수의 파일을 처리 할 수 ​​없습니다.

Total size of resourceFiles cannot be more than 32768 characters

이것은 공식적인 해결책은 아니지만 유용 할 수 있습니다. 저는 독립적 인 단일 바이너리 애플리케이션을 만들 수있는 도구 인 warp의 저자입니다 : https://github.com/dgiagio/warp

저는 워프가 기본적으로 모두가 여기서 찾는 것이라고 생각합니다! 백그라운드에 있든간에 하나의 exe 파일을 가질 수있는 능력에 관한 것입니다. NuGet 패키지에 대해 생각해보십시오. 단일 .nuget 파일이고 그게 전부입니다. 다른 파일을 패키징하는 파일보다 더 복잡한 것은 아닙니다.

워프는 해키 솔루션입니다. 이것은 우리가 원하는 것이 아닙니다.

우리가 원하는 것은 :

dotnet publish --self-contained -c Release -r win10-x64

그리고 그것은 생성합니다 :

App.exe
runtime/

또는 GO / Rust 등

App.exe

다른 모든 것은 원하지 않습니다

Warp는 App.exe를 생성합니다 ... 어떻게 해키입니까? 분명히 프레임 워크의 일부는 아니지만 "하나의 exe 파일"목표를 달성합니다.

이것이 내 말은 타사 솔루션을 사용하지 않고 기본 동작이어야 함을 의미합니다 (내 생각에)

워프는 대접을받습니다. @dgiagio 작업에 감사드립니다!

+1

실행 파일과 모든 종속성을 번들로 제공하는 일종의 단일 파일 아카이브를보고 싶습니다. 네이티브를 포함 할 필요가 없습니다. 시스템에 dotnet 코어를 설치하도록 요구하는 것이 완벽하다고 생각합니다. Java의 jar 파일과 매우 유사한 것입니다. dar 파일?

다음과 같은 것 :
dotnet 게시-자체 포함
dotnet run-자체 포함 MyApp.dar

지금 이에 대한 제안이있는 것 같습니다 : https://github.com/dotnet/designs/pull/52/files?short_path=28dba55

추적 문제는 다음과 같습니다. https://github.com/dotnet/coreclr/issues/20287

또한 @shanselman 에는 Warp 솔루션에 대한 블로그 게시물이 있습니다.

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

나는 제안을 읽고 이것을 보았다.

그것은 내가 염두에 둔 것이 아닙니다. 이것은 기본적으로 모든 것을 압축하는 느린 프로세스처럼 들립니다.
모든 코드가 단일 실행 파일 / dll로 병합되지만? 아니면 제안서에서 뭔가를 놓쳤을까요?

@RUSshy 모든 관리 코드를 네이티브 컴파일하고 모든 것을 함께 연결하여 하나의 실행 파일을 얻도록 요청하고 있습니까 (CoreRT에서와 같이)? 이것은 .Net Core의 현재 단일 파일 작업의 목표가 아닙니다.

그러나 디스크 추출 및 시작 시간을 줄이기위한 제안 된 솔루션이 있습니다 (예 : 번들에서 직접 특정 파일 유형로드, 추출 된 파일 재사용 ). 단일 파일 솔루션 개발 단계가 여기 에 설명되어

CC : @jeffschwMSFT

파일을 추출해야하는 이유는 무엇입니까? 우리는 ILMerge를 사용하여 .NET에서이 문제를 해결했습니다.

@ phillip-haydon, 여기 에 설명 된대로 ILMerge 및 단일 파일 솔루션은 서로 다른 목표를 달성합니다.

ILMerge 는 여러 어셈블리의 IL을

CoreRT는 다른 것입니다. .NET 코드의 AOT 컴파일은 흥미로워 보이지만 아직 준비되지 않았습니다 (MS가 그것에 집중하고 더 많은 리소스를 할당하기를 바랍니다 .. 이것이 바로 사람들이 원하는 것이고 그들이 GO로 이동 한 이유입니다. )

어쨌든 세부 사항에 대해 이야기 할 기술적 지식이 없지만 사용 사례는 다음과 같습니다.

자체 포함 된 단일 실행 파일을 게시하고 압축, 추출, 오버 헤드없이 실행 파일 만 게시합니다.

@ swaroop-sridhar Linux의 dotnet 코어에서 작동하는 예가 있습니까? https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13 에 따르면 이것은 Windows / Mono 전용 프로젝트입니다.

@thefringeninja ILMerge는 Windows 도구입니다. ILMerge를 다른 플랫폼에 이식 할 계획이 있는지 모르겠습니다.
단일 파일 솔루션은 크로스 플랫폼으로 구현됩니다. 이것은 개발 과정에 있습니다.

트윗 담아 가기
배포 배포 배포!1 ~ 3 개의 파일이 배포 (게시, 업데이트 포함)에 더 적합합니다!

CoreRT는 AOT입니다.
하지만 ppl은 AOT를 원하십니까?
프로젝트 (CoreRT)는 항상 사용할 수있는 것은 아닙니다 (2014 년부터). 지금은 2019 년입니다! ( 약 5 년 소요 )
pragram 언어에 대한 얼마나 소중한 5 년!CoreRT는 다음 릴리스에 대한 계획도 없습니다 !!!ppl이 5 년 더 기다리게 하시겠습니까?

@ swaroop-sridhar 유감입니다. ILMerge / ILRepack은 라이브러리 개발자가 다이아몬드 종속성 문제를 피하는 데 유용합니다.

.NET Core 3.0에서 지원할 계획이 있습니다. @richlander 가 상태를 업데이트 할 수 있습니다.
.NET Core 3.0 블로그 게시물 (예 : https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ 의 "Side-by- 사이드 및 앱-로컬 배포 '섹션을 참조하세요.
또한 읽기 : https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

.net은 작은 단일 독립 실행 파일을 생성하기 위해 이러한 모든 해킹을 필요로하지 않아야합니다. 기본 동작이어야합니다. GO에 의해 살아 나고, Rust도 등장하고, CoreRT 또는 ILMerge에 집중하고, .net 핵심 앱도 이미 있습니다. 로드 할 모든 파일로 인해 시작하는 데 오래 걸리므로 제안서에 언급 된 것처럼 zip / unzip을 사용하여 추가하지 마십시오.

.net은 작은 단일 독립 실행 파일을 생성하기 위해 이러한 모든 해킹을 필요로하지 않아야합니다. 기본 동작이어야합니다. GO에 의해 살아 나고, Rust도 등장하고, CoreRT 또는 ILMerge에 집중하고, .net 핵심 앱도 이미 있습니다. 로드 할 모든 파일로 인해 시작하는 데 오래 걸리므로 제안서에 언급 된 것처럼 zip / unzip을 사용하여 추가하지 마십시오.

당신이 좋아하는 것처럼 ppl은 자바를 가지고 있기 때문에 .net은 살아있을 필요가 없습니다.
go 또는 rust 또는 dlang은 Fuck Zip / Unzip이 있기 때문에 단일 실행 프로그램에 대한 빌드 대상을 지원해서는 안됩니다!

뿡뿡

.net은 작은 단일 독립 실행 파일을 생성하기 위해 이러한 모든 해킹이 필요하지 않습니다.

동의합니다. 동시에 .NET은 정적 링커의 요구 사항 (예 : 즉석 코드 생성, 반영, 데이터 바인딩 등)과 조정하기 어려운 다른 언어에 비해 특정 기능을 제공합니다. 단일 파일 / 정적 링크가 중요한 시나리오에서 이러한 기능을 제외하도록 실험했습니다. 우리는 생태계에서 소비 할 수있는 라이브러리 수가 급격히 감소했기 때문에 그 결과가 더 이상 .NET처럼 느껴지지 않는다는 고객 피드백을 통해 배웠습니다.

따라서 .NET에서 우리 모두가 의존하고 좋아하는 기능의 충실도를 손상시키지 않는 링커를 올바르게 수행하는 것은 어려운 문제입니다. 이 문제를 해결하기 위해 다양한 접근 방식을 실험하고 있습니다. 당신은 이것을 핵이라고 부르고, 나는 이것을 개방적이며 상자 밖에서 생각할 의지라고 부릅니다. 그러나 맹목적으로 .NET을 Go / Rust / C ++로 바꾸는 것은 정답이 아닙니다.

단일 파일 / 정적 링크가 중요한 시나리오에서 이러한 기능을 제외하도록 실험했습니다. 우리는 생태계에서 소비 할 수있는 라이브러리 수가 급격히 감소했기 때문에 그 결과가 더 이상 .NET처럼 느껴지지 않는다는 고객 피드백을 통해 배웠습니다.

Jetbrains가 kotlin JVM / kotlin NATIVE에서했던 것처럼 네이티브 개발 및 제한된 환경에 초점을 맞춘 별도의 .net 버전을 만드는 것에 대해 팀이 생각 했습니까?

.net을 모든 사용 사례에 맞추려는 것이 가장 현명한 옵션이 아니므로 특정 유형이이 문제에 대한 정답 일 수 있습니다.

그리고 tbh, afaik,이 문제는 모든 Windows 설치에 이미 .net 프레임 워크가 있었기 때문에 .net 코어 이전에는 실제로 존재하지 않았으므로 몇 KB exe 만 배포하면되었고, 나를 괴롭히는 것은 아무도 이런 종류에 대해 생각하지 않은 것 같습니다. 기본적으로 .net 프레임 워크를 재 작성한 .net 코어를 설계 할 때 문제가 발생합니다. 이것이 제가 언급 한 옵션이 일반 해킹이라고 말하는 이유입니다. 설계 실수를 수정하기 위해 여기에 있습니다.

https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md를 읽은 후 제안에 대한 추가 단계가있는 것 같으며 zip / unzip으로 끝나지 않으므로 그렇지 않습니다. 잃어버린 싸움, 잘하면 팀이 그 문서에 언급 된 더 가벼운 것을 가져올 수있을 것입니다.

이런 것들이 Windows가 장난감 OS로 남아있는 이유입니다.

@kjkrum 무슨 일이?

@cryru 사람들이 무엇을하는지 모를 때 말하는 것입니다.

@Cryru 독립 실행 형 실행 파일을 빌드 할 수없는 것과 그렇게해야하는 매우 실제적인 필요성을

@Cryru 독립 실행 형 실행 파일을 빌드 할 수없는 것과 그렇게해야하는 매우 실제적인 필요성을

동의, 이것은 실제로 운영 체제에서 C # 프로그램의 위치와 관련이 있습니다.
C # 프로그램은 항상 일류 시민이 될 수 없습니다.2 등석이되기 위해서만.

이것은 해결되었습니다.
TLDR : dotnet publish -r win10-x64 /p:PublishSingleFile=true

세부:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

이것은 해결되었습니다.
TLDR : dotnet publish -r win10-x64 /p:PublishSingleFile=true

세부:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

이 기능이 추가 된 dotnet-core 버전은 무엇입니까? 3.0.100-preview5-011568 하고 있는데이 오류가 발생했습니다.
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE : 실제로 작동하고 있습니다. https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md 에 dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true 게시한다고 명시한 구문 오류 만있는 것 같습니다. --self-contained 를 추가하지 않습니다.

@mihaimyh 감사합니다. 디자인 문서의 오타를 수정하겠습니다.

메신저는 항상 단일 exe 자체 포함 기능에 zip / unzip 솔루션을 사용하는 것에 반대
이것이 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!

사실, 처음부터 유사한 방식으로 IL-Merge를 사용해야합니다.

논쟁이 있어서는 안됩니다. 이것은 시간 낭비입니다. 아무도 모든 것을 압축 / 압축 해제하도록 요청하지 않았습니다. 그러나 그들은이 디자인을 가지고 와서 그들의 시간과 우리의 것을 낭비했습니다.

사람들은 단일 실행 파일과 AOT를 요구하고 시간 낭비를 막습니다. Microsoft

AOT가 없는 단일 파일

나는 MS가 듣고 싶지 않은 것 같아요.

메신저는 항상 단일 exe 자체 포함 기능에 zip / unzip 솔루션을 사용하는 것에 반대
이것이 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!

이미 압축되어있는 것처럼 이해가 잘 안됩니다. 아니면 중복 종속성을 줄여 압축하기 전에 크기를 줄이는 것을 의미합니까?

부정성을 이해하지 못합니다. 빠른 테스트 외에는 아직 사용하지 않았습니다. 그러나 단일 실행 파일은 앱을 클라이언트에 배포하는 상황이나 CLI 도구로 잘 작동하는 것 같습니다. 이 기능이 유용하다고 생각하는 곳입니다. 그 외에는 Dev 또는 기타 환경에서 사용 사례가 표시되지 않으므로 그들이 한 일은 현재 솔루션으로 잘 작동합니다 ..

뿡뿡

나는 MS가 듣고 싶지 않은 것 같아요.

반대로 관련 스레드에서 볼 수있는 광범위한 사용 사례를 요청하고 수집하고 있습니다. 귀하의 의견은 중요하지만 커뮤니티의 다른 사람들의 의견도 마찬가지로 중요하므로 Microsoft의 의견을 들었다고 조롱해서는 안됩니다.

귀하의 진술에 따르면 Microsoft로 오해했을 수 있습니다. 저는 Microsoft를 대변하지 않는 커뮤니티 회원 일뿐입니다.

메신저는 항상 단일 exe 자체 포함 기능에 zip / unzip 솔루션을 사용하는 것에 반대
이것이 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!

이미 압축되어있는 것처럼 이해가 잘 안됩니다. 아니면 중복 종속성을 줄여 압축하기 전에 크기를 줄이는 것을 의미합니까?

WebApi 또는 MVC 또는 ConsoleApp을 사용하는 경우 HelloWorld! 내 뜻을 잘 알고 있습니다.
압축 파일이 너무 커서 너무 많은 코드를 가져 오지만 실행되지 않습니다.
IL-Merge 방법이 사용되지 않는 코드 분기를 줄이면.

네, 콘솔 HelloWorld를했고 그래 68K

자체 포함되지 않은 것은 67K였습니다.
그러나 C #은 어셈블리가 아닙니다. <1K HelloWorld를 원했다면 왜 C #을 사용합니까?
더 큰 앱은 프레임 워크를 더 많이 사용하므로 한 시점에서 프레임 워크보다 더 많은 사용자 지정 코드를 사용합니다.
우리는 정말로 몇 십만에 대해 걱정하고 있습니까? 그렇다면 프레임 워크를 사용하지 말고 모든 것을 처음부터 작성하는 데 시간을 투자하십시오.
내가 여기서 무엇을 놓치고 있습니까?

메신저는 항상 단일 exe 자체 포함 기능에 zip / unzip 솔루션을 사용하는 것에 반대
이것이 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!
WebApi 또는 MVC 또는 ConsoleApp을 사용하는 경우 HelloWorld! 내 뜻을 잘 알고 있습니다.
압축 파일이 너무 커서 너무 많은 코드를 가져 오지만 실행되지 않습니다.
IL-Merge 방법이 사용되지 않는 코드 분기를 줄이면.

@sgf 여기에는 다소 별개의 두 가지 문제가 있습니다.

• 앱의 코드를 줄이는 방법은 무엇입니까?
• 앱을 단일 파일로 패키징하는 방법은 무엇입니까?

코드 감소를 위해 몇 가지 추가 기술이 있습니다.

• IL 병합 : 프로세스에서 어셈블리 ID를 잃기 때문에 모든 앱에 적용되는 것은 아닙니다. 이것은 현재 단일 실행 작업의 목표가 아닙니다.
• 미사용 IL 트리밍 : ILLinker 는 미사용 IL 트리밍을 목표로합니다. 이 기능은 dotnet SDK ( PublishTrimmed 속성)에 통합되어 있으며 ILLinker에서 더 많은 최적화가 개발 중입니다.
• Zip / Unzip : dotnet publish는 현재 게시 된 단일 파일을 압축하지 않지만 수행 할 수 있습니다.

앱을 단일 파일로 패키징하는 방법은 무엇입니까?
dotnet publish는 단일 파일로의 게시를 지원합니다. 게시 된 파일은 앱 크기만큼 커집니다.

네이티브 코드 생성과 관련하여 :

• 현재 네이티브 코드 생성 지원은 즉시 실행 가능한 컴파일러 ( PublishReadyToRun 속성)를 통해 이루어집니다.
• AOT 컴파일을 통한 게시는 훌륭하지만 ( CoreRT ) 아직 사용할 수 없습니다. AOT 컴파일에서도 실행 파일의 크기는 컴파일 옵션에 따라 달라집니다. 예 : 생성 된 코드를 실행하기위한 jit를 포함합니까?

네, 콘솔 HelloWorld를했고 그래 68K

자체 포함되지 않은 것은 67K였습니다.
그러나 C #은 어셈블리가 아닙니다. <1K HelloWorld를 원했다면 왜 C #을 사용합니까?
더 큰 앱은 프레임 워크를 더 많이 사용하므로 한 시점에서 프레임 워크보다 더 많은 사용자 지정 코드를 사용합니다.
우리는 정말로 몇 십만에 대해 걱정하고 있습니까? 그렇다면 프레임 워크를 사용하지 말고 모든 것을 처음부터 작성하는 데 시간을 투자하십시오.
내가 여기서 무엇을 놓치고 있습니까?

UR img가 보여준 것처럼 미안해, 자기 contianed. Thats 68626KB, 약 68mb = 68KK, 68K뿐만 아니라 !!!
우리는 <1kb가 필요하지 않을 것입니다 (자기 contianed 불가능합니다), <3000KB는 괜찮습니다.
하지만 68MB는 30 배 이상입니다.
U는 항상 HelloWorld 프로그램을 작성하지 않습니다 !!!

사과, 늦은 밤에 K와의 실수
추가 된 설명 / 정보 swaroop-sridhar에 감사드립니다. 내가 알지 못했던 새로운 스위치가 있습니다.
다음 스위치를 사용하여 3.preview 6으로 시도했습니다.

dotnet publish -r RID / p : PublishTrimmed = true / p : PublishSingleFile = true
이제 29,000K까지

물론 모든 앱이 Hello World가되는 것은 아니지만 C # Core SelfContained App의 경우 런타임도 포함됩니다. 개인적으로 걱정하지 마세요. 물론 작은 콘솔 도구를 작성하는 경우 3K를 사용하는 것이 좋을 것임을 이해합니다. 하지만 우선 C #을 사용하는 이유는 무엇입니까?
얘들 아 흥미로운 토론!

30mb LOL, 1 ~ 3MB가 될 때 전화 해, 런타임이 부풀어 오르고, GO를 확인하고, 사람들이 웨이브로 마이그레이션합니다.

https://www.jetbrains.com/lp/devecosystem-2019/

kotlin조차도 주식을 얻기 시작하고 kotlin 네이티브로 C #을 부끄럽게 만듭니다.

그리고 Swift는 Windows https://forums.swift.org/t/swift-win32-programming/20686에 오고

그래서 여기에 몇 가지 제안 :

• 반사 제거 옵션 추가
• JIT 물건을 제거하는 옵션 추가
• JIT에 의존하지 않도록 C # 코드 최적화 개선

30mb LOL, 1 ~ 3MB가 될 때 전화 해, 런타임이 부풀어 오르고, GO를 확인하고, 사람들이 웨이브로 마이그레이션합니다.

https://www.jetbrains.com/lp/devecosystem-2019/

kotlin조차도 주식을 얻기 시작하고 kotlin 네이티브로 C #을 부끄럽게 만듭니다.

그리고 Swift는 Windows https://forums.swift.org/t/swift-win32-programming/20686에 오고

그래서 여기에 몇 가지 제안 :

• 반사 제거 옵션 추가
• JIT 물건을 제거하는 옵션 추가
• JIT에 의존하지 않도록 C # 코드 최적화 개선

이건 불공평하다고 생각합니다. .NET은 가장 작은 단일 파일 콘솔 응용 프로그램을 구축하도록 설계되지 않았습니다. Asp.Net 웹 사이트 및 API에 사용합니다. 따라서 프레임 워크 자체는 포함 할 수있는 수많은 너겟 패키지 외에도 수많은 기능을 제공합니다. 웹 응용 프로그램의 크기가 50 또는 수백 메가 바이트이면 문제가 있다고 상상할 수 없습니다. 주요 관심사는 속도, 메모리 사용량 및 장기적인 유지 관리입니다. 누가 서버의 크기를 신경 쓰는지.

유일한 의도가 작은 단일 MB 크기의 콘솔 애플리케이션을 구축하는 것이라면 작업에 적합한 도구를 사용하는 것은 어떨까요? 하나의 파일에 완전한 기능을 갖춘 프레임 워크가 포함 된 애플리케이션의 크기가 "홀로 세계"에서도 수십 메가 바이트라고 불평하는 대신, 예를 들어 Rust를 사용하는 것은 어떨까요?

마이크로 소프트는 처음부터 .NET으로 훌륭한 일을하고 있으며 지난 몇 년 동안 더 많은 일을하고 있습니다. 감사합니다.

그런 무의식, 거짓말, 효율성의 부족에 대해 어떻게 대답해야할까요?

.net 핵심 방향이 얼마나 틀렸는 지 깨닫지 못하고 최근에야 Distribution / IL Merge / AOT 작업을 통해이를 깨닫기 시작했습니다.

이제 웹 어셈블리 마차로 이동하려면 .net 런타임이 너무 커서 적절한 크기의 파일을 배포 할 수 없기 때문에 할 수 없습니다.

그리고 여전히 "서버의 크기에 관심이있는 사람"에 집착했습니다. 이러한 사고 방식은 "현대적이어야 함".net 코어를 이미 오래되고 관련성이없는 기술 스택으로 만든 이유입니다.

마이크로 소프트는 .net을 잘 사용하지 않고 있습니다. 그들은 .net 프레임 워크 호환성을 위해 노인들을 기쁘게하기를 원했기 때문에 실패했습니다. 그것은 그들의 실수 중 하나였습니다.

내가 무례하게 들리면 미안하지만 때로는 변경해야 할 필요가 있습니다

무례하게 들리면 미안하지만

무례하게 들리는군요. 즉, 당신의 해고와 성급한 결론은 설득력있는 효과가 없습니다.

사과, 늦은 밤에 K와의 실수
추가 된 설명 / 정보 swaroop-sridhar에 감사드립니다. 내가 알지 못했던 새로운 스위치가 있습니다.
다음 스위치를 사용하여 3.preview 6으로 시도했습니다.

dotnet publish -r RID / p : PublishTrimmed = true / p : PublishSingleFile = true
이제 29,000K까지

물론 모든 앱이 Hello World가되는 것은 아니지만 C # Core SelfContained App의 경우 런타임도 포함됩니다. 개인적으로 걱정하지 마세요. 물론 작은 콘솔 도구를 작성하는 경우 3K를 사용하는 것이 좋을 것임을 이해합니다. 하지만 우선 C #을 사용하는 이유는 무엇입니까?
얘들 아 흥미로운 토론!

현대 언어로서 세계를 통일하려는 약간의 야망이 있어야하지 않습니까?
모든 개발자가 C ++ 용 C #을 집에서 작성하기를 원하십니까? 아니면 Go, Kotlin, Swift로 푸시 하시겠습니까?
시장 점유율과 C #을 더 침식?

.Net은 크로스 플랫폼을 구현하지 않기 때문에 처음 15 년 이상의 훌륭한 개발 기회를 놓쳤습니다.
그러나 이제 .net이 올바른 방향으로 돌아 왔습니다.

네, 전에 말했듯이 왜 부정적인지 모르겠습니다.
.Net Core는 Full Framework에서 온다면 환상적이었습니다. 그리고 .Net Standard + Core 통합 비전은 합리적이고 진보적이라고 생각합니다.

.NET을 GO 또는 다른 언어 / 프레임 워크와 비교하는 것은 의미가 없습니다.
어쨌든, 싱글 .exe에 대해 작업하고 개선하고있는 솔루션이 몇 년 전의 내 '요청'을 꽤 잘 해결했다고 생각하기 때문에이 주제에 대해 설명하겠습니다.

감사합니다 Guys & Gals!

밖

이 글의 모든 사람들에게 행동 강령 에 대해 상기시키고 싶습니다.

동의하지 않거나 다른 의견을 갖는 것은 괜찮습니다.하지만 제발, 예의 바르게 기술적 인 논의로 표현합시다. 강한 단어를 사용할 필요가 없습니다.
또한, 아이디어를 표적으로하고, 당신의 의견으로 구현하는 것은 공정한 게임입니다. 그러나 뒤에있는 사람들을 공격하는 것은 용납되지 않습니다. 서로를 존중하고 서로 다른 의견을 듣고 강한 발언과 모욕적 인 발언은 자제합시다.

또한 모든 사람에게 다른 관점과 의견을 열어달라고 부탁하고 싶습니다. 판단을 내리기 전에 일반적으로 상대방의 말을 듣는 것이 좋습니다. 상황이 왜 그런지에 대한 이야기가 종종 있습니다. 아이디어와 솔루션이 왜 그런지 안다면 일반적으로 더 생산적입니다.

감사합니다!

메신저는 항상 단일 exe 자체 포함 기능에 zip / unzip 솔루션을 사용하는 것에 반대
이것이 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!
WebApi 또는 MVC 또는 ConsoleApp을 사용하는 경우 HelloWorld! 내 뜻을 잘 알고 있습니다.
압축 파일이 너무 커서 너무 많은 코드를 가져 오지만 실행되지 않습니다.
IL-Merge 방법이 사용되지 않는 코드 분기를 줄이면.

@sgf 여기에는 다소 별개의 두 가지 문제가 있습니다.

• 앱의 코드를 줄이는 방법은 무엇입니까?
• 앱을 단일 파일로 패키징하는 방법은 무엇입니까?

코드 감소를 위해 몇 가지 추가 기술이 있습니다.

• IL 병합 : 프로세스에서 어셈블리 ID를 잃기 때문에 모든 앱에 적용되는 것은 아닙니다. 이것은 현재 단일 실행 작업의 목표가 아닙니다.
• 미사용 IL 트리밍 : ILLinker 는 미사용 IL 트리밍을 목표로합니다. 이 기능은 dotnet SDK ( PublishTrimmed 속성)에 통합되어 있으며 ILLinker에서 더 많은 최적화가 개발 중입니다.
• Zip / Unzip : dotnet publish는 현재 게시 된 단일 파일을 압축하지 않지만 수행 할 수 있습니다.

앱을 단일 파일로 패키징하는 방법은 무엇입니까?
dotnet publish는 단일 파일로의 게시를 지원합니다. 게시 된 파일은 앱 크기만큼 커집니다.

네이티브 코드 생성과 관련하여 :

• 현재 네이티브 코드 생성 지원은 즉시 실행 가능한 컴파일러 ( PublishReadyToRun 속성)를 통해 이루어집니다.
• AOT 컴파일을 통한 게시는 훌륭하지만 ( CoreRT ) 아직 사용할 수 없습니다. AOT 컴파일에서도 실행 파일의 크기는 컴파일 옵션에 따라 달라집니다. 예 : 생성 된 코드를 실행하기위한 jit를 포함합니까?

필요에 따라 기본 DLL을 XXX.exe (UnManaged)와 같은 이름으로 동적 병합합니다.
nativeDLLs (UnManaged) Function-Level Linking 컴파일시 정적 분석을 사용하여 분석합니다.

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

좋은 일을하면 결과는 아마도 2-3MB가 될 것입니다. 메신저가 7zip으로 모두 포장하면 약 4.85mb가 걸립니다. 이제 우리는 XXX.exe를 얻습니다.

IL-merge를 사용하여 유사한 기능 수준 링크를 개발합니다.
관리 DLL의 경우 동일한 이전 트릭이 다시 있습니다.
마지막으로 관리 DLL을 PE.exe 섹션 (.net 섹션으로 표시)으로 포함합니다.

반사의 경우 반사 유형의 분석 DLL입니다. 메타 데이터와 리플렉션 유형 (함수 포함) 및 모든 트리 의존성을 유지합니다.

죄송합니다. 더 이상 이에 대한 토론에 더 이상 시간을 할애하지 않고 의견이 통일 될 수 없습니다.
처음에는 그 결과를 기대했습니다. 그러나 지금, 나는 아마 내 요구를 (아마도 Dlang 어쩌면 어쩌면 코 틀린 어쩌면 님을 이동 또는 어쩌면 녹이 최고입니다) 수행하기 위해 다른 프로그래밍 언어를 고려해야합니다.

나와 이야기 해주셔서 감사합니다. 잔소리로 죄송합니다. 밖

@sgf 나는 당신이 좋은 지적을했다고 생각하고 나는 당신이 주제에 서명했다는 것을 알고 있습니다. 요청하신 기능이 향후 몇 년 동안 .NET Core에 제공 될 것이라고 믿고 있습니다. 실제로 오늘 작은 파일 크기를 원했다면 모노를 대상으로하면 가능할 수 있습니다.

1. Mono는 이미 Linking과 함께 AOT 컴파일을 지원하여 파일 크기를 줄입니다. 이것이 브라우저 .net 런타임 구현에 모노가 선택된 이유 중 하나입니다. https://www.mono-project.com/docs/advanced/aot/ 그리고 이것이 Blazor 프로젝트가 링커를 가질 수있는 이유라고 생각합니다.

2. Microsoft는 .NET 런타임을 하나의 "모든 강력한"런타임으로 통합하기를 원한다고 선언했습니다. 어떤 경우에는 모노를 사용하고 다른 경우에는 .NET Core를 사용하는 대신 모든 시나리오에서 제공 할 수있는 단일 런타임을 원합니다. 이 사실은 AOT 및 연결 / 코드 제거 등을 지원해야 함을 의미합니다. 따라서 향후 몇 년 동안 .NET Core 런타임이 이러한 기능을 얻거나 Mono 및 .NET Core 기능이 새로운 기능으로 통합 될 것으로 예상합니다. 실행 시간.

더 잘 아는 사람이 있으면 알려주세요.

+ 2 ¢

문제는 많은 정보없이 결정이 내려지는 것 같다는 생각이 듭니다. 요즘 내가 보는 모든 곳에서 사람들이 이것에 대해 이야기하고 있습니다. 프로그램을 배포하는 대다수의 사람들은 위시리스트 위에 이것을 가지고 있으며 많은 사람들 이 더 나은 AOT / 배포 가능성을 가진 C #에서 다른 언어로 이동하고 있습니다. 커뮤니티에서 활발히 활동한다면 매우 분명 해지는 꽤 확실한 사실이라고 생각합니다. 그러나 그것은 결정에 사소한 영향을 미치지 않는 것 같습니다.

문제는 이것이 얼마나 중요한지 정확히 알지 못하는 것 같습니다. 개인적으로 그것은 매우 중요합니다. 물론 저는 매우 편견이 있습니다. 그러나 제가 가진 인상은 전반적으로 이것이 가장 중요하고 MS가 가치있는주의를 기울이지 않는 것 같고 많은 사람들에게 인상을 남깁니다. 그들은 전체적으로 기술의 미래에 대해 우리를 확신시키지 못하는 일관된 결정을 내리고 있습니다.

@RUSshy에 동의합니다. CoreRT는 놀라운 프로젝트이며 확실히 올바른 방향으로 가고 있지만 전반적으로 모든 노력이 서버 / 웹 기술에 집중되어있는 것 같습니다. 런타임, jits 및 대형 바이너리와 같은 것들이 그 점에서 스스로를 말합니다. 소프트웨어를 배포하는 누구도 그런 것을 원하지 않습니다.

일부 영역에서 미래에 대해 숨을 쉬지 않고 있지만 개인적으로 여전히 기술을 사용하고 있다고 말합니다.

내가 개인적으로 기대하는 것과 반대라는 것이 밝혀 지더라도 앞으로 나아가는 방향으로 커뮤니티의 더 많은 참여를보고 싶습니다. 그러나 지금까지는 그것을 고려하지 않고 결정을 내리는 것 같습니다. 서버 / 웹이 돈을 벌고 프로그램을 배포하는 사람들은 (적어도 이윤 측면에서) 무시할 수있는 소수 인 것 같지만, 만약 그렇다면 적어도 그것이 그들이 그들의 결정을 기반으로하는 것이 무엇인지 알고 싶습니다. 가능성이 매우 높습니다), 외부에서 보면 동전을 던지는 것처럼 보이기 때문입니다.

@ Alan-FGR

그러나 지금까지는 그것을 고려하지 않고 결정을 내리는 것 같습니다.

더 많은 것을 알고 싶어서 공유 할 그러한 결정의 구체적인 예가 있습니까?

나는 MS가 현재의 dotnet 코어 런타임의 단점을 잘 알고 있다고 생각하며, 이것이 그들이 미래에 모노 런타임과 기능 패리티를 추구하는 이유입니다.

.net core 3.0.0 미리보기 6의 릴리스 정보를 살펴보십시오.

오늘 우리는 .NET Core 3.0 Preview 6을 발표합니다. 여기에는 향상된 시작을위한 어셈블리 컴파일, 링커 및 EventPipe 개선을 통해 크기에 맞게 애플리케이션을 최적화하기위한 업데이트가 포함되어 있습니다. ARM64에서 Alpine 용 새로운 Docker 이미지도 출시했습니다.

특정 시나리오에서 애플리케이션 크기가 중요하다는 것을 잘 알고있는 것 같습니다. 특히 Blazor가 혼합되어 있습니다.

@ Alan-FGR 동의, IIS가 약 8 %의 시장 점유율을 가지고 하락하고 있다는 점을 감안할 때 웹 포커스는 다소 이상합니다. ASP.NET은 관련이 없으며 C # 또는 표준 라이브러리에 대한 개선으로 인해 변경되지 않습니다. C #은 콘솔 앱, Windows 서비스, 모바일 앱 및 PC 게임에서 유지되고 있습니다. 지속적인 존재는 Unity와 Xamarin 덕분입니다. C #은 개발하기에 정말 즐거운 언어이기 때문에 안타까운 일입니다. 이는 Microsoft가 Windows XP에 최고 수준을 남겼다고 여전히 생각하는 오랜 Java 개발자로부터 높은 평가를 받고 있습니다.

필요에 따라 기본 DLL을 XXX.exe (UnManaged)와 같은 이름으로 동적 병합합니다.
nativeDLLs (UnManaged) Function-Level Linking 컴파일시 정적 분석을 사용하여 분석합니다.

동적 병합이 무엇을 의미하는지 잘 모르겠지만 기본 구성 요소를 호스트와 함께 정적으로 연결할 계획이 있습니다. 이 섹션을 참조하십시오.

IL-merge를 사용하여 유사한 기능 수준 링크를 개발합니다.
반사의 경우 반사 유형의 분석 DLL입니다. 메타 데이터와 리플렉션 유형 (함수 포함) 및 모든 트리 의존성을 유지합니다.

어셈블리를 하나로 병합하고 동적 기능을 지원하는 사이드 메타 데이터 테이블을 갖는 옵션에 대해 논의했습니다. 상당한 크기 절약을 제공합니다. 그러나 새로운 메타 데이터 지원과이를 처리하기 위해 디버거 / 프로파일 러 등에 필요한 변경 사항으로 인해 구현 비용이 상당히 높습니다.

바이너리 크기를 줄이는 몇 가지 다른 옵션이 있습니다. 예를 들어 단일 파일을 파일로 추출하지 않고 직접 실행할 수있는 경우 각 DLL에 대한 서명 / 인증서를 삭제할 수 있습니다. 앱 전체에 서명합니다. 이것은 때때로 몇 MB를 절약 할 수 있습니다.

그러나 지금까지는 그것을 고려하지 않고 결정을 내리는 것 같습니다.

더 많은 것을 알고 싶어서 공유 할 그러한 결정의 구체적인 예가 있습니까?

나는 MS가 현재의 dotnet 코어 런타임의 단점을 잘 알고 있다고 생각하며, 이것이 그들이 미래에 모노 런타임과 기능 패리티를 추구하는 이유입니다.

@dazinator 나는 MS가 Mono가 어떤 것에 대한 적절한 해결책이라고 생각한다는 사실이 그들이 실제로 제품을 모른다는 것을 보여줄 것이라고 생각합니다. 저는 Mono를 사용해 왔고, 기술의 중요한 부분이고 .NET의 대중화를 크게 도왔지만 확실히 품질이 부족했습니다. MS에서 이러한 결정을 내리는 사람은 홍보 자료 중 일부를 보았고 실제로 기술을 사용하지 않은 것 같습니다. 반면 CoreRT는 지금까지 나를 위해 크게 과도하게 제공 한 기술입니다. 제 생각에는 다른 수준의 품질이지만 덕 테이프와 함께 사용되는 것으로 의심되는 일부 기술을 선호하여 MS에 의해 무시되고 있습니다.

동의합니다. IIS가 약 8 %의 시장 점유율을 가지고 하락하고 있다는 점을 고려하면 웹 포커스는 다소 이상합니다. ASP.NET은 관련이 없으며 C # 또는 표준 라이브러리에 대한 개선으로 인해 변경되지 않습니다. C #은 콘솔 앱, Windows 서비스, 모바일 앱 및 PC 게임에서 유지되고 있습니다.

@kjkrum 그게 요점입니다. 그러나 웹에서 8 %의 시장 점유율은 여전히 ​​Windows 및 모바일 앱보다 훨씬 더 중요합니다. 좋은 웹 기술은 최소한 Windows 서버 판매에 도움이되므로 이에 대한 관심은 분명하지만 여기에 너무 집중하는 것도 매우 얕은 전략이며 이것이 결정을 내리는 요인이라고 믿지 않습니다. MS는 닷넷 기반과 많은 유망한 프로젝트가 진행되는 가운데 올바른 방향으로 가고있는 것처럼 보였지만 지배적 인 기술을 가질 기회를 놓치고있는 것 같습니다.

나는 이것이 일화이므로 아마도 무의미하다는 것을 알고 있지만, 프로젝트에 C #을 사용했던 모든 사람들 (주로 게임 개발자)은 완전히 해결할 수있는 한계 때문에 다른 것으로 옮겨갔습니다. 그들은 Rust, D, Go 및 C ++로 이동했습니다. 저는 정기적으로 C ++를 사용하고 Rust를 배우고 있지만, 품질이 좋은 제품을 배포하는 것이 후방에 고통 스럽지만 훨씬 더 낫기 때문에 일부 개인 프로젝트에 C #을 사용하고 있습니다.

지속적인 존재는 Unity와 Xamarin 덕분입니다.

예, 많은 기술적 문제 때문에 축복과 저주가 무엇입니까? 예를 들어 Unity는 평판이 매우 좋지 않지만 운 좋게도 .NET / C #에 영향을 미치지 않는 것 같습니다.
그러나 XNA는 완벽하지는 않지만 여전히 사용자와 개발자 사이에서 믿을 수 없을 정도로 큰 명성을 얻고 있습니다.

오늘 .NET Core 3.0으로이 땅을 보게되어 기쁩니다. 감사합니다! 👍

나는 그것이 사람들이 원하는 것인지 잘 모르겠습니다. 141mb exe 인 간단한 계산기로 끝나면 기능은 실패입니다 (그리고 실제 비용은 141mb * 2입니다.

네, 확실히 제가 원하는 것입니다. 일반 자체 포함 배포보다 여전히 작습니다.

보다 적극적인 어셈블리 트리밍과 트리 쉐이킹은 환영하지만 이것은 매우 유용한 시작입니다. 점진적 개선은 가치를 제공하는 가장 현명한 방법입니다.

오이게 네가 원하는거야? 안타깝게도 부푼 어플이 인기가있는 줄 몰랐어요

계산기는 JIT도 필요없고 Reflection도 필요하지 않지만 그것이 당신이 원하는 것이기 때문에 처음부터 내가 틀렸던 것 같아 프로그래밍을 그만둬야한다

@RUSshy 다른 자체 포함 배포보다 더 부

JIT와 리플렉션을 제거하는 것은 모든 것이 단일 exe로 압축되었는지 여부와는 별개입니다. 즉, 단일 exe없이 JIT 및 리플렉션을 제거 할 수 있으며 JIT 및 리플렉션을 제거하지 않고도 단일 exe를 가질 수 있습니다. 그들은 별도의 작품입니다.

나는 그것이 사람들이 원하는 것인지 잘 모르겠습니다. 141mb exe 인 간단한 계산기로 끝나면 기능은 실패입니다 (그리고 실제 비용은 141mb * 2입니다.

C : Users [YourUserName] AppDataLocalTemp.net에 파일 압축을 풉니 다.

단일 exe가 풀릴 위치를 재정의하는 방법이 있습니까?
사용자에게 쓰기 권한이없는 / var / ....로 추출하려고 할 때 문제가 발생했습니다.

@eiva 어떤 OS
https://github.com/dotnet/core-setup/issues/7940 트랙이이 문제를 해결합니다.

그 동안 DOTNET_BUNDLE_EXTRACT_BASE_DIR 환경 변수를 설정하여 번들 파일이 추출되는 위치를 제어 할 수 있습니다.

@ swaroop-sridhar 답장을 보내 주셔서 감사합니다!
"제한된"서비스 계정에서 앱을 실행하는 centos.7입니다.

@ jnm2 C #을 사랑해 주셔서 감사합니다. 하지만 솔직히 말해서 계산기가 128 메가 바이트라는 것은 광기입니다.

@TechnikEmpire "I love C #"이 위에서 말한 내용을 상당히 집중적으로 줄여 준다는 점을 지적 할 필요가 있다고 생각합니다 .D

내 자신의 코드와 라이브러리, 참조 된 타사 라이브러리 및 .NET 자체를 트리 쉐이킹 할 수있을 때까지는 개인적으로 완전히 만족하지 않을 것입니다. 그러나 그렇다고해서 단일 실행 기능이 오늘날 나에게 덜 가치가있는 것은 아닙니다. 그것은 한 차원을 따라가는 단계입니다. 나무를 흔드는 것은 독립적 인 차원이고 제가 바라는 것은 많은 관심을 받고 있습니다.