Runtime: 단일 파일 배포 지원

흥미롭게도 이 이니셔티브는 CoreRT와 어떻게 비교됩니까? 비슷한 노력을 하는 것 같죠?

' 아마도 네이티브 사용자 코드 '와 관련이 있습니까? 즉, AOT뿐만 아니라 코드를 JIT 컴파일할 수 있습니까?

또한 런타임 구성 요소(' 네이티브 코드(런타임, 호스트, 프레임워크의 네이티브 부분.. ')가 CoreCLR 리포지토리에 있는 것입니까?

당신은 훌륭한 질문을 하고 있지만 이것은 아직 초기 디자인이기 때문에 나는 아직 좋은 대답을 하지 못합니다.

흥미롭게도 이 이니셔티브는 CoreRT와 어떻게 비교됩니까? 비슷한 노력을 하는 것 같죠?

다소 유사한 결과(단일 파일)가 있을 수 있지만 디자인에는 작동하거나 작동하지 않는 다른 성능 특성 또는 기능이 있을 수 있습니다. 예를 들어 가능한 설계는 기본적으로 .NET Core 자체 포함 애플리케이션의 모든 파일을 단일 파일로 연결하는 것일 수 있습니다. 그것은 10MB이고 더 느리게 시작될 수 있지만 플러그인 로드, 반사 방출 및 고급 진단을 포함하여 CoreCLR의 전체 기능을 허용합니다. CoreRT는 스펙트럼의 다른 쪽 끝으로 간주될 수 있습니다. 한 자리 MB이고 시작 시간이 매우 빠르지만 JIT가 없기 때문에 플러그인을 로드하거나 리플렉션 방출을 사용할 수 없으며 빌드 시간이 대부분의 것보다 느립니다. NET 개발자는 익숙합니다. 현재 시간이 지남에 따라 개선될 수 있는 몇 가지 다른 제한 사항이 있지만 .NET Core 3.0에서는 개선되지 않을 수 있습니다(반사를 위한 주석 필요, 일부 interop 시나리오 누락, Linux의 제한된 진단). 또한 둘 사이 어딘가에 아이디어가 있습니다. 사람들이 절충안을 만들고/피하고 싶은 경우 이에 대해 듣고 싶습니다.

'아마도 네이티브 사용자 코드'와 관련이 있습니까? 즉, AOT뿐만 아니라 코드를 JIT 컴파일할 수 있습니까?

"네이티브 사용자 코드"란 귀하의 앱에 C++ 네이티브 코드(귀하 또는 타사 구성 요소가 작성)가 있을 수 있음을 의미합니다. 해당 코드로 할 수 있는 작업에 제한이 있을 수 있습니다. .dll로 컴파일된 경우 실행할 수 있는 유일한 방법은 디스크를 사용하지 않는 것입니다. .lib이면 링크할 수 있지만 다른 문제가 발생합니다.

또한 런타임 구성 요소('기본 코드(런타임, 호스트, 프레임워크의 기본 부분..')가 CoreCLR 리포지토리의 구성 요소가 될 것이라고 가정합니다.

위의 모든 것을 기반으로 우리는 어떤 repos가 관련되어 있는지 알아낼 것입니다. "프레임워크의 기본 부분"에는 ClrCompression 및 Unix PAL과 같은 CoreFX 기본 파일이 포함됩니다.

이러한 방식의 단일 파일 배포는 시작 시간이 약간 느리더라도 배포의 용이성을 위해 매우 중요할 수 있습니다. 나는 그것의 일부를 포기하도록 강요받는 것보다 완전한 힘을 가질 수 있는 능력을 갖고 싶습니다.

우리에게 흥미로운 몇 가지 시나리오. 이것은 크로스 플랫폼 측면에서 어떻게 작동합니까?
플랫폼마다 별도의 "파일"이 있다고 가정합니까?

네이티브 코드와 관련하여 플랫폼에 따라 다른 네이티브 구성 요소를 어떻게 선택할 수 있습니까?

우리에게 흥미로운 몇 가지 시나리오. 이것은 크로스 플랫폼 측면에서 어떻게 작동합니까?
플랫폼마다 별도의 "파일"이 있다고 가정합니까?
네이티브 코드와 관련하여 플랫폼에 따라 다른 네이티브 구성 요소를 어떻게 선택할 수 있습니까?

@ayende , 나는 @morganbr 코멘트 에서 인용하고 있습니다 :

가능한 설계는 기본적으로 .NET Core 자체 포함 애플리케이션의 모든 파일을 단일 파일로 연결하는 것일 수 있습니다.

자체 포함된 응용 프로그램에 대한 현재 플랫폼 간 이야기는 플랫폼별 런타임과 함께 응용 프로그램을 제공하기 때문에 대상으로 지정하려는 플랫폼별로 배포 패키지를 만드는 것입니다.

@morganbr 시간을 내어 이렇게 자세한 답변을 해주셔서 감사합니다.

디자인이 어디로 가는지 보고 싶습니다. 이것은 정말 흥미로운 이니셔티브입니다.

단일 파일을 사용하려는 사람들에게 몇 가지 질문이 있습니다. 귀하의 답변은 선택의 폭을 좁히는 데 도움이 될 것입니다.

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)
2. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?
3. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?
4. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?
5. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?
6. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?
7. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?
8. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

1. 모든 플랫폼의 콘솔/UI 앱.
2. 아마도 타사 구성 요소로.
3. 아마도 그렇습니다.
4. 예, 특히 ClickOnce와 유사한 간단한 시스템이 있는 경우에 그렇습니다.
5. 약간의 초기 둔화는 용인될 수 있습니다. 포인트 3이 도움이 될까요?
6. 자산에 따라 다릅니다. Hello World는 MB 정도의 크기를 가져야 합니다.
7. 생산만 하면 상관없습니다.
8. 반사 항목을 화이트리스트에 추가하시겠습니까? 네.

@morganbr , 이러한 질문이 더 많은 청중에게 더 나은 질문이라고 생각하십니까? 즉, 이 GitHub 문제에 대해 알고 있는 사람들보다 더 광범위합니까?

예를 들어 가능한 설계는 기본적으로 .NET Core 자체 포함 애플리케이션의 모든 파일을 단일 파일로 연결하는 것일 수 있습니다.

그것을 압축하는 것을보고; 또는 파일에 압축 파일 시스템을 사용하고 있습니까?

@tpetrina , 감사합니다! 포인트 3은 몇 가지 디자인 각도를 다룹니다.

1. 트리 셰이킹은 플러그인이 의존하는 코드를 제거할 수 있기 때문에 트리 셰이커가 보지 못한 플러그인을 로드하는 데 적합하지 않습니다.
2. CoreRT에는 현재 플러그인을 로드하는 방법이 없습니다.
   포인트 5는 크기 또는 시작 시간(그리고 얼마나)을 최적화할 것인지에 대한 것입니다.
   Point 8 네, 주로 리플렉션에 대해 생각하고 있었습니다.

@TheBlueSky , 우리는 다른 사람들에게도 연락했지만 GitHub 커뮤니티의 열정적인 사람들로부터 의견을 얻는 데 도움이 됩니다.

@benaadams , 압축은 테이블에 있지만 현재 전체 디자인과 직교한다고 생각하고 있습니다. 가벼운 실험에 따르면 압축은 몇 초의 시작 시간(및 빌드 시간)을 희생하여 약 50% 크기 감소를 얻을 수 있습니다. 나에게 그것은 우리가 그렇게 한다면 선택 사항이 되어야 할 만큼 충분히 급진적인 절충안입니다.

@morganbr 압축을 사용할 때 시작 시간이 몇 초입니까? UPX 가 압축 해제 속도를

고대 Pentium 133에서 ~10MB/초, Athlon XP 2000+에서 ~200MB/초.

@morganbr , 나에게 대답은 다음과 같습니다.

1) 서비스(기본적으로 Kestrel을 실행하는 콘솔 앱). Windows 서비스/리눅스 데몬으로 실행하거나 도커에서 실행합니다.
2) 예
3) 예, 일반적으로 AssemblyContext.LoadFrom 를 사용하여 어셈블리를 관리합니다. 최종 사용자가 제공합니다.
4) 예, 예상됩니다. 사실, 어쨌든 우리는 이미 전체 프레임워크를 번들로 제공하므로 그 관점에서 변경 사항은 없습니다.
5) 서비스로서 우리는 시작 시간에 그다지 신경 쓰지 않습니다. 5초가 적당합니다.
6) 75MB가 한계일 것입니다. 모든 패키지가 압축되어 배달되기 때문에 실제 압축 크기에 따라 많이 다릅니다.
7) 릴리스 빌드의 경우 더 긴(훨씬 더 긴) 빌드 시간이 허용됩니다.
8) 예, 절대적으로. 크기는 그다지 중요하지 않지만 작을수록 좋습니다.

내가 언급하지 않았고 매우 중요한 것은 이것의 디버깅 가능성입니다.
이것이 스택 추적을 엉망으로 만들지 않기를 바랍니다 pdb 파일이나 일종의 디버깅 기호를 포함할 수 있기를 바랍니다.

압축에 관해서는 거의 모든 경우에 실제 전달 메커니즘이 이미 압축되어 있다는 사실을 고려하십시오.
예를 들어, 너겟 패키지.
사용자는 압축을 푸는 데에도 능숙하므로 문제가 되지 않습니다.
측면에서 압축을 할 수 있다고 생각합니다.

고마워, @ayende! 디버깅 가능성을 언급했어야 하는 것이 맞습니다. 디버깅에 영향을 미칠 수 있는 몇 가지 사소한 방법이 있다고 생각합니다.

1. 단일 파일에서 편집하고 계속하기를 사용하지 못할 수 있습니다(원래 어셈블리를 다시 작성하고 다시 로드하는 방법이 필요하기 때문에).
2. 단일 파일 빌드는 어셈블리와 함께 제공된 파일 외에 디버깅에 필요한 PDB 또는 기타 파일을 생성할 수 있습니다.
3. CoreRT를 사용하는 경우 시간이 지남에 따라 채워지는 일부 디버깅 기능이 있을 수 있습니다(특히 Linux/Mac에서).

"pdb 파일 포함"이라고 말할 때 단일 파일 _inside_를 원하십니까 아니면 단일 파일 빌드를 디버그해야 할 경우에 대비하여 파일을 생성하고 매달리는 기능을 원하십니까?

1) 우리에게는 문제가 되지 않습니다. E&C는 일상적인 배포가 아닌 실제 배포에만 사용되기 때문에 여기서는 관련이 없습니다.
2) 이상적으로는 PDB를 포함한 모든 것에 대해 하나의 파일이 있고 측면에 하나의 파일과 pdb 세트가 있는 것이 아닙니다. 임베디드 PDB 옵션이 이미 있습니다. 작동한다면 훌륭할 것입니다.
3) 디버그에 대해 말할 때 나는 디버거를 라이브로 연결하는 것보다 생산 시간에 대해 더 많이 이야기하고 있습니다. 보다 구체적으로, 파일 및 줄 번호를 포함하는 스택 추적 정보, 덤프를 읽을 때 기호를 확인할 수 있는 등

1. 주로 서비스이지만 일부 UI
2. 일부는 하지만 이것은 긴급하지 않을 것입니다
3. 네
4. 네
5. 몇 초면 OK
6. 우리에게 중요하지 않습니다. dll 크기의 합은 괜찮습니다.
7. 이상적으로는
8. 크기는 우리에게 가장 중요한 것이 아닙니다.

우리에게 또 다른 질문은 개별 구성 요소(아마도 단계적)에 대해서도 이 작업을 수행할 수 있는지 여부입니다. 예를 들어 많은 종속성을 사용하는 라이브러리 dll이 있습니다. 우리가 그것들을 패키징할 수 있다면 버전 관리 등의 수고를 덜 수 있을 것입니다. 이것들이 차례로 exe로 패키징될 수 있다면 훨씬 더 좋을 것입니다.

1. 서비스 및 일부 UI.
2. 지금은 아닙니다.
3. 네. 이상적으로는 폴더에서 로드할 수 있고 런타임에 다시 로드할 수 있는 플러그인입니다.
4. 네
5. 우리가 10-15+를 밀어붙이지 않는 한 문제가 되지 않습니다.
6. DLL 크기의 합계 또는 이와 유사한 것입니다.
7. 네. 프로덕션 빌드 시간의 경우 디버그/테스트 빌드가 상당히 빠르게 빌드되는 한 실제로 문제가 되지는 않습니다.
8. 에 따라 다르지만 옵션이 편리할 것입니다.

1. 서비스와 UI.
2. 때때로.
3. 예, 일반적으로.
4. 네.
5. 5초 이내로 하는 것이 좋습니다.
6. UI는 5초 미만이며 서비스는 중요하지 않습니다.
7. 빌드 시간은 중요하지 않으며 최적화 효과가 가장 중요합니다.
8. 네.

@tpetrina @ayende @bencyoung @Kosyne @expcat 당신은 질문 3에 예라고 답했습니다("당신의 앱은 플러그인이나 당신의 앱 빌드에 원래 포함하지 않은 다른 외부 dll을 로드합니까?") - 당신의 사용에 대해 더 자세히 알려주실 수 있습니까? 사례?

단일 파일 배포의 주요 장점은 배포할 파일이 하나뿐이라는 것입니다. 앱에 별도의 파일에 플러그인이 있는 경우 여러 파일이 있는 단일 파일 배포에서 얻을 수 있는 가치는 무엇입니까? "app.exe+plugin1.dll+plugin2.dll"이 "app.exe+coreclr.dll+clrjit.dll+...+plugin1.dll+plugin2.dll"보다 나은 이유는 무엇입니까?

app.exe + 300+ dll - 오늘날의 현재 상태는 정말 어색합니다.
app.exe + 일반적으로 사용자 자신이 정의하는 1-5개의 dll이 훨씬 쉽습니다.

우리의 시나리오는 사용자가 특정 확장을 허용하므로 일반적으로 단일 exe 만 배포하고 사용자는 필요에 따라 추가 기능을 추가할 수 있습니다.

우리가 그렇게 할 _계획_은 아니지만, 필요할 경우 그렇게 하기를 _할 수 있기를 원합니다.

@ayende 우리와 동일하게 동의했습니다.

또한 dll 수준에서 이를 수행할 수 있다면 클라이언트 어셈블리와 충돌하지 않도록 어셈블리 내부에 종속성을 패키징할 수 있습니다. 즉, NewtonSoft.Json의 버전을 선택하면 현재 동일한 폴더에 있는 모든 프로그램, 플러그인 및 타사 어셈블리에 대해 정의하고 있지만 이를 포함할 수 있다면 타사에서 유연성을 확보하고 버전 호환성을 높일 수 있습니다.

@ayende 에 동의합니다.

답변해 주셔서 감사합니다! 네이티브 코드를 사용하거나 플러그인을 로드해야 하는 사람들의 수에 따라 우리가 관리할 수 있는 가장 호환되는 접근 방식이 시작하기에 가장 적합한 곳이라고 생각합니다. 이를 위해 "포장 및 추출" 접근 방식을 사용합니다.

이것은 본질적으로 모든 애플리케이션과 .NET 파일을 추출기 실행 파일에 리소스로 포함하는 도구가 될 것입니다. 실행 파일이 실행되면 해당 파일을 모두 임시 디렉터리에 추출한 다음 앱이 단일 파일이 아닌 응용 프로그램으로 게시된 것처럼 실행됩니다. 압축으로 시작하지는 않지만 보증된다면 향후 추가할 수 있습니다.

이 계획의 가장 까다로운 세부 사항은 파일을 추출할 위치입니다. 다음과 같은 여러 시나리오를 고려해야 합니다.

• 첫 번째 실행 - 앱은 디스크의 어딘가에 추출하기만 하면 됩니다.
• 후속 실행 -- 모든 실행 시 추출 비용(몇 초 정도)을 지불하지 않으려면 추출 위치를 결정적으로 지정하고 두 번째 실행에서 첫 번째 실행에서 추출한 파일을 사용할 수 있도록 하는 것이 좋습니다.
• 업그레이드 -- 애플리케이션의 새 버전이 실행되면 이전 버전에서 추출한 파일을 사용해서는 안 됩니다. (반대의 경우도 마찬가지입니다. 사람들은 여러 버전을 나란히 실행하기를 원할 수 있습니다.) 이는 결정적 경로가 애플리케이션의 내용을 기반으로 해야 함을 시사합니다.
• 제거 -- 원하는 경우 사용자가 추출된 디렉터리를 찾아 삭제할 수 있어야 합니다.
• 내결함성 -- 콘텐츠를 부분적으로 추출한 후 첫 번째 시작이 실패하면 두 번째 시작에서 추출을 다시 실행해야 합니다.
• 관리자 권한으로 실행 -- 무결성이 낮은 프로세스가 변경되는 것을 방지하기 위해 관리자로 실행되는 프로세스는 관리자 쓰기 가능한 위치에서만 실행해야 합니다.
• 상승되지 않은 상태로 실행 -- 관리자 권한 없이 실행되는 프로세스는 사용자가 쓸 수 있는 위치에서 실행해야 합니다.

다음을 포함하는 경로를 구성하여 이 모든 것을 설명할 수 있다고 생각합니다.

1. 잘 알려진 기본 디렉토리(예: Windows에서는 %LOCALAPPDATA%\dotnetApps, 다른 OS에서는 사용자 프로필 위치)
2. 상승된 별도의 하위 디렉토리
3. 애플리케이션 ID(exe 이름일 수도 있음)
4. 버전 식별자입니다. 숫자 버전은 유용할 수 있지만 정확한 종속성 버전도 통합해야 하므로 충분하지 않습니다. 빌드별 guid 또는 해시가 적절할 수 있습니다.

함께 보면 c:\users\username\AppData\Local\dotnetApps\elevated\MyCoolApp\1.0.0.0_abc123\MyCoolApp.dll
(앱 이름이 MyCoolApp인 경우 버전 번호는 1.0.0.0이고 해시/guid는 abc123이며 상승된 버전으로 출시되었습니다.)

추출기에 파일을 삽입하는 작업도 필요합니다. Windows에서는 단순히 기본 리소스를 사용할 수 있지만 Linux 및 Mac에서는 사용자 지정 작업이 필요할 수 있습니다.

마지막으로 호스트(추출된 파일 찾기) 및 진단(DAC 또는 기타 파일 찾기)에서 조정이 필요할 수도 있습니다.

CC @swaroop-sridhar @jeffschwMSFT @vitek-karas

나는 이 치료법이 질병보다 더 나쁘다고 느낀다. 외부 디렉토리(OS마다 다름), 업데이트, 제거 등을 처리해야 하는 경우 처음에 이 기능을 원하는 이유(모든 것을 단순하고, 휴대 가능하며, 독립적이고 깨끗한 상태로 유지)에 반대합니다.

이것이 절대적으로 이 방식이어야 하는 경우 내 프로젝트의 경우 단일 기본 실행 파일과 압축을 푼 파일이 해당 실행 파일과 함께 디렉토리에 있거나 해당 디렉토리가 어디로 갈지 결정할 수 있는 기능을 훨씬 선호합니다.

저만 그런건지 다른 분들의 의견도 궁금합니다.

여기에 동의해야 합니다. 다른 디렉토리를 사용하면 많은 흥미로운 문제가 있을 수 있습니다. 예를 들어 exe와 함께 구성 파일을 배치하면 "실제" 디렉토리가 다른 곳에 있기 때문에 이 exe가 선택되지 않습니다.
디스크 공간은 액세스 정책 등으로 인해 임의의 파일 잠금에 문제가 될 수 있습니다. pp.
이 기능을 사용하고 싶지만 이전에 감지할 수 없는 다양한 실패 모드가 추가된다면 사용하지 않을 것입니다.

@Kosyne 에 동의 - 제안된 초기 솔루션은 일종의 "설치 프로그램"을 단순히 자동화하는 것 같습니다. 그것이 우리가 한 명의 간부로 해결하려는 문제의 한계였다면 우리 모두가 그 자동화를 스스로 수행했을 것이라고 생각합니다.

단일 실행 제안의 주요 목표는 관리되지 않는 시스템에서 실행 파일을 실행할 수 있어야 합니다. 선택한 대상 "설치" 디렉토리에 대한 쓰기 권한이 있는지 누가 알겠습니까? 물론 시작 후 자체적으로 인공물을 남기지 않아야 합니다(기본값 아님).

위의 사항을 만족시키기 위해 기존 제안을 약간 수정한 것입니다. 메모리에 압축을 풀고 거기에서 실행할 수 없습니까?

나머지 의견에 동의합니다. 다른 위치로 압축을 푸는 것은 _이미_ 사용할 수 있는 것입니다.
추출된 값을 상당히 쉽게 실행할 수 있는 자체 압축 해제 zip을 가질 수 있습니다. 이것은 이것이 대답하기 위한 것이며 설치의 또 다른 이름일 뿐이라는 많은 우려에 대답하지 않습니다.

파일의 위치가 중요합니다. 예를 들어, 우리의 경우 다음을 의미합니다.

• 구성 파일 찾기(없으면 즉석에서 생성하고 사용자가 사용자 지정할 수 있음)
• 일반적으로 소스 exe와 관련된 데이터 파일 찾기/만들기.
• 적절한 모니터링/지원을 위해 PID/프로세스 이름이 일치해야 합니다.

사용자 중 한 명이 실제로 HD를 실행할 수 없는 시스템에서 DVD에서 소프트웨어를 실행해야 합니다. 어떻게 작동합니까?

나는 모든 것을 기억 속에하는 것이 더 낫다는 데 동의합니다. 그리고 시작 시간에 대한 우려는 그리 크지 않습니다. 다시 시작할 때마다 이 비용을 지불하거나 필요한 경우 수동으로 이를 완화하는 단계를 수행하는 것이 좋습니다.

여기서 또 다른 문제는 실제 크기입니다. 이것이 단지 (효과적으로) 설치 프로그램이라면 수백 MB의 합리적인 앱에 대한 파일 크기에 대해 이야기하고 있음을 의미합니다.

제안된 솔루션을 구축하는 데 CLR 변경이 필요하지 않은 것 같습니다. 사용자는 이미 이와 같은 솔루션을 구축할 수 있습니다. 이것을 CoreCLR에 추가하는 것은 의미가 없습니다. 특히, 이에 대한 사용 사례는 상당히 좁고 구체적이기 때문입니다.

@GSPP 이것은 기본적으로 오늘 7z-Extra 로 할 수 있는 일인 것 같습니다. 이 경우라면 아예 갖지 _않는_ 것이 낫다는 데 동의합니다.

이 파티에 늦어서 죄송합니다. 추적 중인 중복 티켓에 게시된 링크를 따라가서 여기까지 왔습니다.
여기에서 최신 댓글을 읽은 후 포장 및 추출을 고려하고 있는 것을 보니 유감입니다. 이것은 지나친 것 같습니다. 기본 콘솔 앱용 SFA 배포 기능으로 시작하는 것이 어떻습니까? 단일 파일에 있는 일부 네트워크, IO 및 일부 외부 종속성(nuget 등)을 사용하여 기본적인 콘솔 앱을 만드는 것이 가능해야 하는 것 같습니다.
내가 말하려는 것은 모든 사람의 요구 사항을 수집하는 대신 아무도 요구하지 않는 사항을 수집하는 대신 모든 사람에게 의미가 있고 결과를 빠르게 산출하는 첫 번째 반복으로 작게 시작하라는 것입니다.

이것은 기본적으로 오늘 7z-Extra로 할 수 있는 것 같습니다.

이 문제를 해결하기 위한 프로그래밍 환경에 구애받지 않는 솔루션이 오늘날 많이 존재한다는 것은 맞습니다. 많은 것 중 또 다른 예: https://www.boxedapp.com/exe_bundle.html

여기에 추가된 가치는 전문가가 아닌 사용자도 쉽게 수행할 수 있도록 dotnet 도구에 통합하는 것입니다. 전문가 사용자는 귀하가 지적한 대로 기존 도구를 함께 연결하여 오늘날 이 작업을 수행할 수 있습니다.

개인적으로, 나는 우리가 여기서 올바른 선택을 하고 있는지 명확하지 않다는 점에 동의합니다. 우리는 핵심 팀 내에서 이에 대해 많은 토론을 했습니다.

인턴을 배치하고 글로벌 도구(권장되지만 지원되지는 않음)를 사용하는 것도 마찬가지이며 설치도 상당히 쉬울 수 있습니다.

효과적으로, 우리는 dotnet publish-single-file 에 대해 이야기하고 있으며 이는 무대 뒤에서 필요한 모든 것을 수행할 것입니다.

이 시나리오를 지원하기 위해 프레임워크나 런타임에 실제로 필요한 것은 아무것도 없으며, 이것을 프레임워크 외부에 명시적으로 만들면 사용자가 이를 수정하는 방법에 대해 훨씬 더 많은 자유를 얻을 수 있습니다.
프레임워크를 변경하려는 경우 얻을 수 있는 PR(모든 관련 행사, 백워드 컴팩트, 보안 등)을 얻을 "필요"가 없습니다.
일반적인 부업 프로젝트를 포크하고 사용하면 됩니다.

내가 이 기능을 원하는 만큼 외부에서 잘 할 수 있는 어떤 것(그것이 _항상_ 있을 것이라는 의미)은 갖고 싶지 않습니다.

더 높은 수준의 질문을 하고 싶습니다. 단일 파일 배포를 원하는 고객의 주된 동기는 무엇입니까?
주로:

1. 포장? 그렇다면 솔루션이 받은 편지함이든 타사 도구이든 관계없이 가장 중요한 특성은 무엇입니까?
   a) 시작 시간(첫 실행 이후)
   b) 쓰기 불가능한 환경에서 실행하는 기능
   c) 실행 후 파일을 남기지 않음
   d) 설치 프로그램을 실행할 필요 없음
   2) 성능?
   a) 속도(네이티브 코드의 정적 링크, 다중 라이브러리 로드 방지, 모듈 간 최적화 등)
   b) 코드 크기(인증서 하나만 필요, 트리 쉐이킹 등)
   3) 다른 사람이 있습니까?

일부 사람들은 이 기능을 그다지 중요하지 않은 것으로 읽거나 적어도 여기의 핵심 기능 세트에 포함하는 것이 좋은 목표가 아닐 수도 있다고 생각합니다. 더 큰 응용 프로그램의 서비스 또는 하위 모듈 역할을 하는 모든 응용 프로그램에 대해 매우 강력할 것이라고 생각한다는 점을 반복하고 싶습니다. 작성자가 개발자가 아닐 수도 있습니다. 설치(자동 또는 기타)로만 해결할 수 있는 종속성 요구 사항 또는 사용자의 추가 보안 상승이 필요할 수 있는 디스크의 사후 실행 아티팩트 등을 전달하고 싶지 않습니다.
현재로서는 .NET이 이 틈새 시장에 적합한 선택이 아닙니다. 그러나 (그리고 IMO이어야 함) 그럴 수 있습니다.

컴파일된 실행 파일은 다음을 충족해야 합니다.

• 모든 관련 종속성 패키지
• 실행 아티팩트 없음(디스크 쓰기 없음)

Re @swaroop-sridhar 감히 모든 응용 프로그램에는 고유한 성능 요구 사항이 있으므로 핵심 솔루션을 다룬 후 가장 좋은 방법은 매달린 과일을 골라 거기에서 시작하는 것이라고 생각합니다.

@swaroop-sridhar 저에게 이것은 최종 사용자를 위한 패키징과 사용 용이성에 관한 것입니다.
시스템 전반에 걸친 설치를 처리할 필요가 없습니다. 클릭하고 실행하기만 하면 됩니다.

이는 소프트웨어를 포함할 수 있도록 하고 단일 파일 애드온을 관리하기가 훨씬 쉽기 때문에 중요합니다.

@strich 임베딩에 대한 요점은 좋은 것입니다. 우리는 일반적으로 마이크로 서비스 아키텍처의 구성 요소로 사용되며 배포 오버헤드를 줄이면 쉽게 만들 수 있습니다.

문제는 이것이 중요한 기능인지 아닌지가 아닙니다. 문제는 제안된 솔루션(이 시점에서 본질적으로 압축)이 _핵심에_ 있어야 한다는 것입니다.
핵심에 있는 것은 변경에 대해 훨씬 더 높은 기준을 가지고 있습니다. 이것을 외부 도구로 사용하면 수정 및 확장이 더 쉽기 때문에 더 좋습니다.

솔직히 말해서 더 나은 옵션을 보는 것이 훨씬 낫습니다. 예를 들어, 파일 대신 메모리에서 dll을 로드하는 것이 가능합니다(일부 작업이 필요하지만 가능함).
그런 일이 발생하면 순수 메모리에서 압축 풀기를 수행하고 디스크 히트 없이 _전체_ 일을 실행할 수 있습니다.

이는 핵심에 있어야 하는 것인데, 이를 가능하게 하려면 런타임을 수정해야 할 가능성이 매우 높기 때문입니다.
그리고 그것은 그 자체로 가치가 있을 것입니다. 그리고 현재 우리가 할 수 있는 일이 아닙니다.

따라서 Hashicorp's Consul과 같은 Go 도구의 경험을 살펴보는 것이 좋은 예입니다. 모든 시스템에 드롭할 수 있는 단일 exe 파일이 실행됩니다. 설치 프로그램이 없고, 폴더를 복사하지도 않고, 수백 개의 파일 목록에서 구성 파일을 찾을 필요도 없고, 정말 좋은 최종 사용자 경험입니다.

플러그인 dll에서도 작동하기를 원하기 때문에 메모리 내 접근 방식이 작동할지 확신할 수 없습니다(따라서 플러그인 삭제는 종속성 전체가 아니라 단일 파일이기도 함). 그러나 모든 진행 상황은 잘해. 우리는 Fody.Costura를 살펴보았고 일부 항목에서는 잘 작동하지만 .NET Core에 문제가 있었습니다.

따라서 좋은 예는 Hashicorp의 Consul과 같은 Go 도구의 경험을 살펴보는 것입니다.

어, 영사 같은 도구의 경우 이상적인 솔루션은 이 자체 추출 즉흥 연주가 아니라 corert입니다.

@mikedn 왜 그래? AOT 또는 JIT 컴파일이 배포 방법과 어떤 관련이 있는지 모르겠습니다.

@strich 의 말을 두 번째로 하고 싶습니다. 단일 파일 배포는 마이크로서비스 아키텍처 배포뿐만 아니라 명령줄이 있는 작은 도구이거나 최소한 수명이 시작되는 모든 콘솔 앱에 신선한 공기가 될 것입니다. 스위치.

왜 그래? AOT 또는 JIT 컴파일이 배포 방법과 어떤 관련이 있는지 모르겠습니다.

원하는 것을 정확하게 제공하기 때문입니다. 단일 exe 파일을 모든 시스템(적절한 OS가 있는 모든 시스템, 결국 기본 파일)에 놓고 실행할 수 있습니다. 또한 리소스를 덜 사용하는 경향이 있으므로 영사와 같은 에이전트에게는 좋은 것입니다. 자체 추출 솔루션 이상으로 Go가 제공하는 것과 거의 동일합니다.

@mikedn 추측하지만

1) 아직 프로덕션 형태로 존재하지 않습니다(내가 아는 한)!
2) 동적 기능을 많이 사용합니다(IL 생성, 임의 반사)
3) 우리는 여전히 플러그인을 추가할 수 있기를 원합니다(다시 이상적으로 압축됨)

이 문제는 사람들에게 원하는 것이 무엇인지 묻는 것이므로 우리는 우리의 의견을 제시할 뿐입니다! 이 이점을 얻기 위해 다른 런타임 모델로 전환해야 하는 것은 아닙니다. 나에게 그것들은 직교적 관심사다.

AOT 또는 JIT 컴파일이 배포 방법과 어떤 관련이 있는지 모르겠습니다.

JIT가 없으면 디버깅 스토리와 같은 내용을 충분히 쉽게 얻을 수 있습니다. JIT 부분은 문제를 더 어렵게 만들기 때문에 Go에서 찾을 수 없습니다. 이것은 엔지니어링이므로 더 어려운 문제에 더 많은 엔지니어를 투입하고 새로운 복잡성으로 살아가거나 다른 곳에서 범위를 좁힐 수 있습니다. Self-extractor는 필요한 기술을 가진 엔지니어의 수가 제한되어 있기 때문에 범위를 줄이는 것입니다.

Go 프로젝트(JIT 요구 사항 없음)와 유사한 프로젝트를 가진 사람들은 "실험적" 레이블만 있으면 CoreRT에 매우 만족할 수 있습니다. 요즘 은 시도하기가 매우 쉽습니다 . 전체 CoreCLR과 동일한 가비지 수집기, 코드 생성기, CoreFX 및 CoreLib의 대부분을 사용하고 자체 포함된 작은 실행 파일(한 자리 메가바이트)을 생성합니다.

그것은 실제로 아직 생산 형태로 존재하지 않습니다(내가 아는 한)!

예, 내 의견은 주로 MS 사람들을 대상으로 했습니다 . 그들은 이 모든 병렬, 관련, 진행 중인 프로젝트/아이디어(corert, illinger)를 가지고 있으며 이제 하나 더 추가합니다. 이 자체 추출 기능은 이미 많은 사람들이 지적했듯이 "음, 우리는 할 수 있습니다. 우리 자신" 그런 것. 그리고 파일을 "숨겨진" 디렉토리로 추출하는 것과 같은 단점도 있습니다.

우리는 많은 동적 기능(IL 생성, 임의 반사)을 사용합니다.

그것은 커뮤니티 전체가 다시 생각해 볼 수 있는 것입니다. 물론 그렇게 할 수 있으면 유용하지만 단일 파일 배포와 같은 다른 요구 사항과 충돌합니다. 여전히 단일 파일 배포를 얻을 수 있지만 비용이 많이 드는 경향이 있습니다. 즉, 다소 큰 파일입니다. 당신이 그것으로 괜찮다면 그것은 완벽합니다. 그러나 내 경험상 파일이 커질수록 "단일 파일" 측면이 덜 유용해집니다.

@MichalStrehovsky 확실히 다른 옵션이 있습니다. 그러나 우리는 실험적인 방법을 사용할 수 없으며(.NET Core로 이동할 때가 되었다고 확신하는 것은 충분히 어렵습니다) 임시 폴더로 추출하는 것이 우리의 경우에도 작동하지 않을 것이라고 생각합니다. 그러나 최악의 경우는 이 기능을 사용하지 않고 계속 진행하는 것입니다.

비록 그것이 우리가 원하는 대로 진행된다면 그것은 우리가 원하는 것입니다 :)

@mikedn 동의합니다. 다중 병렬 솔루션은 훨씬 더 혼란스럽습니다. 우리의 이상적인 솔루션은 일종의 슈퍼 ILLinker/weaver 접근 방식일 것이라고 생각하지만 이 방법을 실행하고 우리가 어디로 가는지 알게 되어 기쁩니다.

이 기능이 출시된 것에 대해 정말 흥분되지만 @morganbr을 게시한 초기 제안에 대해서도 마찬가지로 흥분되지 않습니다. 귀하가 제기한 질문 목록에 대한 제 답변은 다른 사람들이 게시한 것과 유사하지만(그래서 공통적으로 원하는 기능 세트가 있다고 생각합니다), IMHO가 제안한 '디스크에 압축 풀기' 솔루션은 제가 보기를 바라는 것이 전혀 아닙니다. 구현되고 다른 사람들이 말했듯이 '질병'보다 거의 더 나쁠 것입니다. @jkotas

@strich 및 @ayende에 동의합니다.
컴파일된 실행 파일은 다음을 충족해야 합니다.
모든 관련 종속성 패키지
실행 아티팩트 없음(디스크 쓰기 없음)

디스크 대신 메모리에서 .dll을 로드하는 것은 쉽지 않을 수 있지만, 이는 IMO가 다음과 같이 구현할 수 있는 위의 제안과 비교하여 MSFT 저수준 개발자의 깊은 전문 지식을 가질 만한 가치가 있는 기능입니다. 외부 도구(이미 가지고 있음, https://github.com/dgiagio/warp 참조). 이것이 달성되면 첫 번째 실행과 후속 실행 사이에 시간 차이가 얼마나 나는지 궁금합니다. 영감/예를 들어 Linux 3.17+에는 dlopen에서 사용할 수 있는 memfd_create가 있다고 생각합니다.

다른 주제로 플러그인 지원 요구 사항이 디자인 제안을 과도하게 인덱싱하는지 궁금합니다. 이 기능을 옵트인하여 이 기능이 필요한 사람만 잠재적인 불이익(트리 쉐이킹 부족 등)을 일으키고 다른 모든 사람(대다수?)은 배포 가능한 크기를 줄이고 성능 이점(?)

@swaroop-sridhar @MichalStrehovsky 로 한 걸음 물러나면, 하나의 솔루션으로 모든 사람을 수용하기 어려울 만큼 충분히 다른 목표/욕구를 가질 수 있는 두 가지 광범위한 사용 사례를 볼 수 있습니다.

• CLI 도구는 매번 빠르게 실행되고 소규모 배포가 가능하기를 이상적으로 원합니다. CoreRT에 더 적합할까요?
• 마이크로서비스는 JIT 및 동적 코드 기능과 같은 더 풍부한 기능을 대가로 더 긴 최초 실행(이상적으로는 <1s), 더 큰 배포를 허용할 수 있습니다.

이 브레인 덤프가 의미가 있기를 바랍니다. 바보가 되려는 것이 아니라 이 주제에 매우 관심이 있기 때문에 피드백을 제공하십시오. 모든 노고에 감사드리며 커뮤니티의 의견을 요청합니다! :)

플러그인 정보.
기본적으로 내가 원하는 유일한 것은 Assembly.LoadFrom 또는 LoadLibrary 호출에서 차단되는 _not_ 것입니다.
다른 건 필요 없고 나머지는 혼자 할 수 있어요.

@ayende "LoadFrom 등에서 차단됨"이 무엇을 의미하는지 좀 더 자세히 설명해 주시겠습니까?

예를 들어, 이에 대한 제안 중 일부는 CoreRT를 포함했는데, 이는 우리가 (아마도) 관리되는 dll을 로드할 수 없다는 것을 의미합니다.
그러나 관리되는 dll에 대한 경로를 제공하고 어셈블리를 가져오거나 네이티브 dll에서 LoadLibrary 를 호출할 수 있는 한 플러그인 메커니즘으로 괜찮습니다.

플러그인 시나리오는 _고려해야 하는 것이 아니라 _차단_되어서는 안되는 것입니다.

나는 코드를 파헤치는 데 시간을 보냈고, 언뜻 보기에 다음과 같이 _가능_해야 하는 것처럼 보입니다(Windows에 대해서는 간단하게 설명하기만 하면 됨).

• 전체 CoreCLR을 exec에 압축합니다(임베디드 리소스 또는 이와 유사한 것으로 가정해 봅시다).
• 기본 dll을 열거하고 MemoryModule (https://github.com/fancycode/MemoryModule)와 같은 것을 호출하여 메모리에 로드합니다.
• 런타임을 호출하고 메모리에서 어셈블리를 로드합니다.

나는 이것이 그렇게 간단하지 _않은_ 것이라고 가정할 것입니다. 예를 들어, ICLRRuntimeHost2::ExecuteAssembly 는 버퍼를 제공하는 방법을 제공하지 않으며 디스크에 있는 파일만 제공합니다.
그것은 (내가 확신하는 많은 것 중) 실제로 작동하게 만드는 첫 번째 쇼 스토퍼가 됩니다.

관련 항목을 실패할 수 있는 파일로 참조할 수 있는 코드가 많이 있다고 확신합니다. 하지만 이것이 제가 단일 파일 실행을 원하고 왜 그런 종류의 솔루션은 외부에서가 아니라 CoreCLR에서 수행해야 합니다(zip 예제에서와 같이).

MemoryModule과 같은 것을 호출하십시오.

MemoryModule을 사용하여 로드된 바이너리는 진단할 수 없으며(예: 일반 디버거, 프로파일러 등이 작동하지 않음) MemoryModule은 내장된 모든 OS 보안 조치(예: 바이러스 백신 등)를 건너뜁니다. 지원되는 솔루션으로 제공할 수 있는 항목이 아닙니다.

나는 이것이 그렇게 간단하지 않다고 가정할 것이다.

확장되지 않은 단일 파일 번들에서 실행을 지원하려면 새로운 API(관리형 및 비관리형 모두)가 필요합니다. 기존 프로그램과 라이브러리는 "그냥 작동"하지 않습니다.

안티 맬웨어 검사 인터페이스가
최근처럼 MemoryModule에서 Windows 엔지니어가 구현했습니다.
mem에서 로드된 어셈블리를 포함한 모든 .net 어셈블리?

https://twitter.com/WDSecurity/status/1047380732031762432?s=19

편집: 흠 MemoryModule은 기본 모듈을 로드하기 위해 OS에 내장된 것처럼 들리지만 분명히 그렇지 않습니다. 위의 제안을 무시하기에 충분한 이유일 것입니다.

2018년 12월 5일 수요일 01:46 Jan Kotas [email protected] 이 다음과 같이 썼습니다.

MemoryModule과 같은 것을 호출하십시오.

MemoryModule을 사용하여 로드된 바이너리는 진단할 수 없습니다(예:
일반 디버거, 프로파일러 등)에서 작동하고 MemoryModule
구축된 모든 OS 보안 조치(예: 바이러스 백신 등)를 건너뜁니다. 그렇지 않다
지원되는 솔루션으로 제공할 수 있는 것입니다.

나는 이것이 그렇게 간단하지 않다고 가정할 것이다.

맞습니다. 새로운 API(관리형 및 비관리형 모두)가 필요합니다.
확장되지 않은 단일 파일 번들에서 실행을 지원합니다. 기존
프로그램과 라이브러리는 "그냥 작동"하지 않습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/coreclr/issues/20287#issuecomment-444314969 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEBfudvVHxpbeKa-L_vTQjbnNZZsn6Meks5u1xdlgaJpZM4XK-X_
.

모든 피드백에 감사드립니다.
단일 파일 배포를 지원하기 위한 업데이트된 계획을 곧 게시할 예정입니다.

@NinoFloris 참조 dotnet/coreclr#21370

이 토론에 늦었다는 것을 알고 있으므로 도움이 되지 않으면 사과드립니다.

@mikedn 이 말한 것을 반복하기 위해, 이러한 모든 병렬 솔루션을 갖는 것은 혼란스러울 수 있으며, 미래에 MS의 초점이 어디에 있을 것인지에 대한 질문을 던집니다. CoreRT에서 수행된 뛰어난 작업은 공식 로드맵 없이 여전히 실험적이라는 레이블이 지정되어 있고 CoreCLR(CPAOT, 현재 단일 파일 게시)에서 유사한 기능이 구현되어 기술을 기반으로 비즈니스 결정을 내리기가 어렵습니다. 다시는 말을 잘못 선택하고 싶지 않습니다(Silverlight...).

CoreRT의 뛰어난 런타임을 고수하고 기본 코드를 빌드하면서 전체 프레임워크 기능을 원하는 사람들을 위해 CoreRT에 JIT 통합(그리고 준비될 때까지 인터프리터 작업 확장) 작업에 집중하는 것은 어떻습니까? JIT 기능을 원하는 경우 메타데이터와 JIT를 CoreRT 고유하게 컴파일된 실행 파일 내부에 유지하는 것이 가능하지 않을까요?
이것이 모든 세계의 최고가 아니겠습니까? 예. 가장 작은 실행 파일, 가장 빠른 시작 시간, JIT를 배치하고 전체 프레임워크 기능을 유지하려는 사람들을 위해 메타데이터 및 IL 코드를 유지함으로써 CoreRT의 AOT 코드 제한을 확장할 수 있습니다.
IMO는 장기적인 목표를 방해할 수 있는 단기 기능 대신 '최상의' 솔루션에 초점을 맞춰야 합니다.

내가 틀렸을 수도 있지만 CoreCLR의 일부로 단일 파일 게시를 사용하면 고객이 CoreRT에서 멀어지게 되므로 많은 경우에 잠재적으로 더 나은 솔루션이 될 수 있다고 생각합니다. 예. 이것이 "이제 .NET 코드를 단일 파일로 게시할 수 있습니다"라는 상표가 붙었지만 거대한 파일을 만들고 시작 성능 등에서 어려움을 겪을 것입니다. 그러면 사람들이 이 "비대해진 .NET 런타임"에 대해 불평하기 시작하는 것을 볼 수 있습니다. . .NET은 실제로 CoreRT에서 정확히 이에 대한 훌륭한 솔루션을 이미 가지고 있지만, 공식 지원/공식 제품 약속은 부족합니다.

아마도 내 관심사는 병렬 제품(다시 @mikedn 인용)을 줄이고 여기에 있는 제품(로드맵 공유 포함)에 대한 깊은 약속, 확장 및 지원에 더 중점을 두고 싶다는 것입니다.

덜 병렬 제품

.NET Core라는 하나의 제품만 있습니다. CoreRT는 별도의 제품이 아니며 앞으로도 없을 것입니다. 이것은 하나의 제품에 옵션을 추가하는 것입니다. 다음은 현재 사용할 수 있는 옵션의 몇 가지 예입니다. 워크스테이션 GC 및 서버 GC; 독립형 앱 게시 대 프레임워크 종속 앱 게시.

@jkotas 이해하고 옵션을 추가하는 것이 일반적으로 훌륭하다는 데 전적으로 동의합니다. "제품"이라는 단어를 "옵션/솔루션"으로 바꾸면 .NET Core 전체 제품 내부의 옵션/솔루션으로 CoreRT에 대한 우리 제품의 약속이 우리가 할 수 있는 것인지 완전히 알지 못한다는 우려가 있습니다. 앞으로 몇 년 동안 안전하게 지원받을 수 있습니다. API가 시간이 지남에 따라 예측할 수 없는 주요 변경 사항을 만들고 API를 신뢰할 수 있는지 여부를 모르는 상태에서 갑자기 사용 중단된다면 어떨지 상상해 보세요. MS가 아닌 엔터티에게는 제품의 일부인 도구/옵션이 동일하게 느껴집니다. CoreCLR로는 (적어도 현재로서는) 할 수 없는 CoreRT의 여러 기능에 의존하고 있습니다(그 중 하나는 PACE로 실행 파일을 보호하고 많은 메타데이터, IL 등을 제거하는 기능입니다. 쉬운 정적 링크, 기본 플랫폼에 대한 더 쉬운 이해, 난독화를 컴파일러에 직접 구축할 가능성 등). 기본적으로 CoreRT에 대한 귀하와 Michal 및 다른 사람들의 작업은 IMO가 처음 설계된 이후로 .NET 생태계에서 일어난 최고의 일 중 하나이기 때문에 우선 순위가 높아야 한다고 생각합니다. 새로운 도구/옵션에 대한 이야기가 있을 때마다 내부적으로 CoreRT 옵션이 완성되고 확장되는 대신 CoreRT와 경쟁하는 것처럼 보일 수 있으며 리소스 할당이 잘못된 것처럼 느껴집니다. 죄송합니다. 토론을 끌려는 의도는 아니었습니다. CoreRT 작업이 얼마나 감사한지, 그리고 우리 중 일부는 이것이 플랫폼의 미래가 되어야 한다고 믿습니다.
나는 이 토론을 더 이상 더럽히지 않을 것입니다. 팀을 위해 최선을 다하고 당신이 무엇을 생각해 내든 기대하며, 나는 그것이 훌륭할 것이라고 확신합니다.

@christianscheuer 이 문제 및 기타 CoreRT 관련 문제에 대한 귀하의 피드백은 매우 중요합니다. 당신은 이 토론을 전혀 더럽히지 않습니다.

CoreRT와 경쟁하는 것처럼 내부적으로 볼 수 있는 새로운 도구/옵션에 대한 이야기가 있습니다.

핵심 팀 사이에서 우리는 다양하고 야심 차거나 더 미친 옵션에 대해 이야기하고 있습니다. 나는 "디스크에 압축 풀기"를 CoreRT 전체 AOT의 중요한 경쟁자로 생각하지 않습니다. 각각은 .NET 사용자/앱의 다른 세그먼트를 대상으로 합니다.

다양한 채널(github 문제 또는 고객과의 대면 대화 포함)에서 데이터를 수집하는 우리 제품 관리 팀은 여기에 제안된 것과 같은 솔루션이 가장 큰 효과를 볼 수 있다고 제안했습니다. 우리는 이 권리에 대한 모든 데이터를 보유하고 있으며 원하는 결과를 얻을 수 있음을 여전히 검증하고 있습니다.

이 시점에서 CoreRT 기술이 지원되는 .NET Core 제품의 일부로 제공될 때를 약속할 수 없습니다. 고유한 장점이 있다는 것을 알고 있으며 궁극적으로 혜택을 받는 중요한 .NET 사용자 세그먼트를 위해 이와 같은 지원 솔루션을 제공할 것이라고 확신합니다.

단일 파일 배포는 다음과 같은 경우에 적합합니다.

• 시작 시간에 영향을 미치지 않습니다(그렇지 않으면 가장 작은 응용 프로그램에서만 사용할 수 있음).
• VFS(가상 파일 시스템) 역할을 합니다. 어셈블리와 리소스를 마치 디스크에서, 응용 프로그램 폴더에 있는 것처럼 액세스할 수 있습니다.
• 앱의 "패치 가능성"에 영향을 미치지 않습니다. IE: Microsoft는 시스템 수준에서 다른 위치에서 재정의를 제공하여 포함된 경우에도 중요한 어셈블리를 패치할 수 있어야 합니다.

포함된 리소스로 어셈블리를 추출하여 임시 폴더에 복사하는 것은 Microsoft의 필수 솔루션이 아닙니다. 이를 필요로 하는 모든 고객이 쉽게 구현할 수 있습니다.

"진정한" 단일 파일 솔루션이 필요하며 많은 가치를 제공합니다.

@jkotas 귀하의 의견은 저에게 사실입니다. 회사의 .NET 개발자(LOB/백오피스/통합)가 CoreRT로 전환하도록 설득하는 데 어려움을 겪을 것입니다. 왜냐하면 그것은 그들에게 너무 많은 도약이 될 것이기 때문입니다(특히 실험적 레이블이 주어짐). 그러나 그들은 다음에서 가치를 볼 수 있습니다. 이 스레드와 같은 Core에 대한 비교적 간단한 (사용하기) 솔루션이 논의 중입니다. 감사 해요

@popcatalin81 저는 실제로 여기에서 귀하의 요점에 크게 동의하지 않습니다.

시작 시간은 많은 응용 프로그램에서 의미가 없습니다. 장기 실행 서비스의 시작 시간을 50% - 100% 늘리는 대신 배포의 운영 복잡성을 줄일 수 있습니다.

서비스 시작 시간에 30초를 추가하더라도 장기적으로 서비스에는 의미가 없습니다.
사용자 대면 응용 프로그램의 경우 킬러가 될 수 있지만 3.0이 나올 때까지 거의 모든 CoreCLR 앱은 콘솔 또는 서비스입니다.

CoreCLR에 이미 프레임워크를 애플리케이션과 번들로 묶을 수 있는 모드가 있는 것은 아닙니다(자체 포함 배포).
우리의 경우(RavenDB), 우리는 여러 목적으로 그것에 _신뢰_합니다. 첫째, 사용자가 사용하는 것과 상관없이 자체 프레임워크를 선택할 수 있는 기능입니다. 이것은 우리에게 _중요한_ 이점입니다. 이는 우리가 전역적으로 설치된 프레임워크를 사용할 필요가 없고 따라서 관리자가 프레임워크로 결정하기로 결정한 것과 관련이 없다는 것을 의미하기 때문입니다. 예를 들어 .NET 4.0은 때때로, 심지어 4.5가 나온 지 몇 년이 지난 후에도 고통스러웠습니다.
또 다른 중요한 측면은 프레임워크의 _자신의_ 포크로 실행할 수 있다는 것입니다. 이것은 우리가 변경해야 하는 일에 직면했을 때 매우 유용합니다.

그 일환으로 우리는 패치 주기에 대한 소유권을 가지며 다른 사람이 이를 방해하는 것을 원하지 않습니다.

나는 VFS를 _생각하지_ 않지만 이것이 필요하다고 생각하지 않습니다. 그리고 이 방식으로 묶인 어셈블리/네이티브 dll/리소스에 도달하기 위해 전용 API/점프를 통과해야 하는 것은 완벽합니다.

이틀 동안 @briacht 가 이 문제에 대해 지적했기 때문에 토론에서 정말 늦었습니다.
내 2센트를 추가하고 싶습니다!

먼저 @morganbr 의 질문에 대한 답변입니다.

1. Windows 앱, WPF 및 WinForms 혼합.
2. 현재 없음
3. 예, Assembly.Load를 사용하여 다양한 변형
4. 네
5. 이것이 모든 시작 시 적용되는 패널티인지 여부에 따라 다릅니다. 예, 몇 밀리초이면 5초: 아니요. 1회라면 5초면 문제없다.
6. 50MB는 <2MB에 비해 이미 상당히 큽니다... 하지만 이것이 dotnet 런타임이 포함된다는 것을 의미한다면... 좋습니다. 어쩌면 나는 다운로드를 제공할 수도 있고 제공하지 않을 수도 있습니다.
7. 릴리스 시간은 직접적인 문제는 아니지만 장기간 CPU를 많이 사용하여 CI 제공자를 화나게 해서는 안 됩니다.
8. 네!

내가 말하는 애플리케이션 Greenshot, 현재 릴리스된 버전은 여전히 ​​.NET Framework 2.0을 대상으로 하고 있지만(정말 그렇습니다) 최신 버전에서는 문제 없이 작동합니다(좋은 하위 호환성)! Zhe 다운로드는 설치 프로그램을 포함하지만 .NET Framework가 없는 경우 약 1.7MB입니다. 이것이 시작되는 디렉토리에는 1개의 .exe와 4개의 .dll이 포함되어 있으며 하위 디렉토리에도 11개의 추가 기능이 있습니다.

이전 댓글을 읽고 있었는데 많은 댓글이 내가 설치 프로그램을 사용하는 기능이 있는 무언가를 원하는 것처럼 들립니다. 이것은 현재 플랫폼 독립적인 솔루션이 없기 때문에 어느 정도 의미가 있습니다.

저는 8월에 Microsoft의 일부 사람들과 현재 주제에 대해 논의하고 있었습니다. 저의 주요 초점은 배포를 위한 응용 프로그램의 크기와 복잡성을 줄이고 시작하는 동안 많은 시간이 걸리는 어셈블리 로딩을 줄이기 위해 모든 것을 함께 연결하는 것에 대해 이야기하는 것이었습니다. 내 응용 프로그램의.

.NET Framework 4.7.1 및 dotnet core 3.0을 나란히 대상으로 하는 Greenshot의 다음 버전을 사용하면 dotnet core 3.0에 대한 결과 다운로드에는 현재 약 103개의 dll(!!!), 1개의 exe 및 15개의 추가 기능이 있습니다. . 전체 크기는 약 37MB이고 가장 큰 파일은 MahApps.Metro.IconPacks.dll(12MB!!)로 우리가 사용하는 대부분의 아이콘이 포함되어 있으며 이는 아마도 파일의 약 4%일 것입니다. 다른 많은 dll과 마찬가지로 일반적으로 코드 사용량의 50%가 많다고 가정합니다!

사용자가 응용 프로그램을 설치하고 싶지 않다면 .zip을 다운로드하고 약 118개 파일 사이에서 실행 파일을 찾으면 됩니다. 정말 좋은 경험이 아닙니다! 크기는 약 35MB(17x) 더 큰데 사용자에게 어떤 이점이 있습니까?

dotnet core 3.0이 등장하기 몇 달 전에 저는 Fody.Costura를 사용하여 여기에 설명된 작업을 거의 수행하고 있었습니다. 빌드 시 패킹 및 시작 시 언패킹! 그러나 해킹으로 파일을 추출하지 않고 단일 실행 파일을 만들 수도 있습니다. 그러나 그것은 또한 꽤 많은 문제를 일으켰기 때문에 이것은 내가 선호하는 솔루션이 아닙니다.

나는 내가 말할 수 있는 다소간 표준적인 솔루션을 기대하고 있습니다: 그것은 단지 작동합니다 ™
표준 폴더 구조를 정의하는 것이 합리적일 수 있으므로 실행 파일, 추가 정보, 라이선스 파일 등을 루트에 배치하고 다른 파일(dotnet 코어, 종속성 등)에 대해 다른 "알려진" 디렉토리를 가질 수 있습니다. 이를 통해 도구 작업이 더 쉬워지고 모든 사람이 사용하고 싶은 것과 사용하지 않는 것을 결정할 수 있는 기능을 제공할 수 있습니다. 때로는 디렉토리에서 zip을 실행해도 일부 문제가 해결됩니다.

Fody.Costury와 유사한 솔루션을 갖게 되면 언젠가는 Greenshot 배포를 단순화하기 위해 이미징을 사용할 수 있지만 크기와 로딩 시간이 직접적으로 줄어들지는 않습니다. 그래서 여기서도 시간을 보낼 수 있기를 바랍니다!

@ayend 나도 동의하지 않을 수 있게 해주세요 :)

그것이 진정한 서비스이지만 웹 애플리케이션 및 일반적으로 서버 기반 장기 실행 애플리케이션은 일회성 시작 비용의 영향을 받지 않지만 동시에 이러한 애플리케이션은 단일 파일 배포 모델의 이점을 가장 많이 볼 수 있는 애플리케이션은 아닙니다. ( 까마귀는 표준이 아닌 예외입니다 ;) )

내가 보기에 단일 파일 배포는 주로 사용자를 대상으로 하는 응용 프로그램 및 유틸리티를 대상으로 합니다. 이러한 응용 프로그램을 다운로드, 복사, 실행할 사용자. 그리고 가까운 장래에 .Net Core 3.0이 UI 라이브러리에 대한 지원을 제공할 때 이 배포 모델은 매우 보편화될 것입니다. 그러나 강조해야 할 것은 이 모델은 어떤 앱에도 적합하지 않습니다. 주요 앱은 여전히 ​​설치 프로그램을 사용합니다.

이제 문제는 임시 폴더에 복사된 이 임베디드 어셈블리 모델이 인기를 얻으면 잘 작동할까요?입니다.

제 생각에는 현재 모델에 대한 몇 가지 잠재적인 문제가 있습니다.

• 수십 개의 앱이 복제된 어셈블리로 수천 개의 임시 파일을 만듭니다. 여기에 엉망이 될 가능성이 있습니다. (사용자들에게 눈에 띄지 않지만 여전히 엉망)
• 압축도 없고 링커도 없습니다. 이것은 FDD 또는 이벤트 압축에 비해 작은 유틸리티 앱에 불리한 점을 만들 수 있습니다.
• 서버 배포를 더 쉽게 만드는 대신 실제로 방해할 수 있습니다. 그 이유는 토큰 교체를 통한 배포 후 구성 때문입니다. (설정 파일을 덮어쓸 임시 폴더를 찾으려면 어디로 가나요? 거기에 설정 파일을 생성하기 위해 서비스에 자체 폴더에 대한 쓰기 권한을 부여합니까? 보안은 no-no)

나는 이 모델이 모든 종류의 앱에 차선책이라고 말하려는 것이 아닙니다. 나는 그것을 성공적으로 구현했고 과거에 full.Net Framework에 직접 사용했으며 특정 앱에 적합합니다.

최적의 구현은 링커가 모든 어셈블리를 단일 파일로 병합하는 버전이라고 생각합니다.

@popcatalin81 관점이 하나인 세상은 가난한 세상입니다. 그리고 내 배포 모델이 유일한 모델이라고 생각할 만큼 오만하지 않습니다.

내가 염두에 둔 경우는 다운로드 및 두 번 클릭 시나리오입니다.
지금 당장 실행하려면 셸 스크립트의 압축을 풀고 클릭해야 합니다. 100개의 파일이 있는 디렉토리로 이동하여 올바른 파일을 찾는 것이 귀찮은 일이기 때문입니다.

임시 파일의 구성 정보. 나는 그것에 대해 매우 반대할 것이다. 구성 파일은 사용자가 볼 수 있는 다른 항목입니다._반드시_ 사용 중인 실제 파일 옆에 있어야 하며, 어딘가에 숨겨져 있지 않습니다.
사용자가 필요할 때 IsolatedStorage 파일이 얼마나 나쁜지 이미 보았습니다.

이전 버전의 RavenDB에서는 디렉토리 레이아웃을 더 단순하게 만들고 표시되는 파일 수를 줄이기 위해 많은 항목을 병합했으며, 이는 소프트웨어 사용에 심각한 영향을 미쳤습니다.

이 기능은 ILMerge를 사용합니까? 그렇지 않다면 그 이유는 무엇입니까? 함정이 있다면 스스로 교육하고 싶습니다.

나는 제안된 "팩 및 추출" 접근 방식, 특히 if가 디스크에서 파일을 추출하는 부분을 좋아하지 않습니다. 간단하지만 문제가 너무 많습니다. 디스크로 추출하지 않고 "메모리"에서 모두 작동해야 합니다.

corert 네이티브 컴파일러나 Costura.Fody 와 같은 것이어야 한다고 생각합니다.

선택적으로 바이너리 크기를 줄이려고 시도해야 합니다(사용하지 않는 참조, 죽은 IL 제거).

답장

dotnet core 3.0이 등장하기 몇 달 전에 저는 Fody.Costura를 사용하여 여기에 설명된 작업을 거의 수행하고 있었습니다. 빌드 시 패킹 및 시작 시 언패킹!

Costura는 기본적으로 "디스크에 압축을 풀지" 않습니다. 리소스에서 임베디드 어셈블리를 (메모리에서) 추출하고 바이트를 통해 로드합니다.

@SimonCropp 컨텍스트에 감사드립니다. 디스크에 압축을 풀고 스트림에서 로드하는 두 가지 옵션을 모두 탐색하고 있습니다. 순수한 IL에 대한 스트림의 로딩을 커버하는 것은 첫 번째 반복에서 가능할 수 있습니다.

@jeffschwMSFT btw 어셈블리를 매끄럽게 병합하는 기능 세트(및 선택적 트리 흔들기)는 일류 시민으로서 보고 싶은 것입니다. costura는 제가 가장 인기 있는 프로젝트 중 하나지만 지원하는 데 상당한 시간이 걸리는 프로젝트이기도 합니다. 따라서 MS가 대안(베타 버전 포함)을 제공하는 경우 알려주시면 검토하는 데 시간을 할애하고 Costura Readme 및 Nuget 설명에 "MS 대안이 있습니다"를 추가하겠습니다.

가능성은 없지만 diff 라이선스에 따라 Costura의 코드를 릴리스해야 하는 경우 알려주세요.

mono/illinker를 .NET Core 도구 체인에 통합하기 시작할 때 @SimonCropp 에게 감사드립니다. 검토 제안을 수락하겠습니다.

Costura는 기본적으로 "디스크에 압축을 풀지" 않습니다. 리소스에서 임베디드 어셈블리를 (메모리에서) 추출하고 바이트를 통해 로드합니다.

더 좋은 것은 AppDomain.AssemblyResolve 이벤트를 사용하여 온디맨드로 로드하므로 필요할 때마다 어셈블리(메모리로)만 로드하기 때문에 시작에 너무 많은 영향을 미치지 않아야 한다고 생각합니다.

여기 대화에 늦었습니다. 이미 다뤘다면 사과드립니다.

여기서 인공물이 결정적이라고 가정할 수 있습니까? 따라서 동일한 빌드는 항상 동일한 바이너리를 생성합니까? 바이트 단위. 표준과 함께 제공되는 체크섬과 함께 바이너리를 배포할 수 있다는 것도 도움이 될 것입니다.

@morganbr 여기에는 많은 읽을거리가 필요합니다. 지금까지 내린 결정을 기록할 수 있습니까?

@edblackburn 피드백을 기반으로 업데이트된 디자인을 함께 모으고 있습니다. @swaroop-sridhar는 지금 디자인을 주도하고 있습니다.

이 기능은 ILMerge를 사용합니까? 그렇지 않다면 그 이유는 무엇입니까? 함정이 있다면 스스로 교육하고 싶습니다.

@simplejackcoder ILMerge 는 많은 어셈블리의 IL을 하나로 결합하지만 그 과정에서 병합된 어셈블리의 원래 ID를 잃습니다. 따라서 원래 어셈블리 이름을 기반으로 하는 리플렉션을 사용하는 것과 같은 작업은 실패합니다.

이 노력의 목표는 어셈블리를 병합하는 것이 아니라 어셈블리 ID를 유지하면서 함께 패키지하는 것입니다. 또한 어셈블리뿐만 아니라 기본 바이너리, 구성 파일, 런타임 및 앱에 필요한 기타 종속성을 패키징해야 합니다.

IL 병합은 이에 적응할 수 있는 앱에 유용한 기능입니다. 이 문제와 다른 기능입니다.

디자인 리뷰는 https://github.com/dotnet/designs/pull/52 에 게시됩니다.
앞으로도 PR에 대한 논의를 계속하자.

단일 파일을 사용하려는 사람들에게 몇 가지 질문이 있습니다. 귀하의 답변은 선택의 폭을 좁히는 데 도움이 될 것입니다.

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)
2. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?
3. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?
4. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?
5. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?
6. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?
7. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?
8. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

1. 지금까지 dotnet/coreclr#1 사용 사례는 유틸리티인 콘솔 앱입니다. Windows 또는 Linux용으로 게시하고 --single-file 를 지정하여 하나의 실행 파일을 얻고 싶습니다. Windows의 경우 .exe 로 끝날 것으로 예상하고 Linux의 경우 실행 가능한 바이너리가 될 것입니다.
2. 보통은 아니지만 우리에게 알려지지 않은 NuGet 패키지를 통해 발생할 수 있습니다.
3. 처음에는 아니지만 향후 훌륭한 기능이 될 것입니다.
4. 네
5. 네
6. 무엇이든 작동
7. 예, 실행 파일의 결과 크기를 최적화한 경우입니다. 이상적으로는 --optimizing-level=5 를 사용하여 최적화 수준을 설정하는 플래그일 수 있습니다.
8. 네, 어느 정도

@BlitzkriegSoftware 감사합니다.
여기 에 제안된 디자인이 귀하의 사용 사례를 다룹니다. 디자인을 살펴보십시오. 피드백을 환영합니다.

단일 파일을 사용하려는 사람들에게 몇 가지 질문이 있습니다. 귀하의 답변은 선택의 폭을 좁히는 데 도움이 될 것입니다.

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)
2. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?
3. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?
4. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?
5. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?
6. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?
7. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?
8. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

1. WPF .Core 3.0 앱
2. 아마도 너겟 패키지에
3. 아니요
4. 네
5. 최대 200-500ms의 경우 예
6. 원래 게시 폴더 크기보다 2~3배 크지 않으면 중요하지 않습니다.
7. 생산을 위한 것이므로 그다지 중요하지 않습니다
8. 예, 하지만 작업이 타사 라이브러리와 관련된 경우 유용할 수 있는 그렇게 하지 않을 가능성이 있습니다.

귀하가 받은 피드백은 주로 2019년 이전에 개발을 위한 것으로 일반적으로 웹 서비스, 콘솔 애플리케이션 및 백그라운드에서 실행되는 기타 서비스입니다. 그러나 이제 .net core 3.0에서는 WPF 및 UI 앱용 솔루션이 필요합니다. .Net Framework 4.8은 .Net Standard 2.1을 지원하지 않으며 .net 프레임워크(죽은 프레임워크)에서 .net 코어로 앱을 업그레이드해야 하므로 지금까지 WPF 애플리케이션에 사용했던 ILMerge를 대체할 솔루션이 필요합니다.

자동 압축 풀림 패키지는 이러한 종류의 프로그램에 대해 이전에 다른 설명에서 설명한 것처럼 분명히 좋은 솔루션이 아닙니다.

1. 대부분 CLI 앱. 소규모 Windows 서비스와 가끔 제공되는 WPF 앱도 흥미롭습니다. 웹 항목의 경우 단일 파일 배포는 기본적으로 관련이 없는 것 같습니다. 이러한 이유로 나머지는 대부분 Windows 지향적입니다. 우리의 Linux .NET Core 관심은 웹에 있습니다.
2. 때때로. 그럴 때 거의 항상 압축 라이브러리를 위한 것입니다. 토종 재료가 포장되지 않았다면 세계의 끝이 아니었을 것입니다. 별도의 dll로 기본 종속성을 배포해야 하는 순수 관리 항목에 대한 좋은 솔루션은 여전히 ​​가치가 있습니다.
3. 아니요, 단일 파일에 관심이 있는 경우에는 그렇지 않습니다.
4. 네.
5. 200ms는 CLI를 시작하는 데 짜증이 나기 전의 대략적인 한계입니다. > 1초면 거의 확실히 .NET Framework(ILMerge + ngen)를 고수하거나 필요한 런타임이 정적으로 연결된 네이티브 바이너리로 컴파일되는 다른 언어를 볼 것입니다. 많은 경우에 병합된 ngen-ed C# 앱이 실제로 상당히 빠르게 시작되기 때문에 C#에서 구현되었습니다. 이 중 일부는 복잡성 면에서 스크립팅 언어로 구현하기에 합리적이지만, 특히 많은 모듈을 가져와야 하는 경우 상당한 시작 비용이 드는 경향이 있습니다.
6. 달려있다. Hello World의 경우 10MB 이상은 판매하기 어려울 것입니다. 또한 거대한 실행 파일은 시작 비용이 만만치 않은 경향이 있습니다. OS가 이론적으로 전체 내용을 읽지 않고 실행을 시작할 수 있다고 해도 적어도 Windows에서는 보안 목적으로 먼저 해시를 얻으려는 것이 거의 항상 있습니다. 말하자면, 임시로 이진 파일을 푸는 것은 리소스 활용 측면에서 AV(Defender 절대적으로 포함됨) 너트를 몰고 갈 것입니다.
7. 확신하는. 적절한 크기를 얻고 빠르게 실행을 시작하는 것을 의미한다면 릴리스 빌드에 1분 이상을 추가하게 되어 기쁩니다.
8. 분명히.

제안서를 읽어보면 우리가 가지고 있고 사용하지 않을 시나리오를 다루지 않습니다. 문제를 해결하는 사람이 있을 수 있지만 우리는 아닙니다.

실제로 사용 가능하거나 계속 작동할 가능성이 있는 도구 체인으로 함께 결합되지 않은 우리와 같은 시나리오에 대한 관련 사항이 많이 있는 것 같습니다. 어쩌면 이것은 나의 무지일 수도 있지만주의를 기울이려고 노력하지만 나에게 명확하지 않습니다. ILLink, Microsoft.Packaging.Tools.Trimming, CoreRT, .NET Native 및 이 문제에서 발생하는 모든 문제 사이에 단일 트리 흔들림, 빠른 시작(AoT 가능성 있음), 합리적인 크기의 바이너리를 얻을 수 있는 방법이 있어야 하는 것 같습니다. .NET Core 외부(UWP용 아님).

1. 단일 파일 배포는 https://github.com/AvaloniaUI/Avalonia(Windows , Linux, MacOS) 및 WPF(Windows) 앱에 매우 유용합니다. 예를 들어 단일 exe가 있으면 자동 업데이트가 쉬워지며 일반적으로 수백 개의 dll에 비해 단일 파일이 더 편리합니다.
2. 예(sqlite 및 skia와 같은 사전 빌드 기본 라이브러리를 참조한다는 의미에서)
3. 아니요
4. 네
5. 200ms는 아마 괜찮을 것입니다. GUI 앱의 시작 시간이 5초인 것은 좋지 않습니다.
6. 별로 상관없어
7. 별로 중요하지 않습니다. 프로덕션 시나리오에 대해서만 단일 파일을 빌드할 수 있습니다.
8. 네

팩 및 추출 방식을 사용하지 마십시오. 아카이브 도구를 사용하여 이미 이를 달성할 수 있었습니다.

팩 및 추출 방식을 사용하지 마십시오. 아카이브 도구를 사용하여 이미 이를 달성할 수 있었습니다.

더 동의할 수 없습니다. 이를 수행할 수 있는 여러 도구가 이미 있습니다.

@Safirion , @mattpwhite , @x2bool , @thegreatco 피드백에 감사드립니다.
이로부터 다양한 사용 시나리오(콘솔 앱, WPF, GUI 앱 등)를 볼 수 있지만 전반적인 요구 사항은 비슷해 보입니다.

• 빌드 시간보다 실행/시작 시간에 중점을 둡니다.
• 추가 릴리스/패치를 위해 앱을 재구축하는 기능
• 번들에서 직접 실행할 수 있는 기능(특히 순수 관리 구성 요소의 경우).

나는 이것이 우리가 디자인 문서 에서 해결하려고 시도한 요구 사항이라고 생각합니다.

팩 및 추출 방식을 사용하지 마십시오.

예, 이 준비 문서 에서 설명한 대로 목표는 파일 추출에 대한 의존도를 점진적으로 최소화하는 것입니다.

제안서를 읽어보면 우리가 가지고 있고 사용하지 않을 시나리오를 다루지 않습니다.

@mattpwhite , 이 솔루션이 다음을 기반으로 작동하지 않는다고 생각하는지 명확히 하고 싶었습니다.

• 이 작업 항목의 앞부분에서 제안된 자체 추출 기반 접근 방식, 또는
• 이 문서 에 언급된 디자인
  나는 나중 문서가 당신이 자세히 설명한 시나리오를 다루려고 한다고 생각합니다. 감사 해요.

실제로 사용 가능하거나 계속 작동할 가능성이 있는 도구 체인으로 함께 결합되지 않은 우리와 같은 시나리오에 대한 관련 사항이 많이 있는 것 같습니다.

@mattpwhite , ILLink(트리 쉐이킹), crossgen(실행 준비가 된 네이티브 코드 생성) 및 단일 파일 번들링 측면을 .net core 3용으로 간소화된 방식으로 msbuild/dotnet CLI에 통합하기 위한 작업이 진행 중입니다. 이 도구를 사용하면 쉽게 수행할 수 있습니다(예: 특정 msbuild 속성 설정).

이러한 모든 도구에는 장단점이 있습니다. 예를 들어, crossgen은 미리 네이티브 코드를 생성하여 시작을 돕지만 바이너리의 크기를 증가시키는 경향이 있습니다. 단일 파일 옵션을 사용하면 앱을 단일 파일에 게시할 수 있지만 기본 바이너리가 디스크 등에 유출되기 때문에 시작 속도가 느려질 수 있습니다.

@swaroop-sridhar, 시간을 내어 응답해 주셔서 감사합니다.

이 솔루션이 다음 기반에 적합하지 않다고 생각하는지 확인하고 싶었습니다.

자체 포함된 모든 것에 대한 추출이 여전히 그림에 있는 것처럼 보였고 crossgen의 상태(또는 출시 시 JIT 시간에 줄일 수 있는 다른 것)가 명확하지 않았습니다. 현재 디자인이 링크하는 스테이징 문서를 읽는 것은 이것을 우리에게 더 흥미롭게 만드는 것처럼 보였습니다. 이를 감안할 때 우리는 앞으로 한동안 이러한 틈새 시장을 위해 .NET Framework를 계속 사용하게 될 것이라고 생각했습니다. 제가 잘못 이해했을 수도 있습니다.

이러한 모든 도구에는 장단점이 있습니다. 예를 들어, crossgen은 미리 네이티브 코드를 생성하여 시작을 돕지만 바이너리의 크기를 증가시키는 경향이 있습니다.

예, 이들 중 일부는 양날의 검이라는 것을 이해했습니다. JIT가 전통적으로 작동하는 방식으로 ngen은 항상 CLI/GUI 앱의 승리였습니다. 계층화된 컴파일과 런타임 자체를 로드하는 것이 동일한 상자에서 실행되는 다른 많은 .NET Framework 프로세스에 의해 반드시 분할 상환되지 않는다는 사실의 일부 조합으로 인해 Core에서 명확하지 않을 수 있습니다.

@swaroop-sridhar 현재 승인된 제안에 대해 제가 가장 우려하는 것은 이 단계입니다.

나머지 216개 파일은 시작 시 디스크에 추출됩니다.

"Hello World"를 실행하는 데 216개의 파일이 필요하다는 사실을 제외하고, 디스크의 일부 위치에 압축을 풀면 간단한 명령줄 응용 프로그램을 제거하기가 어렵습니다. 사람들이 설치 프로그램을 통해 제공되지 않은 도구를 삭제할 때 완전히 제거하기 위해 다른 파일을 찾을 필요가 없을 것으로 예상합니다.

IMHO, 우리는 golang과 유사한 게시 경험을 목표로 해야 합니다. golang 경험과 완전히 일치하려면 crossgen 가 있어야 하지만(JIT 및 계층화된 컴파일에서 지기 때문에 1:1 일치는 _좋은_ 것이 아니라고 주장할 수 있음), 그것 없이는 좋은 부분을 얻을 수 있습니다. 나는 비슷한 경험을 하기 위해 수년 동안 많은 도구를 사용해 왔으며 가장 효과적인 것은 어셈블리 로더에 후크가 있는 임베디드 리소스였습니다(ILMerge는 까다롭고 Costura.Fody는 아직 존재하지 않았습니다). 제안서에 설명된 내용은 해당 기능을 완전히 복제하지도 않습니다. .NET Core는 미래가 매우 강력하지만 명령줄 도구 개발에 대한 사용은 약 100개의 종속성을 러그하거나 손으로 휘두르는 부트스트랩 코드를 사용하여 디스크의 어딘가에 뱉어내야 하는 한 제한적입니다.

내 dotnet/coreclr#1 사용 사례는 명령줄 유틸리티, 하나의 파일이며 추출하지 않는 것이 선호됩니다. 그러나 나는 올인원 대 올인원 자동 압축 풀기에 대한 명령 스위치의 일부로 선택을 제공한다는 점을 지적하고 싶습니다. 자동 압축 풀림의 경우 압축을 푼 파일을 정리하는 undo 를 포함해야 합니다. 첫 번째 경우에 유틸리티를 제거한다는 것은 하나의 파일을 삭제하여 일반 유틸리티 폴더에 상주하기에 적합하게 만드는 것을 의미하지만, 두 번째 경우와 마찬가지로 설치에는 자체 폴더가 있어야 정리가 더 쉬워지고 제거가 공유 파일을 제거하는 시나리오. 그냥 몇 가지 생각. 내가 말했듯이 하나의 파일 유틸리티(설치 필요 없음)는 프로젝트용 유틸리티(도구 제작자로서)를 자주 만들기 때문에 나의 주요 사용 사례입니다. 그러나 두 시나리오 모두에 대한 사용 사례를 볼 수 있습니다. 그러나 그들은 다릅니다 .

단일 파일을 사용하려는 사람들에게 몇 가지 질문이 있습니다. 귀하의 답변은 선택의 폭을 좁히는 데 도움이 될 것입니다.

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)
2. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?
3. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?
4. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?
5. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?
6. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?
7. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?
8. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

1. CLI(Windows, Linux, MacOS), WPF 및 WinForms.
2. 때때로.
3. 예, 여러 번 그리고 플러그인이 메인 애플리케이션의 공유 라이브러리를 재사용할 수 있는 시나리오가 해결되어야 한다고 생각합니다!
4. 네.
5. 200-500ms는 괜찮습니다!
6. 많은 종속성이 없는 간단한 CLI 애플리케이션의 경우 10MB면 충분합니다(압축)!
7. 네 확실히! 빌드 시간(특히 릴리스 빌드의 경우)은 중요하지 않습니다! 압축 크기 및/또는 단일 파일 게시로의 전환은 선택 사항이어야 합니다!
8. 예 예: CoreRT!

IMHO, 우리는 golang과 유사한 게시 경험을 목표로 해야 합니다.

@thegreatco : 예, 네이티브 코드로의 전체 컴파일은 단일 파일 앱을 빌드하는 데 좋은 옵션입니다. GO와 같은 언어는 AOT(Ahead-of-Time) 컴파일을 기본 모델로 사용하여 빌드됩니다. 여기에는 JIT 컴파일을 통해 달성되는 동적 언어 기능에 대한 특정 제한이 있습니다.

CoreRT 는 AOT 컴파일 앱을 위한 .Net Core 솔루션입니다. 그러나 CoreRT를 사용할 수 있을 때까지 이 문제에서 다른 수단을 통해 단일 파일 앱을 구현하려고 합니다.

"Hello World"를 실행하려면 216개의 파일이 필요하다는 사실 외에도

HelloWorld에 필요한 파일 수를 줄이는 데 사용할 수 있는 몇 가지 옵션이 있습니다."

• 3-4개의 파일만 필요한 프레임워크 종속 앱 빌드
• 독립형 앱을 빌드해야 하는 경우 ILLinker 를 사용하여 파일 종속성 수를 줄이십시오.

특정 위치의 디스크에 압축을 풀면 간단한 명령줄 응용 프로그램을 제거하기가 어렵습니다.

• 단일 파일 기능의 개발이 다음 단계 로 이동함에 따라 디스크에 유출되는 파일 수가 줄어들고 대부분의 앱에서 이상적으로는 0이 됩니다. 그러나 초기 단계에서는 여러 파일(네이티브 코드가 포함된 파일)이 유출되어야 합니다.
• 디스크에 유출된 파일의 위치는 항상 결정적이며 구성 가능합니다. 따라서 유출된 파일은 간단한 스크립트로 정리할 수 있습니다. 그러나 이것이 이상적이지 않다는 데 동의합니다.

@mattpwhite에 대한 설명 감사합니다.

예, 기능 개발의 나중 단계까지 독립형 앱은 디스크로 추출된 파일을 볼 수 있습니다. 위의 설명 에서 작성한 기술 중 일부를 사용하여 앱의 상황을 개선할 수 있습니다.

@BlitzkriegSoftware에 응답해 주셔서 감사합니다.

그러나 나는 올인원 대 올인원 자체 추출에 대한 명령 스위치의 일부로 선택을 제공한다는 점을 지적하고 싶습니다.

단일 파일로 게시된 앱에 추출이 필요한지 여부는 앱 콘텐츠에 따라 다릅니다(예: 기본 파일이 포함되어 있는지 여부). 번들러 디자인은 모든 파일을 추출할지 여부를 결정하는 몇 가지 구성 을 제공합니다. 앱이 런타임에 파일에 대한 추출을 사용하지 않아야 한다는 속성을 추가할 수 있습니다.

<propertygroup>
    <SingleFileExtract> Never | Always | AsNeeded </SingleFileExtract>
</propertygroup>

여기에서 이해는 다음과 같습니다. SingleFileExtract=Never를 컴파일할 때 앱에 추출(네이티브 바이너리)을 통해서만 처리할 수 있는 파일이 포함되어 있으면 단일 파일에 게시할 수 없습니다.

자동 압축 풀림의 경우 압축을 푼 파일을 정리하는 실행 취소가 포함되어야 합니다.

합리적으로 들리네요. 추출의 정확한 위치(있는 경우)는 결정적이며 구성 가능합니다. 따라서 앱과 추출된 모든 종속성을 제거하는 스크립트를 가질 수 있습니다.

@DoCode에 응답해 주셔서 감사합니다. 귀하의 시나리오는 플러그인을 사용한다는 점에서 흥미롭습니다.
플러그인 자체에 몇 가지 종속성이 있는 경우(기본 앱과 공유되지 않음) 플러그인을 단일 파일로도 게시해야 합니까(포함된 ​​종속성 포함)? 감사 해요.

예 @swaroop-sridhar, 그것이 목표입니다. 이 경우 플러그인에 종속성이 포함되어야 한다고 생각합니다. 공유 종속성만 단일 파일 기본 앱 외부에 있어야 합니다.

오늘 @madskristensen 은 Visual Studio 및 인기 있는 Newtonsoft.Json NuGet 패키지에 대한 설명 을 공유했습니다.

우리는 때때로 비슷한 상황에서 같은 상황!

@DoCode 감사합니다. 단일 파일 앱이 구현되고 안정되면 단일 파일 플러그인의 주소 기능을 계획합니다. 디자인 문서는 여기에서 플러그인에 대해 이야기합니다.

@swaroop-sridhar 이 기능에 대한 지속적인 참여에 감사드립니다. 대단히 감사합니다. 실행 취소 명령이 있으면 특히 원래 단계에서 유용합니다.

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)
   -- 명령줄 유틸리티(콘솔 앱)
2. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?
   -- 아니요
3. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?
   -- 보통 아님
4. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?
   -- 네
5. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?
   -- < 1초가 선호됩니다.
6. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?
   -- 크기는 중요하지 않습니다.
7. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?
   -- 30 초
8. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?
   -- 스크립팅하거나 구성할 수 있는지 여부

1 - 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)

• 계략
• 명령줄 도구

2 - 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?

네

3 - 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?

예, 하지만 이미 알려진 기호를 사용하면 느리기 때문에 반사에 의존하지 않습니다.

4 - 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포할 의향이 있습니까?

네

5 - 앱이 200-500ms 더 느리게 시작되는 경우 사용하시겠습니까? 5초 정도?

아니, 이미 조금 느리다

6 - 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?

프로젝트에 따라 다르지만 간단한 명령줄 도구의 경우 한 자리 mbs보다 클 것으로 기대하지 않습니다.

7 - 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?

개발/반복 시간에 영향을 미치지 않는 한 릴리스 빌드 시간이 길어도 괜찮습니다.
그러나 .net 핵심 앱은 이미 기존 .net 프레임워크 앱보다 더 오래 빌드된다는 점을 기억하세요.

매년 느린 소프트웨어의 경향은 용인되지 않습니다. 우리는 더 나은 하드웨어를 가지고 있습니다. 느려질 이유가 없습니다.

8 - 앱 크기를 절반으로 줄이는 추가 작업을 수행하시겠습니까?

네!

언젠가 CoreRT를 사용한 AOT 컴파일이 작동하여 golang 및 rust 및 기타 AOT 컴파일 lang과 같은 응용 프로그램을 기본적으로 컴파일할 수 있기를 진심으로 바랍니다. Unity3D가 IL2CPP로 수행하는 방식과 유사합니다.

@morganbr 다음은 나와 함께 일하는 사람들의 의견입니다. 저는 많은 언어를 사용하지만 주로 C#, Go, Python을 사용합니다.

어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)

ASP.NET Core 및 콘솔 프로그램(대부분 Linux)은 ML.NET이 우리의 요구 사항을 충족하는지 여부에 따라 잠재적으로 일부 Windows 워크로드입니다.

앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?

현재로서는 가능성이 낮습니다.

앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?

때에 따라 다르지. 현재 우리는 모든 종속성을 패키지로 가져올 수 있지만 외부 DLL을 사용하는 것을 의미할 수 있는 상용 라이브러리에 비용을 지불하는 상황을 볼 수 있습니다.

보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?

전적으로. 이것은 우리의 최우선 과제입니다.

앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?

나는 10초 미만이면 무엇이든 괜찮다고 말하고 싶다. 시작 시간은 일반적으로 멱등성이 있고 예측 가능한 한 중요하지 않습니다. 즉, 라이브러리가 동일한 순서로 로드되고 변수가 동일한 순서로 초기화되는 등입니다.

앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?

주로 배포 목적으로 작을수록 좋습니다. 배포는 사용자가 다운로드한 바이너리, 바이너리가 포함된 컨테이너 이미지 등이 될 수 있습니다.

크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까?

물론, C/C++ 및 Java보다 빠르면 만족해야 합니다.

가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?

30-90초가 이상적이지만 3분 미만이면 적당합니다. 중소 규모 프로젝트(1k-500k LOC)의 경우 3분 이상은 다소 많을 것입니다. 매우 큰 프로젝트(1M LOC)의 경우 5분이 허용될 수 있습니다.

앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

때에 따라 다르지. 추가 작업이 템플릿화할 수 있는 상용구 코드를 추가하는 것이라면 괜찮을 것입니다. 불명확하거나 간단한 작업이 아닌 경우 잠재적으로 그렇지 않습니다.

@mxplusb , @dark2201 , @RUSshy , @BlitzkriegSoftware 응답에 감사드립니다

현재 설계 는 순수한 AOT 컴파일이 없는 경우 가능한 한 최상의 범위로 시나리오를 해결한다고 생각합니다. 디자인에 대한 문제가 있으면 언제든지 제기하십시오.

더 낮은 시작 시간 및 컴파일 시간과 관련하여:
프레임워크 종속 앱은 시작 시간이 상당히 짧습니다(적어도 기능 시작 초기 단계에서는). 컴파일 시간도 더 짧습니다(더 적은 수의 파일을 포함해야 하기 때문에).
기능 개발의 첫 번째 반복이 완료되는 즉시 시작 시간, 컴파일 처리량 및 파일 크기 측정에 대해 알려 드리겠습니다.

@swaroop-sridhar 그 일정은 어떻게 되나요?

@ayende 첫 번째 반복은 활발히 개발 중이며 몇 주 안에 결과를 얻을 수 있을 것으로 생각합니다.

@swaroop-sridhar

현재 설계 는 순수한 AOT 컴파일이 없는 경우 가능한 한 최상의 범위로 시나리오를 해결한다고 생각합니다. 디자인에 대한 문제가 있으면 언제든지 제기하십시오.

실행: HelloWorld.exe

번들 앱 및 구성 파일은 번들에서 직접 처리됩니다.
나머지 216개 파일은 시작 시 디스크에 추출됩니다.

읽기 전용 fs에서 실행해야 하는 경우 IoT에 일반적이거나 exe가 ro 컨테이너 내에서 실행 중인 경우에는 어떻게 됩니까? exe에서도 직접 실행하는 옵션이 없는 이유는 무엇입니까?

@etherealjoy 이 섹션 에 표시된 예는 이 기능을 개발하는 2단계 에서 자체 포함된 HelloWorld에 대한 예상 출력입니다( 이 섹션 에서 언급됨). 이 단계에서 EXE에서 직접 실행할 수 있는 유일한 앱은 프레임워크 종속 순수 관리 앱입니다.

4 단계 또는 5단계 에 있는 경우 위의 독립형 앱은 번들에서 직접 실행할 수 있습니다.

어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)

기본적으로 위의 모든 것. 콘솔 유틸리티, WPF, asp.net, 게임

앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?

네. Sqlite가 좋은 예입니다.

앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?

아마 아니오.

보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?

네.

앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?

net.core는 이미 너무 느립니다. 그러나 몇 초 증가는 허용됩니다. 5초 -- 절대 아닙니다.

앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?

요즘은 상관없어

크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?

최대 5분의 느낌이 허용됩니다. UWP용 15-20분 릴리스 빌드는 모두를 미치게 만듭니다.

앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

확신하는.

@mjr27 감사합니다

이제 1단계 구현이 완료 되었으며 3.0.100-preview5-011568부터 사용할 수 있습니다.

여기 에 설명된 대로 PublishSingleFile 속성을 true 로 설정하여 앱을 단일 파일에 게시할 수 있습니다.

이 버전에서는 여기 에 설명된 대로 모든 포함된 파일이 처음 실행 시 디스크로 추출되고 후속 실행에서 재사용됩니다.

컴파일 처리량
파일이 게시 디렉토리에 개별 파일로 기록되는지 또는 단일 파일로 기록되는지 여부에 따라 시간상 큰 차이가 없습니다.

파일 크기 및 시작
다음 표는 단일 파일로 빌드된 몇 가지 앱의 성능을 보여줍니다.

• 콘솔: Hello World 앱입니다. 보고된 시간은 시계 틱을 통해 측정된 앱 실행 시간입니다.
• WPF 앱: msix-catalog 앱. 보고된 시간은 스톱워치를 통해 측정된 초기 화면으로 시작하는 시간입니다.
• Fw: 프레임워크 종속 빌드
• 자체: 자체 포함된 빌드입니다.
  모든 실행은 외부 요인의 영향을 최소화하기 위해 안티바이러스 검사가 꺼져 있을 때 시간이 정해져 있습니다.

측정 | 콘솔 펌웨어 | 콘솔 셀프 | WPF FW | WPF 자체
-- | -- | -- | -- | --
파일 크기(MB) | 0.32 | 66.5 | 20.69 | 118.9
일반 실행(초) | 0.123 | 0.127 | 3.32 | 3.24
단일 exe 첫 실행(초) | 0.127 | 0.565 | 3.67 | 4.14
단일 exe 후속 실행(초) | 0.124 | 0.128 | 3.30 | 3.29

구현이 후속 개발 단계 로 진행됨에 따라 숫자를 계속 업데이트하겠습니다.

좋은 소식입니다. 감사합니다

3.0 RTM에서 스테이징 문서에 언급된 모든 단계가 완료됩니까? 아니면 구현될 때까지 3.0 이후를 기다려야 합니까?

여기 에서 언급했듯이 .net core 3.0은 프레임워크 종속 순수 msil 앱이 번들에서 직접 실행할 수 있도록 2단계 를 구현해야 합니다. 나머지 단계는 추가 릴리스를 위해 고려됩니다.

여기 에서 언급했듯이 .net core 3.0은 프레임워크 종속 순수 msil 앱이 번들에서 직접 실행할 수 있도록 2단계 를 구현해야 합니다. 나머지 단계는 추가 릴리스를 위해 고려됩니다.

:( RTM에 도달할 수 있기를 바랐습니다.

@cup dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 로 할 수 있다고 생각했습니다. 방금 바닐라 콘솔 앱을 만들고 해당 명령을 실행하여 테스트했습니다. 성공적으로 작동했습니다.

dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 /p:IncludeSymbolsInSingleFile=true 를 사용하여 .pdb 파일을 번들링하면 더 멀리 갈 수 있습니다.

자세한 내용을 알려주신 @seesharprun 에게 감사드립니다. 예 @cup , 명령줄 단일 파일 게시에 권장되는 방법은 명령줄에서 PublishSingleFile 속성을 설정하는 것입니다.

@etherealjoy coreclr 런타임 저장소는 거의 한 달 안에 기능 작업에 대해 대부분 잠겨 있습니다. 모든 단계에 시간이 충분하지 않다고 생각합니다. 후속 단계는 다음 릴리스에서 제공되기를 바랍니다.

오늘 이 작업을 수행했지만 추출 기본 디렉토리를 변경해도 작동하지 않는 것 같습니다. 이 섹션 에 따르면 . 응용 프로그램이 추출되는 위치를 변경하기 위해 ExtractBaseDir이라는 응용 프로그램 스위치를 runtimeconfig에 추가할 수 있어야 합니다.

다음과 같은 runtimeconfig.template.json이 있습니다.

{
    "configProperties" : {
        "ExtractBaseDir": "C:\\"
    },
    "ExtractBaseDir": "C:\\"   
}

생성된 app.runtimeconfig.json은 다음과 같습니다.

{
  "runtimeOptions": {
    "configProperties": {
      "ExtractBaseDir": "C:\\"
    },
    "ExtractBaseDir": "C:\\"
  }
}

생성된 exe를 통해 실행할 때 여전히 tmp 폴더에 압축되어 있습니다.

이 기능이 Preview5에서 준비되지 않았다고 가정하지만 "ExtractBaseDir"이 runtimeconfig.json에 있어야 하는 위치가 명확하지 않고 예제가 없기 때문에 확인하고 싶었습니다.

@igloo15 올려 주셔서 감사합니다.

현재 미리 보기에서는 DOTNET_BUNDLE_EXTRACT_BASE_DIR 환경 변수만 활성화됩니다. 이는 현재 구현 단계에서 runtimeconfig.json 를 포함한 모든 파일이 처리되기 전에 디스크로 추출되기 때문입니다.

다음 미리 보기에서 ExtractBaseDir 에 대한 지원을 추가하는 작업을 하고 있습니다.

ASP.NET Core 프로젝트에서 이 작업을 수행하는 방법에 대한 지침이 있습니까? 권장되는 접근 방식은 리플렉션을 사용하여 내 시스템 유형이 로드되는 위치를 찾고 해당 디렉토리를 기준으로 IHostingEnvironment ContentRootPath 및 WebRootPath를 설정하는 것입니까?

@keithwill AppContext.BaseDirectory 를 사용하여 app.dll 및 기타 모든 파일이 디스크로 추출되는 위치를 얻을 수 있습니다. 따라서 이것을 ContentRootPath 로 사용할 수 있습니다.

@igloo15 : 이 옵션을 사용하는 시나리오가 어떤 것인지 공유해 주실 수 있는지 궁금합니다.

• 디버깅 또는 프로덕션 배포 시나리오에 사용하려고 합니까?
• 이 경우 환경 변수로 충분합니까, 아니면 runtimeconfig.json 설정이 필요합니까?

이 설정에 대한 특정 사용 사례가 있는지 다른 개발자의 의견도 듣고 싶습니다.

@swaroop-sridhar

나는 다소 이상한 상황이 있습니다. 내 소프트웨어가 네트워크 공유에 저장된 다음 네트워크 공유가 임의의 Windows VM에 연결되고 네트워크 공유에서 직접 실행됩니다. 네트워크 공유에서 소프트웨어를 실행하기 위해 회전된 Windows VM은 아무 것도 수정하거나 변경할 수 없습니다. 로그, 구성 파일 등은 모두 네트워크 공유에 생성되어야 합니다.

이상하게도 이 설정을 사용하면 전체 시스템이 폴더에 여러 소프트웨어를 배치한 다음 다른 구성/버전에 대해 해당 폴더 구조를 복제할 수 있습니다. 그런 다음 특정 버전에서 관리 소프트웨어를 실행해야 하는 경우 VM을 스핀업하고 VM의 드라이브를 특정 버전의 네트워크 공유에 매핑하고 소프트웨어를 실행합니다.

1.) 프로덕션 배포 시나리오입니다.
2.) 소프트웨어를 실행하는 컴퓨터가 지속적으로 다르고 파괴/재제작되기 때문에 환경 변수가 어려울 수 있습니다.

@cup 저는 이 주제가 디자인 문서 구현에 관한 것이라는 데 동의하지 않으며 디자인 문서에서는 구체적으로 ExtractBaseDir 가 이 기능에 대해 작동해야 한다고 말합니다.

이 문제가 이 설계 문서를 구현하는 것과 관련이 없다면 이 문제는 무엇에 관한 것입니까?

@igloo15에 대한 설명 감사합니다.

AppHost 코드 초기에 구성 파일을 구문 분석하는 데 비용이 들기 때문에 구성 옵션에 대해 질문합니다. 현재 AppHost는 json 파일을 구문 분석하기 위한 코드와 연결되지 않습니다(대신 hostfxr/hostpolicy에서 사용됨). 현재 이 기능을 추가하면 AppHost가 조금 더 커지고 복잡해집니다. 그러나 구현이 추가 단계 (모든 호스팅 및 런타임 코드가 함께 연결됨)로 진행되면 더 이상 문제가 되지 않습니다.

@igloo15 디자인 문서도 중요한 부분이지만 이 문제의 핵심은 기능 자체입니다. ExtractBaseDir 는 선택적 매개변수이며 선택적 매개변수에 얽매이기보다는 핵심 기능이 "현재" 릴리스로 전달되는 것을 보고 싶습니다.

@cup , 이 스레드에서 관심 있는 개발자들의 관심을 받았기 때문에 여기에 질문했습니다.
질문이 주제에서 벗어났다고 생각하지 않지만 이 스레드의 길이에 대한 귀하의 우려를 이해합니다. 다음에는 링크된 문제를 만들겠습니다. 감사 해요.

@cup @swaroop-sridhar

내가 먼저 말하고 싶은 몇 가지는 이 기능이 스테이지 문서 의 스테이지 1에서만 중요하다는 것입니다. 다른 모든 단계 2 - 5는 압축을 풀지 않고 번들 내부에서 dll을 실행하는 것입니다. 따라서 추출 기본 디렉토리의 위치를 ​​결정하는 설정은 2-5단계에서 실제로 유용하지 않습니다. NetCore 3.0이 1단계를 개발할 계획이므로 이 기능이 유용할 수 있는 유일한 시기이기 때문에 이 기능이 있을 것으로 예상합니다.

두 번째는 이 방법을 dotnet-wrap과 같은 다른 방법과 어떻게 구별하는지입니다. 나에게 이 방법의 주요 이점은 코드가 컴파일될 때와 더 가까운 빌드 체인에 이 프로세스를 구축한다는 것입니다. 또한 이것은 .NET에 맞춰진 기능이므로 구성, 빌드 프로세스 등과 같은 .NET Core 애플리케이션의 뉘앙스를 이해합니다. 따라서 이 도구를 네트 코어에 특별히 맞춰져 있지 않습니다. dotnet-wrap이 할 수 없는 추출 위치 구성과 같은 기능입니다.

구현 방법에 관해서는 확실하지 않지만 런타임 시 구성에서 ExtractBaseDir을 읽는 것보다 빌드 시 번들 exe에 이를 새길 수 없다고 생각합니다. 나는 이 번들 프로세스를 작동시키는 코드를 보지 못했지만 내 생각에는 그 안에 모든 dll 등이 포함된 기본 exe를 생성/구축하는 것입니다. exe를 생성/빌드하는 동안 번들된 앱 runtimeconfig 파일을 읽고 ExtractBaseDir을 가져와 기본 번들 exe의 속성으로 설정할 수 없었습니까?

그런 다음 런타임에 포함된 runtimeconfig를 읽지 않고 대신 내부적으로 속성을 활용하여 추출 위치를 결정합니다. 잠재적으로 훨씬 빨라야 합니다.

@igloo15 : 번들의 내용을 디스크로 추출하는 것은 2단계 이후의 특정 앱에 유용할 수 있습니다.
예를 들어 앱의 번들에 사용자 지정 기본 바이너리가 있는 경우 5단계까지 추출해야 합니다. 앱은 런타임 시 파일로 추출할 알 수 없는 유형의 콘텐츠 파일을 번들로 만들 수 있습니다.

추가 개발 단계로 이동함에 따라 이 설정의 유용성이 감소한다는 데 동의합니다. 그러나 옵션을 추가하면 호환성을 위해 모든 후속 버전에서 이 옵션을 유지해야 할 것입니다. 따라서 지금은 신중한 검토가 필요합니다.

나는 runtimeconfig 옵션보다 추출 위치를 빌드 타임 설정(예: msbuild-property)으로 만드는 것이 더 쉽고 효율적인 wrt 구현에 동의합니다. 감사 해요.

안녕하세요, 이 주제에 대해 몇 가지 질문이 있습니다.

.NET Framework 4.7.2(예:) 응용 프로그램을 단일 실행 파일로 패키징하기 위해 단일 파일 배포 기능을 사용하고 싶습니다. 이것이 이 기능의 의도입니까 아니면 .NET Core 애플리케이션만 지원하기 위한 것입니까?

두 번째 질문은 포장이 어떻게 이루어지는지에 관한 것입니다. 실행 파일이 생성되면 대상 프레임워크 런타임이 실행 파일에 번들로 포함됩니까? 아니면 애플리케이션을 실행할 대상 머신에 사전 설치해야 합니까?

@gaviriar .NET Framework 응용 프로그램을 지원하지 않는다고 생각합니다. 그리고 예, .NET Core 런타임을 실행 파일로 묶을 수 있습니다("자체 포함" 게시라고 함).

@tomrus88 답변 감사합니다. .NET Framework 응용 프로그램과 관련하여 참으로 부끄러운 일입니다. .NET Framework 런타임을 실행 파일로 번들링하는 데 사용할 수 있는 권장하는 방법이 있습니까?

문서의 관련 작업 섹션에서 도구 목록을 봅니다. 위에서 제안한 사용 사례에 특히 권장할 수 있는 것이 있습니까?

@gaviriar .NET Framework는 Windows OS의 일부입니다. 실행 파일로 번들링하는 지원되는 방법이 없습니다.

@gaviriar 런타임을 번들로 제공해야 하는 것은 .NET Core로 전환해야 하는 주요 이유 중 하나입니다.

@jnm2 및 @jkotas 는 .NET 세계에 대한 설명에 감사드립니다. .NET Core로 전환하고 싶습니다. 그러나 .NET Framework를 대상으로 하는 레거시 라이브러리와 상호 작용해야 하는 경우가 있습니다. 이러한 경우 이 라이브러리와 상호 작용해야 하는 경우 내 앱을 .NET Core로 전환할 수 없다는 것을 이해합니다. 또는 내 앱이 .NET Core이지만 여전히 레거시 .NET Framework 라이브러리와 상호 작용할 수 있는 다른 접근 방식이 있습니까?

라이브러리에 따라 다릅니다. .NET Framework를 대상으로 하는 많은 라이브러리가 .NET Core에서도 잘 작동합니다. .NET Core에서 라이브러리를 사용해 보셨습니까? 작동하지 않는 것을 확인한 경우 해결 방법을 찾을 때까지 전환할 수 없습니다.

나는 실제로 그것을 시도했지만 우리가 창에 특정한 라이브러리에 대해 이야기하고 있기 때문에 이것은 작동하지 않습니다. .NET Framework 대상을 고수하고 .NET Core의 재미를 놓치는 것 외에 다른 옵션이 없는 것 같습니다./

@gaviriar 이것은 주제가 아니지만 Microsoft.Windows.Compatibility 를 설명하는 정확한 목적을 위해 .NET Core용 Windows API를 제공하는 Windows 호환성 NuGet 패키지를 사용해 보셨습니까?

@gaviriar : 몇 가지 추가 설명:

실행 파일이 생성되면 대상 프레임워크 런타임이 실행 파일에 번들로 포함됩니까? 아니면 애플리케이션을 실행할 대상 머신에 사전 설치해야 합니까?

이것은 빌드에 따라 다릅니다. 프레임워크 종속(런타임이 대상에 설치됨) 및 자체 포함(런타임이 앱과 함께 패키지됨) 앱은 모두 단일 파일로 게시할 수 있지만 .net core 3.0 앱만 가능합니다.

문서의 관련 작업 섹션에서 도구 목록을 봅니다. 위에서 제안한 사용 사례에 특히 권장할 수 있는 것이 있습니까?

.net 프레임워크의 경우 내가 제안할 수 있는 최상의 솔루션은 앱이 자체적으로 파일 추출을 처리하는 것입니다. 예: 종속성을 앱 바이너리에 관리 리소스로 포함시킨 다음 시작 시 리소스를 명시적으로 추출합니다. 번들링 및 추출을 위해 번들 라이브러리 를 사용할 수도 있지만(라이브러리가 netstandard로 구축되었기 때문에) 관리 리소스를 사용하는 것이 더 나은 솔루션입니다.

@igloo15 및 @swaroop-sridhar 주제가 아닌 이러한 의견에 감사드립니다. 언젠가 다른 사람이 이 토론을 읽을 때 유용하다고 생각하기를 바랍니다.

나는 당신이 나와 공유한 옵션을 평가하고 내 사용 사례에 가장 적합한 접근 방식이 무엇인지 알려줄 것입니다.

감사 해요!

빠른 업데이트!

이 간단한 Hello World 응용 프로그램을 테스트했습니다. 단일 파일 실행 파일을 성공적으로 빌드할 수 있습니다. 그러나 프로젝트 구성에서 볼 수 있듯이 자체 포함을 의미합니다. 그러나 .NET 코어 런타임이 설치되지 않은 새 Windows 7 설치에서 이 실행 파일을 실행하려고 하면 다음 오류가 표시됩니다.

Failed to load the DLL from [C:\Users\vagrant\AppData\Local\Temp\.net\HelloWorld
\muasjfkf.kyn\hostfxr.dll], HRESULT: 0x80070057
The library hostfxr.dll was found, but loading it from C:\Users\vagrant\AppData\
Local\Temp\.net\HelloWorld\muasjfkf.kyn\hostfxr.dll failed
  - Installing .NET Core prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=798306

내가 볼 수 있는 것은 앱을 dotnet publish /p:PublishSingleFile=true 또는 /p:PublishSingleFile=false 로 게시하는 빌드가 실행 파일의 크기를 변경하지 않는다는 것입니다. 이것은 예상된 동작입니까?

번식 단계

1. 프로젝트를 게시하여 HelloWorld.exe 생성

2. 실행 파일을 .NET Core 런타임이 설치되지 않은 Windows 7 설치에 복사합니다.

3. HelloWorld.exe 실행

@gaviriar 게시한 예제를 시도했는데 잘 작동했습니다.
즉, 정상적으로 실행되는 HelloWorld용으로 자체 포함된 단일 exe를 빌드했습니다.

내가 볼 수 있는 것은 dotnet publish /p:PublishSingleFile=true 또는 /p:PublishSingleFile=false로 앱 게시를 빌드해도 실행 파일의 크기가 변경되지 않는다는 것입니다. 이것은 예상된 동작입니까?

이것은 확실히 예상되지 않습니다. 단일 파일 앱은 약 70MB여야 합니다(gitlab 페이지에 표시된 디버그 빌드의 경우). 그렇지 않으면 위에서 언급한 대로 정확히 실패할 것으로 예상되는 일반 앱 호스트입니다. 깨끗한 디렉토리에서 게시하고 있습니까?

프로젝트 파일에 대한 또 다른 참고 사항 -- IncludeSymbolsInSingleFile IncludeSymbolsInFile 로 잘못 작성된 속성 중 하나가 있습니다. 그러나 이것은 귀하가 보고한 문제와 관련이 없습니다.

@gaviriar 대상 런타임 식별자는 무엇입니까? 올바르게 설정하지 않으면 올바른 hostfxr.dll을 번들로 제공하지 않습니다. hostfxr.dll에는 Windows 7 시스템에 없는 특정 vc++ 재배포 가능 패키지가 필요할 수 있습니다. 주어진 경로에 dll이 있는지 확인하고 종속성 워커 도구에서 로드하려고 하면 의존하는 dll이 있는지 확인할 수 있습니다.

IL 병합: ILMerge와 같은 도구는 여러 어셈블리의 IL을 하나로 결합하지만 프로세스에서 어셈블리 ID를 잃습니다. 이것은 단일 파일 기능의 목표가 아닙니다.

어셈블리 정체성을 잃다

이것은 문제가 아닙니다.
단일 exe 자체 포함 기능에 대해 zip/unzip 또는 기타 번들 솔루션을 사용하는 것을 항상 반대합니다.
이것은 다음 문제를 일으킬 것이기 때문입니다.
단일 exe 파일 크기를 줄이는 방법!?? 또는 exe 파일이 너무 크지만 Hello World밖에 없는 이유는 무엇입니까?

항상 문제가 있고 해결해야 합니다. 왜 철저하게 하지 않는지.
사실 처음부터 IL-Merge와 유사한 방식을 사용해야 합니다.

사실, 사람들은 단일 EXE에 그렇게 집착하지 않습니다.
exe(1)+dll(1-2) 도 괜찮지만 400 마운트 dll은 아닙니다.
ppl은 코드를 서버 디스크로 절대 실행하지 않고 실행하고 서버 메모리를 차지하는 것을 원하지 않습니다.
사람들은 배포 비용을 줄이고 싶습니다.(디스크, 메모리, 대역폭 등...)

이 문제가 3.0 릴리스의 범위를 벗어나는 이 문서 에 설명된 단계를 통해 단일 파일 기능의 구현을 추적하도록 3.0 이정표를 제거했습니다.

@sgf , 파일 크기를 줄이는 작업이 필요하다는 데 동의합니다. 크기 축소 기회는 두 가지 형태로 제공되며 단일 exe에만 국한되지 않습니다.
1) 게시해야 하는 콘텐츠의 양을 줄입니다. 예를 들어:
* 도구와 같은 ILLinker를 사용하여 불필요한 바이너리, 어셈블리 일부 등을 트리밍합니다.
이 작업은 dotnet/coreclr#24092 및 mono/linker#607과 같은 문제로 별도로 추적됩니다.
* JITting이 지원되지 않는 "감소된 기능" 모드를 갖는 것과 같은 다른 조치를 고려할 수 있습니다.
2) 단일 파일 게시에 압축 기능을 추가합니다.

위의 기능을 함께 사용하여 단일 파일(및 단일 파일이 아닌) 앱의 크기를 줄일 수 있습니다.
예를 들어 HelloWorld 콘솔 앱의 경우
일반 게시 크기 = 67.4MB
잘린 크기 = 27MB
트리밍, 단일 파일, 압축(프로토타입을 통해) = 12MB

@swaroop-sridhar 응용 프로그램 내에서 단일 파일 exe의 경로를 가져올 수 있는 방법이 있습니까?
Assembly.GetExecutingAssembly().Location 를 사용하면 \AppData\Local\Temp.net에 추출 디렉토리가 출력됩니다.

@ chris3713 현재 exe 위치에 액세스하는 가장 좋은 방법은 기본 API에 대한 PInvoke-ing입니다. 예: GetModuleFileNameW (Null, <buffer>, <len>)

@ chris3713 현재 exe 위치에 액세스하는 가장 좋은 방법은 기본 API에 대한 PInvoke-ing입니다. 예: GetModuleFileNameW (Null, <buffer>, <len>)

덕분에 Process.GetCurrentProcess().MainModule.FileName 를 사용하게 되었습니다.

PublishSingleFile=true로 게시된 Windows 서비스로 asp .net 핵심 작업자/웹 API에서 제대로 작동합니다.

서비스를 등록하고 sc create testwk binPath="[...]/MyAspNetCoreWorker.exe" then sc start testwk 을 통해 실행하면 다음과 같은 성공 메시지가 나타납니다.

[...]\bin\publish\x64>sc start testwk

SERVICE_NAME: testwk
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 2  START_PENDING
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x7d0
        PID                : 5060
        FLAGS              :

[...]\bin\publish\x64>sc stop testwk

SERVICE_NAME: testwk
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 3  STOP_PENDING
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

런닝이 묶인 스테이지 2가 너무 기대되네요😀
그건 그렇고, Stage 2는 여전히 .Net Core 3.0의 일부로 계획됩니까?

노고에 감사드립니다. .net core의 퍼블리싱 서비스가 이제 정말 간단해졌습니다 👍

CoreRT: ( 2.5mb )

zip 해킹 없음 , 숨겨진 비용 없음, 엔진에 필요한 것만 포함, csproj 구성(반사)을 사용하여 사용하지 않는 기능 비활성화

이것이 dotnet이 필요로 하는 것입니다. GO와 경쟁하고 크기와 성능 면에서 모두 능가합니다.

관심 있는 사람은 리포지토리를 확인하세요.

https://github.com/dotnet/corert

MonoGame에 대한 샘플이 있습니다.

https://github.com/dotnet/corert/tree/master/samples/MonoGame

제안된 솔루션 중 어느 것도 이 결과를 얻을 수 없습니다. CoreRT는 진정으로 최고입니다. MS는 그것에 집중하지 않음으로써 큰 ​​실수를 하고 있습니다.

dotnet-sdk-3.0.100-preview8-013656-osx-x64.tar.gz 를 사용하여 macOS에서 이 기능을 테스트했습니다. 디버그에서 릴리스로 또는 그 반대로 구성을 전환하고 다시 빌드하면 실행 파일 크기에 10MB가 추가됩니다. 이전 구성으로 다시 컴파일해도 bin 디렉토리를 삭제하지 않는 한 이러한 크기 증가는 복구되지 않습니다.

mkdir /tmp/dotnet-preview8
curl -s https://download.visualstudio.microsoft.com/download/pr/a974d0a6-d03a-41c1-9dfd-f5884655fd33/cf9d659401cca08c3c55374b3cb8b629/dotnet-sdk-3.0.100-preview8-013656-osx-x64.tar.gz | tar -xvz -C /tmp/dotnet-preview8
export PATH=/tmp/dotnet-preview8:$PATH

dotnet new console -o /tmp/myApp
pushd /tmp/myApp

# publish with Debug
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Debug -o bin/a/b/c/d

bin/a/b/c/d/myApp
# outputs: Hello World!

du -sh bin/a/b/c/d
# outputs  70M  bin/a/b/c/d

# publish with Release
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Release -o bin/a/b/c/d

du -sh bin/a/b/c/d
# outputs:  80M bin/a/b/c/d

# publish with Debug again
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Debug -o bin/a/b/c/d
# still outputs:  80M   bin/a/b/c/d

빌드 설정을 변경하지 않아도 초기 빌드 이후에 Rebuild target( /t:Rebuild )을 호출하면 출력 크기가 커집니다.

@am11 봐주셔서 감사합니다. 이전 바이너리를 유지하는 게시는 알려진 문제입니다(cc @nguerrera).

.Net Core 3 미리보기 8 이후로 단일 파일 게시 앱을 시작할 수 없습니다.
이벤트 뷰어에 다음 오류가 있습니다.

저는 Windows Server 2019를 사용 중입니다.

편집: 이 오류는 .Net Core SDK Preview 7을 .Net Core SDK Preview 8로 업데이트한 후에 발생했습니다. 서버를 재부팅한 후 내 애플리케이션을 올바르게 다시 시작할 수 있습니다.

@Safirion 우리는 이러한 미리 보기와 관련된 기본 내부 형식을 변경했습니다. 한 미리 보기에서 출력을 건너뛰고 다른 미리 보기로 빌드할 수 있습니다. 미리 보기 8과 9 사이에는 휴식 시간이 없습니다.

Linux에서 기본 추출 경로는 /var/tmp/.net인 것 같습니다. AWS 람다에서는 /var 경로를 쓸 수 없으므로 해당 폴더를 만드는 데 실패합니다. DOTNET_BUNDLE_EXTRACT_BASE_DIR을 설정하지 않고 기본 실행 가능성을 얻으려면 이것을 /tmp/.net으로 변경할 것을 제안합니다. 또는 공통 위치(/var/tmp, /tmp, 바이너리와 동일한 디렉토리 등)에서 여러 번 시도해야 할 수도 있습니다.

@stevemk14ebr 해당 문제를 보고해 주셔서 감사합니다. 해당 작업을 추적하기 위해 새 문제를 제출할 수 있습니까? https://github.com/dotnet/core-setup

@jeffschwMSFT https://github.com/dotnet/core-setup/issues/7940

@jeffschwMSFT 동일한 오류가 .Net Core P9에서 RC1로 전달될 때 발생했습니다.

Description: A .NET Core application failed.
Application: Setup.exe
Path: C:\Users\Administrateur\Desktop\Setup.exe
Message: Failure processing application bundle.
Failed to determine location for extracting embedded files
A fatal error was encountered. Could not extract contents of the bundle

@Safirion 이 문제를 보고해 주셔서 감사합니다. 이것을 재현하기 위해 별도의 문제를 만들 수 있습니까? https://github.com/dotnet/core-setup
cc @swaroop-sridhar

@Safirion 재현 지침을 보내 주시겠습니까? 이 실패가 결정적입니까?
@jeffschwMSFT 가 위에서 제안한 대로 core-setup repo에 문제를 제출하십시오.

나는 이것을 보았고 이것은 앱이 임시 디렉토리에 액세스 할 수없는 환경에서 실행되는 경우에만 발생합니다. 예를 들어 내가 이렇게 하면:

set "TMP=wrong_path"
myapp.exe

그것은 실패한다

Failure processing application bundle.
Failed to determine location for extracting embedded files
A fatal error was encountered. Could not extract contents of the bundle

번들은 GetTempPath win32 API를 사용하여 임시 디렉토리를 찾습니다. env를 사용합니다. 변수 TMP , TEMP 등이 뒤따릅니다. 값이 있는 첫 번째 항목에 잘못된 경로가 포함되어 있으면 다음과 같이 실패합니다.

임시 경로가 올바르게 설정되었는지 확인하거나 추출을 수행하려는 위치로 DOTNET_BUNDLE_EXTRACT_BASE_DIR 를 명시적으로 설정하여 이 문제를 해결할 수 있습니다.

@Safirion 재현 지침을 보내 주시겠습니까? 이 실패가 결정적입니까?
@jeffschwMSFT 가 위에서 제안한 대로 core-setup repo에 문제를 제출하십시오.

.Net Core를 RC1로 업데이트하고 서버를 다시 시작한 후 이 문제를 재현할 수 없습니다. (RC1을 제거하고 RC1로 다시 업그레이드하기 위해 Preview 9를 다시 설치하려고 시도했지만 이번에는 내 앱이 잘 실행됩니다)

이 오류는 SDK 3.0 P7에서 SDK 3.0 P8로, SDK 3.0 P9에서 SDK 3.0 RC1로 이동할 때 발생했습니다.
그리고 두 경우 모두 서버를 다시 시작하면 문제가 해결됩니다.

RC1으로 업그레이드했을 때 .Net Core Windows 서비스(시스템에서 시작하기 때문에 C:\Windows\Temp\.net 폴더를 사용하여 추출하는 작업자)와 .Net Core WPF 앱(사용자 시작 세션 스크립트로 시작)을 사용합니다. 이 오류는 .Net Core SDK를 설치하는 동안 실행 중인 .Net core 작업자로 인해 발생한 것일 수 있습니다. 잘 모르겠습니다...

런타임이 아닌 SDK를 설치하므로 3개의 .Core 런타임(asp.net 코어, 데스크톱 .net 코어 및 코어)을 동시에 배포해야 하며 https://dot.net 에서 "전체 런타임"을 제공하지 않습니다. 설치 프로그램"(Desktop Runtime 설치 프로그램도 찾지 못해서 선택의 여지가 없습니다)...

업데이트: 신경 쓰지 말고 문서 를 찾았습니다.

안녕, 당신의 노고에 감사드립니다!

구성 파일(예: App.config)은 어떻게 배포되어야 합니까? 정확한 명령 시퀀스를 사용하여 RHEL 7.6에서 콘솔 앱을 방금 구축했습니다.

dotnet restore -r win-x64 --configfile Nuget.config
dotnet build Solution.sln --no-restore -c Release -r win-x64
dotnet publish --no-build --self-contained -c Release -r win-x64 /p:PublishSingleFile=true -o ./publish ./SomeDir/SomeProj.csproj

여기서 SomeProj.csproj는 <PublishTrimmed>true</PublishTrimmed> 를 활성화했으며 결과로 SomeProj.exe 및 SomeProj.pdb 2개의 파일을 얻었지만 SomeProj.config 는 아닙니다.

@catlion 이 *.config 파일에 대한 기본 동작을 갖도록 하려면 번들에서 제외해야 합니다. 기본적으로 모든 비 pdb 파일은 번들에 포함됩니다.
다음은 단일 파일에서 구성을 제외합니다.

<ItemGroup>
    <Content Update="*.config">
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
      <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
    </Content>
  </ItemGroup>

https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#build- 시스템 인터페이스

@morganbr

어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)

Windows용 헤드리스 및 WPF 앱

앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?

예, 우리는 다양한 기본 dll, 우리가 제어할 수 없는 일부 타사 항목, 다른 팀의 내부 항목을 P/Invoke합니다.

앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?

예, 하지만 CompilerServices를 사용하여 소스에서 컴파일합니다.

보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?

네

앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?

예, 저희 앱은 일반적으로 장기간 열려 있습니다.

크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?

예, 몇 분 정도 기다릴 수 있습니다.

앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

네

@john-cullen 감사합니다

추출 없이 단일 파일 앱을 실행하는 프로토타입 구현을 위해 몇 개의 PR을 단일 exe 분기에 연결합니다( 4단계 ).

https://github.com/dotnet/coreclr/pull/26197
https://github.com/dotnet/coreclr/pull/26504
https://github.com/dotnet/coreclr/pull/26697
https://github.com/dotnet/coreclr/pull/26904

@morganbr 에 대한 답변도 제공하겠습니다. :) 아직도 이 글을 읽고 계시는지 모르겠습니다. :)

1. 어떤 종류의 앱과 함께 사용하시겠습니까? (예: Windows의 WPF? Linux Docker 컨테이너의 ASP.NET? 다른 것?)

다양한 플랫폼(Linux, MacOS, Windows)에서 실행되는 텍스트 어드벤처(콘솔 앱)

1. 앱에 (.NET이 아닌) C++/네이티브 코드가 포함되어 있습니까?

아니요.

1. 앱이 원래 앱 빌드에 포함하지 않은 플러그인이나 기타 외부 dll을 로드합니까?

현재는 아니지만 장기적으로 특정 시나리오를 지원하는 것이 좋습니다.

1. 보안 수정 사항을 통합하기 위해 앱을 다시 빌드하고 재배포하시겠습니까?

네.

1. 앱이 200-500ms 더 느리게 시작되면 사용하시겠습니까? 5초 정도?

네.
(사용자에게 어떤 일이 일어나고 있음을 알리기 위해 일부 텍스트 출력이나 메시지 상자를 제공하는 것이 좋을 것입니다)

1. 앱에 허용되는 가장 큰 크기는 무엇입니까? 5MB? 10? 20? 50? 75? 100?

10-20MB

1. 크기 및/또는 시작 시간을 최적화하기 위해 더 긴 릴리스 빌드 시간을 허용하시겠습니까? 가장 오래 받아 들일 수 있는 것은 무엇입니까? 15초? 30 초? 1 분? 5 분?

1분 이상은 괜찮습니다.

1. 앱 크기를 반으로 줄이는 경우 추가 작업을 수행하시겠습니까?

혹시.

@lenardg님, 답변 감사합니다.

이 문제는 .NET Core 3.0 단일 파일 배포 기능의 진행 상황을 추적합니다.
다음은 기능에 대한 디자인 문서 및 준비 계획입니다.

이것은 배포를 용이하게 하고 크기를 줄이는 데 매우 유용한 기능입니다.
특히 그룹 정책을 통해 환경이 엄격하게 제어되는 엔터프라이즈 배포의 경우 설계에 대한 개선 사항이 거의 없습니다.

1. 조건부로 단일 실행 파일을 압축하면서 압축할 수 있습니까?
   즉, Wrap과 같은 로직을 추가하므로 다른 도구 통합이 필요하지 않습니다.
   압축하면 더 작은 exe가 생성됩니다.

2. exe를 시작하면 내용이 임시 폴더로 확장됩니다. 당사 제품의 경우 특정 사용자 사이트에서 클라이언트 시스템이 엄격하게 제어되며 임시 폴더 또는 %userprofile% 위치에서 실행 파일을 실행하는 것을 허용하지 않습니다.

추출할 위치를 지정/제어할 수 있거나 ".\extract" 또는 그러한 하위 폴더에서 '인플레이스 추출'이 될 수 있습니까?
이를 통해 그룹 정책 준수는 물론 단일 exe 기능을 사용할 수 있습니다.

1. 패킹하기 전에 폴더에 서명하고 패킹할 파일을 선택하는 것이 가능한가요?
   단일 exe에 서명할 수 있지만 추출 파일은 서명되지 않으므로 다른 특정 클라이언트 위치에서는 바이너리가 서명되지 않는 한 실행을 허용하지 않습니다.

@RajeshAKumar https://github.com/dotnet/core-setup/issues/7940

오늘 @Safirion 과 동일한 문제를 보았습니다. 우분투를 대상으로 하는 dotnetcore 3.0 앱이 있고 내 Synology 서버에서 실행했습니다. 추출되지 않습니다. "치명적인 오류가 발생했습니다. 번들의 내용을 추출할 수 없습니다"라는 오류와 함께 계속 실패했습니다. 여러 번 재건했지만 똑같습니다. 호스트를 재부팅한 후 다시 정상적으로 작동했습니다.

여기에 파일 잠금이나 무언가가 있는지, 그리고 그것을 디버깅하는 방법에 대한 시간이 있는지 이해하는 데 유용할 것입니다.

@RajeshAKumar dotnet /core-setup#7940

해당 링크가 어떻게 도움이 되는지 잘 모르겠습니다.
그것은 단지 임시 추출에 대해 이야기합니다. 저는 위에 3가지 사항을 나열했습니다.

그리고 그 중 하나에 대한 해결책을 제시했습니다. 나머지 2개는 잘 모르겠음

그리고 그 중 하나에 대한 해결책을 제시했습니다. 나머지 2개는 잘 모르겠음

임시 추출물은 우리에게 효과가 없으므로 해결책이 아닙니다. 내 요청은 추출 위치를 제어하거나 하위 폴더로 추출할 수 있는 기능이었습니다.
많은 클라이언트 컴퓨터의 IT 관리자는 임시 폴더나 사용자 프로필에서 실행 파일을 실행하는 것을 허용하지 않습니다.
게시물을 다시 읽으십시오. https://github.com/dotnet/coreclr/issues/20287#issuecomment -542497711

@RajeshAKumar : 호스트가 번들의 내용을 추출하는 기본 경로를 제어하도록 DOTNET_BUNDLE_EXTRACT_BASE_DIR 를 설정할 수 있습니다.
자세한 내용은 https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location을 참조하십시오.

@RajeshAKumar : 번들된 단일 exe 압축은 .net 5에서 고려 중인 기능입니다. https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#compression

지금은 생성된 단일 exe를 압축하려면 다른 유틸리티를 사용해야 합니다.

@RajeshAKumar 서명과 관련하여 게시되고 단일 exe로 번들되는 모든 파일/바이너리를 서명할 수 있습니다. 호스트가 포함된 구성 요소를 디스크로 추출하면 개별 파일 자체에 서명됩니다. 언급한 대로 빌드된 단일 파일 자체에 서명할 수도 있습니다.

귀하의 요구 사항을 충족합니까?

@Webreaper 문제를 재현할 수 있다면 COREHOST_TRACE 를 켜고( COREHOST_TRACE 환경 변수를 1 로 설정) 앱을 실행하고 생성된 로그를 공유해 주시겠습니까? 감사 해요.

@swaroop-sridhar
이것은 매우 멋진 기능입니다. 어떤 dotnet 릴리스에서 언제 다른 단계를 사용할 수 있는지에 대한 링크가 있습니까?

@RajeshAKumar : 호스트가 번들의 내용을 추출하는 기본 경로를 제어하도록 DOTNET_BUNDLE_EXTRACT_BASE_DIR 를 설정할 수 있습니다.
자세한 내용은 https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location을 참조하십시오.

swaroop-sridhar님, 감사합니다.

@RajeshAKumar 서명과 관련하여 게시되고 단일 exe로 번들되는 모든 파일/바이너리를 서명할 수 있습니다. 호스트가 포함된 구성 요소를 디스크로 추출하면 개별 파일 자체에 서명됩니다. 언급한 대로 빌드된 단일 파일 자체에 서명할 수도 있습니다.

귀하의 요구 사항을 충족합니까?

'컴파일'을 중단하고 부분을 게시하는 방법을 알아 내려고 노력하고 있습니다.
현재 다음 명령을 사용하고 있으므로 서명할 수 없습니다.
publishargs=-c 릴리스 설정 /p:PublishSingleFile=True /p:PublishTrimmed=True /p:PublishReadyToRun=false
도트넷 게시 -r win-x64 -o bin\Output\Win64 %publishargs%

위의 컴파일과 트림 및 패키지가 있기 때문에 깨는 방법을 모릅니다.
귀하의 접근 방식을 이상적으로 사용하려면 컴파일하고 서명한 다음 최종적으로 게시해야 합니다.

@Webreaper 문제를 재현할 수 있다면 COREHOST_TRACE 를 켜고( COREHOST_TRACE 환경 변수를 1 로 설정) 앱을 실행하고 생성된 로그를 공유해 주시겠습니까? 감사 해요.

감사 해요. 지금은 재부팅을 해서 없어졌지만 다시 발생하는 경우에 대비해 두는 것이 좋습니다!

@RajeshAKumar 번들링 직전에 실행되는 대상에 서명에 태그를 지정해야 합니다.
PublishReadyToRun 및 PublishTrimmed 를 사용하고 있으므로 표준 Afterbuild 또는 BeforePublish 대상을 사용할 수 없습니다.

BundlePublishDirectory 직전에 실행되고 서명을 수행하는 대상을 추가할 수 있습니다.

@swaroop-sridhar
이것은 매우 멋진 기능입니다. 어떤 dotnet 릴리스에서 언제 다른 단계를 사용할 수 있는지에 대한 링크가 있습니까?

@etherealjoy 감사합니다. 번들에서 직접 실행되는 단일 파일에 대한 작업이 진행 중이며 .net 5 릴리스를 목표로 하고 있습니다.

@RajeshAKumar 번들링 직전에 실행되는 대상에 서명에 태그를 지정해야 합니다.
PublishReadyToRun 및 PublishTrimmed 를 사용하고 있으므로 표준 Afterbuild 또는 BeforePublish 대상을 사용할 수 없습니다.

BundlePublishDirectory 직전에 실행되고 서명을 수행하는 대상을 추가할 수 있습니다.

감사합니다.
당신이 준 링크는 MS Build 작업처럼 보입니다.
"BundlePublishDirectory"에 대한 처리기를 어떻게 생성합니까? 이것은 Studio/Project props/Build Events에 있습니까, 아니면 처음부터 무언가를 만들어야 합니까?

@RajeshAKumar 이 경우 사전 빌드 사후 빌드 이벤트보다 더 세분화된 것이 필요합니다.
따라서 프로젝트 파일을 편집하고 다음과 같이 추가해야 한다고 생각합니다.

<Target Name="Sign" BeforeTargets="BundlePublishDirectory">
    ... 
</Target>

dotnet pack 명령의 예상되는 동작은 무엇입니까? 로컬 nuget 저장소에 푸시된 단일 exe 아티팩트가 있다고 가정해 보겠습니다. 초콜릿으로 설치하려고 하면 프로젝트 파일에 나열된 모든 nuget dep를 복원하려고 합니다. 이전에는 예상했지만 이 동작이 SFD에 맞는지 의심스럽습니다.

단일 파일 자체 포함 WPF 응용 프로그램을 추출하는 동안 진행률 표시줄이나 로드 표시기를 추가할 수 있습니까? 아무 일도 일어나지 않고 시간이 걸릴 수 있습니다.
기본 자체 포함 WPF 앱은 80Mo 이상이며 추출에는 5초 이상 걸릴 수 있습니다. 사용자 친화적이지 않으며 최종 사용자로부터 불만을 받았습니다.

편집: 실행 시 이전 버전을 자동으로 정리하는 방법이 있습니까?

@Safirion 나는 그것이 어떻게 이 기능의 범위에 포함될 수 있는지 알 수 없습니다. 시작 화면을 표시하고 실제 앱을 실행한 다음, 시작될 때 실제 앱이 시작 화면 프로그램을 중지하도록 하는 작은 앱을 만드는 것이 가장 좋습니다.

@ProfessionalNihilist 제 요점을 이해하지 못하는 것 같습니다.
빈 WPF 앱은 컴파일 시 80mo의 디스크 저장소를 자체 포함하여 사용합니다. 프레임워크 종속 앱으로 컴파일하지 않고는 80mo보다 작은 WPF 앱을 가질 수 없습니다 😉
문제는 앱이 실행되기도 전에 포함된 프레임워크를 추출하는 시간입니다. 따라서 .Net Core에서 수행해야 하며 이 기능과 완전히 관련이 있습니다.

앱이 압축 해제되는 동안 표시될 png 기능을 추가할 수 있습니까?

@Safirion @ayende 시작 중 "UI 피드백" 부족은 여기에서 추적됩니다: https://github.com/dotnet/core-setup/issues/7250

dotnet pack 명령의 예상되는 동작은 무엇입니까? 로컬 nuget 저장소에 푸시된 단일 exe 아티팩트가 있다고 가정해 보겠습니다. 초콜릿으로 설치하려고 하면 프로젝트 파일에 나열된 모든 nuget dep를 복원하려고 합니다. 이전에는 예상했지만 이 동작이 SFD에 맞는지 의심스럽습니다.

@catlion PublishSingleFile 속성은 dotnet publish 명령에서만 지원됩니다. 따라서 dotnet pack 에는 영향을 미치지 않습니다. 단일 파일과 패키징을 모두 사용하려는 동기가 있습니까?

편집: 실행 시 이전 버전을 자동으로 정리하는 방법이 있습니까?

현재 릴리스의 @Safirion , 정리는 수동이며 호스트는 추출된 파일을 제거하려고 시도하지 않습니다. 이는 향후 실행에서 잠재적으로 재사용될 수 있기 때문입니다.

좋아, 내가 직접 청소기를 만들게 😉
당신의 답변에 감사드립니다.

모노에 대해 특별한 것이 없는 @cup 은 표준 컴파일일 뿐입니다. 이제 너겟 참조를 추가하면 해당 솔루션은 더 이상 단일 파일이 아닙니다. Mono는 단일 파일을 달성하기 위해 mkbundle 를 가지고 있습니다.

@수치 만 확실해? 위의 예에서는 단일 3KB 파일을 생성합니다. dotnet 최소 크기는 27MB인 반면:

https://github.com/dotnet/coreclr/issues/24397#issuecomment -502217519

@컵 네

C:\Users\Robin> type .\Program.cs
using System;
class Program {
   static void Main() {
      Console.WriteLine("sunday monday");
   }
}
C:\Users\Robin> C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe .\Program.cs
Microsoft (R) Visual C# Compiler version 4.8.3752.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240

C:\Users\Robin> .\Program.exe
sunday monday
C:\Users\Robin> dir .\Program.exe


    Verzeichnis: C:\Users\Robin


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       10.11.2019     18:36           3584 Program.exe

@수치 만 확실해? 위의 예에서는 단일 3KB 파일을 생성합니다. dotnet 최소 크기는 27MB인 반면:

#24397 (댓글)

모노가 이미 설치되어 있기 때문에 3k 파일만 작동합니다. dotnetcore 단일 파일 배포의 요점은 clr을 설치할 필요가 없으며 런타임을 포함하는 독립 실행형 단일 exe라는 것입니다.

@Webreaper 는 실제로 .NET Framework에서 실행될 가능성이 있는 mono sun-mon.exe 를 작성하지 않았기 때문에 컴파일할 때 모노에서 mcs만 사용했다고 생각합니다.

그러나 .NET Core는 프레임워크 종속 배포라고도 하는 사전 설치된 런타임 시나리오도 지원합니다. .deps.json 및 .runtimeconfig.json 와 같은 .NET Core용 추가 파일이 몇 개 있기 때문에 이 경우에는 여전히 단일 파일 배포가 아닙니다.

@ chris3713 현재 exe 위치에 액세스하는 가장 좋은 방법은 기본 API에 대한 PInvoke-ing입니다. 예: GetModuleFileNameW (Null, <buffer>, <len>)

Environment.CurrentDirectory 가 더 나은 솔루션인 것 같지만 아직 Windows 이외의 다른 방법에서 두 가지 접근 방식을 모두 시도하지는 않았습니다.

편집: 아니요. 해당 경로는 애플리케이션의 다른 진입점에서 변경될 수 있습니다. 좋지 않다.

약간 관련된 메모에서 Mac용 VS의 최신 미리 보기에서 Blazor 앱의 단일 파일 게시에서 이 회귀를 발견했습니다. https://github.com/aspnet/AspNetCore/issues/17079 - 아래에서 보고했습니다. AspNeCore/Blazor, 그러나 이것이 coreclr 그룹과 더 관련이 있을 수 있습니다. 확실하지 않습니다. 너희들이 움직일 수 있도록 남겨둘게!

@Suchiman 조심하세요. 컴파일러에 문제가 있습니다.

https://github.com/dotnet/roslyn/issues/39856

@cup 은 내가 명명한 파일 경로를 사용한다는 점을 제외하고는 C++로 작성된 이전 C# 5 컴파일러를 사용하고 있다는 점을 제외하고는 roslyn이 아니며 아마도 그러한 이유로 해당 문제를 종료할 것입니다. 하지만 roslyn은 같은 일을 할 수 있습니다. 단지 다른 길일 뿐입니다...

약간 관련된 메모에서 Mac용 VS의 최신 미리 보기에서 Blazor 앱의 단일 파일 게시에서 이 회귀를 발견했습니다. aspnet/AspNetCore#17079 - AspNeCore/Blazor에서 보고했지만 다음과 같을 수 있습니다. coreclr 그룹과 더 관련이 있습니다. 확실하지 않습니다. 너희들이 움직일 수 있도록 남겨둘게!

@Webreaper 정적 자산과 관련된 ASP.net 문제처럼 보이는 문제를 보고해 주셔서 감사합니다. 그래서, 그것이 그것을 제출하는 올바른 장소입니다.

* 게시물을 다른 문제에서 여기로 이동합니다.

@swaroop-sridhar ,

DotNet Core 단일 파일 WPF 앱의 시작 시간은 .net 4.7에서 빌드된 원래 ILMerge-ed WPF 애플리케이션보다 훨씬 느립니다. 이것은 예상되는 것입니까, 아니면 앞으로 개선될 것입니까?

빌드는 내 ImageOptimizer에서 가져옵니다. https://github.com/devedse/DeveImageOptimizerWPF/releases

| 유형 | 예상 첫 시작 시간 | 예상 두 번째 시작 시간 | 크기 | 다운로드 링크 |
| -- | -- | -- | -- | -- |
| .NET 4.7.0 + ILMerge | ~3초 | ~1초 | 39.3MB | 링크 |
| dotnet publish -r win-x64 -c 릴리스 --self-contained=false /p:PublishSingleFile=true | ~10초 | ~3초 | 49MB | |
| dotnet publish -r win-x64 -c 릴리스 /p:PublishSingleFile=true | ~19초 | ~2초 | 201MB | |
| dotnet publish -r win-x64 -c 릴리스 /p:PublishSingleFile=true /p:PublishTrimmed=true | ~15초 | ~3초 | 136MB | 링크 |
| dotnet publish -r win-x64 -c 릴리스 | ~2.5초 | ~1.5초 | exe의 경우 223kb(dll의 경우 +400mb) | |

@devedse , 확인하기 위해 "두 번째 시작"이 여러 실행(첫 번째 제외)의 평균입니까?
궁금하지만 /p:PublishSingleFile=true /p:PublishTrimmed=true 실행이 ` /p:PublishSingleFile=true 실행보다 느려야 하는 이유에 대한 설명이 부족합니다.

그래서 조사하기 전에 "두 번째 시작"의 숫자가 안정적인 숫자이고 시작의 차이가 재현 가능한지 확인하고 싶습니다.

또한 이 문제는 단일 파일 플러그인에 관한 것입니다. 성능 토론을 새 문제로 옮기거나 dotnet/coreclr#20287로 옮기시겠습니까? 감사 해요.

@swaroop-sridhar , 평균에 대한 귀하의 질문에 대한 답변:
이것을 매우 정확하게 시간을 측정하는 것은 약간 어렵습니다. 그래서 타이밍은 응용 프로그램이 시작되는 동안 계산한 다음 시작 시간에 상당한 차이가 있는지 확인하기 위해 몇 번 시도하여 수행되었습니다. 더 나은 방법을 알고 있다면 내 솔루션을 구축하여 쉽게 재현할 수 있습니다. https://github.com/devedse/DeveImageOptimizerWPF

내 주요 질문은 번들(단일 파일) 응용 프로그램이 번들되지 않은 .exe 파일과 비교하여 시작하는 데 시간이 더 오래 걸리는 이유와 관련이 있습니다.

여기에서는 틀릴 수 있지만 단일 파일에 오버헤드가 있기 때문에 이해가 됩니다. 기본적으로 다른 앱을 시작하는 앱이 있습니다. ILMerge가 직접 시작되는 동안. ILMerge는 참조된 dll만 exe로 병합했으며 현재 PublishSingleFile로 수행 중인 다른 레이어에 전체를 래핑하지 않았습니다.

@devedse 단일 파일은 기본적으로 dotnet 실행을 시작하기 전에 추출, 체크섬 확인 등입니다.
그래서 시간이 걸렸나 봅니다.
추출은 "캐시"되므로 다음에 실행할 때 IO 오버헤드가 없습니다.

@RajeshAKumar , 흠 이 시나리오에서 정말 갈 길을 추출하고 있습니까? ILMerge 방식으로 가서 실제로 DLL을 하나의 단일 번들로 병합하는 것이 더 좋지 않을까요?

특히 더 큰 .exe 파일의 경우 모든 파일을 두 번 저장하는 디스크 공간 비용도 발생합니다.

@devedse 우리는 모두 이 기능(번들에서 실행)의 다음 단계를 기다리고 있지만 현재로서는 이것이 유일한 솔루션입니다. 😉

https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md

이것은 데스크탑에서 JIT를 사용하여 얻는 것입니다. 느린 시작, Apple만이 이것을 이해한 것 같습니다.

(대부분 이미 언급한 내용을 반복함):
첫 번째 시작은 훨씬 느릴 것으로 예상됩니다. 앱을 디스크에 추출하므로 IO가 많습니다. 두 번째 및 이후 시작은 단일 파일이 아닌 앱 버전과 거의 동일해야 합니다. 내부 측정에서 우리는 차이를 보지 못했습니다.

측정 방법: 추적(Windows의 ETW)을 사용했습니다. 프로세스가 시작될 때 이벤트가 있고 이를 위해 사용할 수 있는 런타임 이벤트가 있습니다. 하지만 정확히는 쉽지 않습니다.

@Safirion 이 언급했듯이 우리는 .exe에서 직접 대부분의 관리 코드를 실행해야 하는 단일 파일에 대한 다음 개선 작업을 진행 중입니다(디스크로 추출하지 않음). 아직 출시 열차를 약속할 수 없습니다.

JIT: 모든 프레임워크는 Ready2Run(CoreFX, WPF)으로 사전 컴파일되어야 하므로 시작 시 애플리케이션 코드만 JIT되어야 합니다. 완벽하지는 않지만 큰 차이를 만들어야 합니다. ~1-2초의 시작 시간을 감안할 때 이미 모든 테스트에서 이를 사용하고 있다고 생각합니다.

모두 감사합니다. 계획된 다음 단계를 알지 못했습니다. 이것은 그것을 명확히합니다.

첫 번째 시작은 훨씬 느릴 것으로 예상됩니다. 앱을 디스크에 추출하므로 IO가 많습니다.

이런 일이 일어나서는 안 됩니다. 디자인에 따라 사용자 경험을 끔찍하게 만들고 끔찍한 선택을 하게 됩니다. 이것이 바로 개발자가 사용하는 기술을 사용자가 싫어하게 만드는 방법입니다.

@Safirion 이 언급했듯이 우리는 .exe에서 직접 대부분의 관리 코드를 실행해야 하는 단일 파일에 대한 다음 개선 작업을 진행 중입니다(디스크로 추출하지 않음). 아직 출시 열차를 약속할 수 없습니다.

곧 변경될 예정인 경우 지금 공식적으로 출시하는 이유는 무엇입니까? 미리보기/실험으로 표시되어야 합니다.

내 생각에 이것은 시간과 리소스 낭비입니다. AOT 컴파일 및 트리 흔들기에 집중하고 모든 리소스를 거기에 넣고 해킹을 중지하십시오.

@RUShy 왜 이렇게 증오가 많아? 처음 시작할 때 시작 지연을 원하지 않으면 단일 파일 배포를 사용하지 마십시오.

시작 시간이 10초 미만으로 상당히 짧고 처음 실행하는 것이므로 전혀 문제가 되지 않습니다. 나는 대부분의 경우에 한 번 시작한 다음 며칠/몇 주 동안 실행될 것이라는 것을 의미하는 서버 측 웹 앱을 배포하고 있습니다. 따라서 초기 추출은 사물 계획에서 무시할 수 있습니다. 단일 컴파일된 이미지가 있을 때까지 중단합니다. 수백 개의 DLL을 주변에 복사하는 것보다 훨씬 쉽게 배포할 수 있기 때문입니다.

제 경우에는 +1, 단일 exe를 생성하는 빌드 도커와 앱을 실행하기 위한 별도의 도커가 있습니다(dotnet이 없는 일반 알파인 도커 이미지 사용). bulid 단계 후에 런타임 컨테이너를 한 번 핫 로드하고 레이어를 docker-commit 합니다. 그 결과 프레임워크 종속 배포와 비교하여 성능 저하가 관찰되지 않았습니다. 번들에서 로드 파일 메커니즘이 구현되고 출시되면 중간 핫 로드 단계를 제거합니다.

@vitek-karas, "번들에서 런타임 자산 로드" 기능을 추적하는 데 문제가 있습니까? 어떤 종류의 장애물이 있는지 이해하는 데 관심이 있습니다. :)

@am11 현재 세부 계획을 짜고 있습니다. https://github.com/dotnet/coreclr/tree/single-exe에서 완료된 프로토타입을 볼 수 있습니다. 실제 구현은 아마도 너무 다르지 않을 것입니다(분명히 더 나은 인수분해 등이 있지만 핵심 아이디어는 건전한 것 같습니다).

@Webreaper 웹 앱의 경우 전혀 문제가 되지 않지만 지금은 WPF/WinForm 개발에 .Net Core 3이 권장되고 백 .dll에서 잃어버린 데스크톱 애플리케이션 .exe를 공유하는 것이 옵션이 아니기 때문일 수 있습니다. 이 기능의 첫 번째 단계와 관련된 좌절감을 이해합니다.
;)

그리고 사용자는 오늘 exe를 다시 클릭하기 전에 10초(또는 3초 이상)를 기다리지 않습니다 . 로딩 표시기가 없다는 사실은 이 기능의 두 번째 큰 문제입니다. 불행히도 로딩 표시기는 .Net Core 3.1의 일부가 아니므로 사용자는 인내심을 가져야 합니다...

데스크톱 개발자는 2단계를 기다리고 있으며 .Net 5의 일부가 될 것으로 예상합니다. 실제로 .Net Core의 데스크톱 개발은 최종 사용자에게 정말 나쁜 경험이기 때문입니다.

@RUShy 왜 이렇게 증오가 많아? 처음 시작할 때 시작 지연을 원하지 않으면 단일 파일 배포를 사용하지 마십시오.

이것은 증오가 아닙니다. 이것은 건설적이고 정직한 피드백입니다. 저는 C#과 .net에 관심이 있습니다. 저는 매일 둘 다 사용합니다. GO나 다른 것으로 대체되는 것을 원하지 않습니다.

최근:
https://old.reddit.com/r/golang/comments/e1xri3/choosing_go_at_american_express/
https://old.reddit.com/r/golang/comments/ds2z51/the_stripe_cli_is_now_available_and_its_written/

부정적인 피드백은 긍정적인 피드백만큼 도움이 되지만 "증오"로 받아들이면 나는 당신을 도울 수 없습니다

.net 커뮤니티는 조용하고 수동적이며 편향되어 있습니다. 파괴가 유일한 방법입니다.

.NET은 객관적으로 오늘날 대부분의 애플리케이션에 가장 적합한 플랫폼입니다. 더 많은 사람들이 깨달았으면 좋겠습니다.

Java, Go, Rust, Node, ...와 같은 다른 플랫폼에서 들은 전쟁 이야기는 솔직히 혼란스럽습니다. 이러한 플랫폼은 생산성 킬러입니다.

내 생각에 이것은 시간과 리소스 낭비입니다. AOT 컴파일 및 트리 흔들기에 집중하고 모든 리소스를 거기에 넣고 해킹을 중지하십시오.

동의한다. .Net에는 훌륭한 유형 시스템이 있습니다. 리플렉션을 사용하여 우회하는 경우가 너무 많습니다. 툴링은 AOT에 초점을 맞춰야 하지만 반사를 최소화하는 데도 중점을 두어야 합니다. https://github.com/dotnet/corert/issues/7835#issuecomment -545087715는 아주 좋은 시작이 될 것입니다. Null의 10억 달러 오류가 이제 완화되고 있습니다. 리플렉션이 없는 코드(또는 링커 또는 corert 호환 코드)에 대한 설정 또는 마커를 사용하여 리플렉션에서도 동일한 작업을 수행해야 합니다.

반사를 제거하는 것은 굉장할 것입니다. 성찰이 금지된다면 많은 고통을 피할 수 있을 것입니다. 가장 최근에 겪은 공포 이야기는 사용된 프레임워크(서비스 패브릭 SDK)가 재정의가 불가능한 직렬화 구현의 어셈블리 이름에 직렬화된 바이트를 묶는 것이 현명하다는 것을 알았기 때문에 코드를 이동할 수 없다는 사실을 발견한 것입니다.

낙담하는 성찰을 향한 모든 진전은 진전이 될 것입니다.

Btw는 어셈블리를 병합하여 번들 크기와 로드 시간을 줄이고 전체 프로그램 최적화를 허용하는 방법을 찾고 있었습니다. 나는 이 문제가 실제로 그것을 겨냥한 것이 아니라는 것을 알고 있습니다.

편집: 이 게시물은 명확히 하기 위해 몇 가지 반응을 수집했기 때문입니다. 메타 프로그래밍은 코드가 데이터이고 내 통제 하에 있는 디자인 타임에 이루어져야 한다고 생각합니다.

내가 신뢰할 수 있는 불변성을 적용하는 데 사용하고 싶은 유형입니다. 런타임 반사는 그 신뢰를 깨뜨립니다.

따라서 런타임 리플렉션이 디자인 타임 메타 프로그래밍으로 대체되기를 바랍니다. 분석기, 빠른 수정 및 리팩토링과 같은 사용 사례와 더 강력하게 중복될 수 있는 곳입니다.

이 영역의 구독자 태그 지정: @swaroop-sridhar
구독을 원하시면 danmosemsft에 알려주십시오.

단일 파일 기능 디자인은 이 문서에 있습니다: https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md
이 문제에서 단일 파일 앱의 진행 상황 추적: https://github.com/dotnet/runtime/issues/36590.
이 문제에 대한 피드백과 제안을 주신 모든 분들께 감사드립니다.