Runtime: 単一ファイル配布をサポート

興味深いことに、このイニシアチブはCoreRTとどのように比較されますか？ 彼らは同じような努力のように見えますか？

これは「おそらくネイティブユーザーコード」に関連していますか？つまり、AOTだけでなく、コードをJITコンパイルすることもできますか？

また、ランタイムコンポーネント（'ネイティブコード（ランタイム、ホスト、フレームワークのネイティブ部分.. '）はCoreCLRリポジトリからのものになると思いますか？

あなたは素晴らしい質問をしていますが、これはまだ設計の初期段階であるため、私はまだ素晴らしい答えを持っていません。

興味深いことに、このイニシアチブはCoreRTとどのように比較されますか？ 彼らは同じような努力のように見えますか？

多少類似した結果（単一のファイル）が発生する可能性がありますが、設計には、機能する/機能しない異なるパフォーマンス特性または機能がある場合があります。 たとえば、考えられる設計は、.NETCoreの自己完結型アプリケーション内のすべてのファイルを基本的に1つのファイルに連結することです。 これは数十MBであり、開始が遅くなる可能性がありますが、一方で、プラグインのロード、リフレクションエミット、高度な診断など、CoreCLRの全機能を使用できます。 CoreRTは、スペクトルのもう一方の端と見なすことができます。これは1桁のMBであり、起動時間が非常に高速ですが、JITがないため、プラグインをロードしたり、リフレクションエミットを使用したりできず、ビルド時間はほとんどの場合よりも遅くなります。 NET開発者は慣れています。 現在、時間の経過とともに改善される可能性のある他のいくつかの制限がありますが、.NET Core 3.0では改善されない可能性があります（リフレクション用の注釈が必要、一部の相互運用シナリオが欠落している、Linuxでの診断が制限されている可能性があります）。 両者の間のどこかにアイデアもあります。 人々が作りたい/避けたいトレードオフを持っているなら、私たちはそれらについて聞いてみたいと思います。

これは「おそらくネイティブユーザーコード」に関連していますか？つまり、AOTだけでなく、コードをJITコンパイルすることもできますか？

「ネイティブユーザーコード」とは、アプリにC ++ネイティブコード（ユーザーまたはサードパーティコンポーネントによって記述されたもの）が含まれている可能性があることを意味します。 そのコードでできることには制限があるかもしれません-それが.dllにコンパイルされている場合、それを実行する唯一の方法はディスクからです。 .libの場合、リンクすることは可能かもしれませんが、それは他の問題を引き起こします。

また、ランタイムコンポーネント（「ネイティブコード（ランタイム、ホスト、フレームワークのネイティブ部分..」）はCoreCLRリポジトリからのものになると思いますか？

上記のすべてに基づいて、どのリポジトリが関係しているかを把握します。 「フレームワークのネイティブ部分」には、ClrCompressionやUnixPALなどのCoreFXネイティブファイルが含まれます。

この方法での単一ファイルの配布は、起動時間がわずかに遅い場合でも、展開を容易にするために非常に貴重です。 私は、その一部をあきらめることを余儀なくされるよりも、むしろ全力を発揮する能力を持っている方がいいです。

私たちが興味を持っているいくつかのシナリオ。 これはクロスプラットフォームの観点からどのように機能しますか？
プラットフォームごとに個別の「ファイル」があると思いますか？

ネイティブコードに関して、プラットフォームに基づいてさまざまなネイティブコンポーネントを選択するにはどうすればよいですか？

私たちが興味を持っているいくつかのシナリオ。 これはクロスプラットフォームの観点からどのように機能しますか？
プラットフォームごとに個別の「ファイル」があると思いますか？
ネイティブコードに関して、プラットフォームに基づいてさまざまなネイティブコンポーネントを選択するにはどうすればよいですか？

@ayende 、 @ morganbrのコメントから引用しています：

考えられる設計は、基本的に.NETCoreの自己完結型アプリケーション内のすべてのファイルを単一のファイルに連結することです。

自己完結型アプリケーションの現在のクロスプラットフォームストーリーは、プラットフォーム固有のランタイムとともにアプリケーションを出荷するため、ターゲットとするプラットフォームごとにデプロイメントパッケージを作成することです。

@morganbrこのような詳細な回答を提供するために時間を割いていただきありがとうございます

デザインがどこに行くのか興味があります。これは本当に興味深いイニシアチブです。

単一ファイルを使用したい人のためにいくつか質問があります。 あなたの答えは私たちの選択肢を絞り込むのに役立ちます：

1. どのようなアプリで使用する可能性がありますか？ （たとえば、Windows上のWPF？Linux Dockerコンテナー内のASP.NET？他に何か？）
2. アプリに（.NET以外の）C ++ /ネイティブコードが含まれていますか？
3. アプリは、アプリのビルドに元々含まれていなかったプラグインやその他の外部dllをロードしますか？
4. アプリを再構築して再配布し、セキュリティ修正を組み込むことをいとわないですか？
5. アプリの起動が200〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？
6. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 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の問題について知っている人はもっと広いですか？

たとえば、考えられる設計は、.NETCoreの自己完結型アプリケーション内のすべてのファイルを基本的に1つのファイルに連結することです。

それを圧縮することを見てください。 またはファイルで圧縮ファイルシステムを使用していますか？

@tpetrina 、ありがとう！ ポイント3は、いくつかの設計角度をカバーしています。

1. ツリーシェーキングは、プラグインが依存しているコードを削除する可能性があるため、ツリーシェーカーが認識していないプラグインの読み込みには適していません。
2. CoreRTには現在、プラグインをロードする方法がありません
   ポイント5は、サイズと起動時間のどちらを最適化するか（およびその量）についてです。
   ポイント8、はい私は主に反射のことを考えていました

@TheBlueSky 、他の人にも連絡を取りましたが、GitHubコミュニティの情熱的な人から意見を聞くのに役立ちます。

@benaadams 、圧縮はテーブルにありますが、私は現在、全体的な設計に直交していると考えています。 簡単な実験では、起動時間（およびビルド時間）の数秒を犠牲にして、zip処理でサイズが約50％削減される可能性があることが示唆されています。 私にとって、これは根本的なトレードオフであり、それを行う場合はオプションである必要があります。

@morganbr圧縮を使用する場合、起動時間は数秒ですか？ UPXが減圧速度を主張していることを考えると、信じがたいことです。

古代のPentium133では最大10MB/秒、AthlonXP2000以降では最大200MB/秒。

@morganbr 、私にとっての答えは次のとおりです。

1）サービス（基本的に、Kestrelを実行するコンソールアプリ）。 Windowsサービス/LinuxデーモンまたはDockerで実行します。
2）はい
3）はい、通常はAssemblyContext.LoadFromを使用して管理されたアセンブリです。 これらはエンドユーザーによって提供されます。
4）はい、それは予想されます。 実際、とにかくフレームワーク全体をすでにバンドルしているので、その観点からの変更はありません。
5）サービスとしては、起動時間はあまり気にしません。 5秒が妥当です。
6）おそらく75MBが限界です。 すべてのパッケージは圧縮されて配信されるため、実際の圧縮サイズに大きく依存します。
7）リリースビルドの場合、より長い（さらに長い）ビルド時間が許容されます。
8）はい、もちろんです。 サイズはそれほど重要ではありませんが、小さい方が良いです。

私が言及していないこと、そして非常に重要なことは、これのデバッグ可能性です。
これがスタックトレースを壊さないことを願っています。 pdbファイルまたはある種のデバッグシンボルを含めることができるようにしたいと思います。

圧縮については、ほとんどの場合、実際の配信メカニズムがすでに圧縮されていることを考慮に入れてください。
たとえば、nugetパッケージ。
ユーザーは解凍することにもかなり精通しているので、それはそれほど問題ではありません。
サイドで圧縮できると思います。

ありがとう、@ ayende！ あなたは私がデバッグ可能性を呼び出すべきだったということは正しいです。 デバッグに影響を与える可能性のあるマイナーな方法はごくわずかだと思います。

1. 単一のファイルで編集と続行を使用できない場合があります（元のアセンブリを再構築して再ロードする方法が必要なため）
2. 単一ファイルビルドでは、アセンブリに付属しているファイル以外のデバッグに必要なPDBまたはその他のファイルが生成される場合があります。
3. CoreRTを使用する場合、（特にLinux / Macで）時間の経過とともに入力されるデバッグ機能がいくつかある場合があります。

「pdbファイルを含める」と言うとき、単一ファイルのビルドをデバッグする必要がある場合に備えて、それらを単一ファイルの_内部_に生成する機能、またはそれらを生成してハングアップする機能が必要ですか？

1）私たちにとって問題ではありません。 E＆Cは、日常の展開ではなく実際の展開にのみ使用される可能性が高いため、ここでは関係ありません。
2）理想的には、1つのファイルと側面のpdbのセットではなく、PDBを含むすべてのファイルに対して単一のファイルがあります。 すでに埋め込まれたPDBオプションがあります。それが機能するのであれば、それは素晴らしいことです。
3）デバッグについて話すとき、私はデバッガーをライブで接続するのではなく、実稼働時間について話します。 具体的には、ファイル番号や行番号などのスタックトレース情報、ダンプの読み取り時にシンボルを解決できることなどです。

1. 主にサービスですが、一部のUI
2. 一部の人はそうしますが、これは緊急ではありません
3. はい
4. はい
5. 数秒で大丈夫です
6. 私たちには関係ありません。 dllサイズの合計は問題ありません
7. 理想的には
8. サイズは私たちにとって最も重要ではありません

私たちにとってのもう1つの質問は、個々のコンポーネントに対してもこれを実行できるかどうかです（おそらくステージングされている場合もあります）。 たとえば、多くの依存関係を使用するライブラリ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をロードしますか？」）-ユースについて詳しく教えてください場合？

単一ファイル配布の主なセールスポイントは、配布するファイルが1つしかないことです。 アプリのプラグインが別々のファイルにある場合、とにかく複数のファイルがある単一のファイル配布からどのような価値が得られますか？ 「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は、通常、ユーザー自身が定義する方がはるかに簡単です。

このシナリオでは、ユーザーによる特定の拡張機能を許可するため、通常は1つのexeのみをデプロイし、ユーザーは必要に応じて機能を追加できます。

それを行うことはそれほど多くはありませんが、必要が生じた場合はそれを実行できるようにしたいと考えています。

@ayende同意しました、私たちと同じです。

また、これをdllレベルで実行できる場合は、依存関係をアセンブリ内にパッケージ化して、クライアントアセンブリと競合しないようにすることができます。 つまり、NewtonSoft.Jsonのバージョンを選択することで、現在、同じフォルダー内のすべてのプログラム、プラグイン、およびサードパーティアセンブリに対して定義していますが、それを埋め込むことができれば、サードパーティには柔軟性があり、バージョンの互換性が向上します。

@ayendeに同意します。

みなさん、ありがとうございました！ ネイティブコードを使用するか、プラグインをロードする必要がある人の数に基づいて、私たちが管理できる最も互換性のあるアプローチは、開始するのに適切な場所であると考えています。 そのために、「パックアンドエクストラクト」アプローチを採用します。

これは、基本的にすべてのアプリケーションと.NETのファイルをリソースとしてエクストラクタ実行可能ファイルに埋め込むツールになります。 実行可能ファイルが実行されると、それらのファイルがすべて一時ディレクトリに抽出され、アプリが非単一ファイルアプリケーションとして公開されたかのように実行されます。 圧縮から始まるわけではありませんが、必要に応じて将来追加する可能性があります。

この計画の最も難しい詳細は、ファイルをどこに抽出するかです。 いくつかのシナリオを説明する必要があります。

• 最初の起動-アプリはディスク上のどこかに抽出する必要があります
• 後続の起動-起動ごとに抽出のコスト（おそらく数秒）を支払うことを避けるために、抽出場所を決定論的にし、2回目の起動で最初の起動で抽出されたファイルを使用できるようにすることが望ましいでしょう。
• アップグレード-アプリケーションの新しいバージョンが起動された場合、古いバージョンで抽出されたファイルを使用しないでください。 （逆もまた真です。人々は複数のバージョンを並べて実行したいと思うかもしれません）。 これは、決定論的なパスがアプリケーションのコンテンツに基づく必要があることを示唆しています。
• アンインストール-ユーザーは、必要に応じて、抽出されたディレクトリを見つけて削除できるはずです。
• フォールトトレランス-コンテンツを部分的に抽出した後に最初の起動が失敗した場合、2回目の起動で抽出をやり直す必要があります
• 昇格されたプロセスの実行-管理者として実行されるプロセスは、整合性の低いプロセスが改ざんされるのを防ぐために、管理者が書き込み可能な場所からのみ実行する必要があります。
• 昇格されていない実行-管理者権限なしで実行されるプロセスは、ユーザーが書き込み可能な場所から実行する必要があります

以下を組み込んだパスを構築することで、これらすべてを説明できると思います。

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は取得されません。
ディスク容量が問題になる可能性があります。また、アクセスポリシーなどによるランダムなファイルロックも問題になる可能性があります。
この機能を使用したいのですが、以前は検出できなかった多数のフェイルモードが追加された場合は使用しません。

@Kosyneに同意-提案された初期ソリューションは、ある種の「インストーラー」を単純に自動化するようです。 それが私たちが1人の幹部で解決しようとしている問題の限界だったとしたら、私たちは皆、その自動化を自分たちで実行しただけだと思います。

単一のexec提案の主な目標は、管理されていないシステムで実行可能ファイルを実行できるようにすることです。 選択した宛先の「インストール」ディレクトリへの書き込みアクセス権さえあるかどうかは誰にもわかりません。 起動後も（デフォルトではなく）それ自体のアーティファクトを残してはなりません。

上記を満たすための既存の提案への小さな変更として：メモリに解凍してそこから実行できませんか？

残りのコメントに同意します。 別の場所への解凍は、_すでに_利用可能です。
抽出された値をかなり簡単に実行する自己解凍型zipを作成できます。 これは、これが答えることを意図しており、インストールの単なる別名であるという多くの懸念に答えるものではありません。

ファイルの場所は重要です。 たとえば、私たちの場合、それは次のことを意味します。

• 構成ファイルの検索（存在しない場合はオンザフライで生成し、ユーザーがカスタマイズできるようにします）
• データファイルの検索/作成。これは通常、ソースexeに関連しています。
• 適切な監視/サポートを確実にするために、プロセスのPID/名前は一致する必要があります。

ユーザーの1人は、実際にはHDを実行できないシステムで、DVDからソフトウェアを実行する必要があります。これはどのように機能しますか。

私は、すべてをメモリ内で実行する方がよいことに同意します。 そして、起動時間についての懸念はそれほど大きくありません。再起動するたびにこれを支払うか、必要に応じて手動でそれを軽減するための手順を実行することで問題ありません。

ここでのもう1つの問題は、実際のサイズです。 これが単なる（事実上）インストーラーである場合、それは、数百MBの妥当なアプリのファイルサイズについて話していることを意味します。

提案されたソリューションを構築するために、CLRを変更する必要はないようです（あるとしても）。 ユーザーはすでにそのようなソリューションを構築できます。 これをCoreCLRに追加しても意味がありません。 特に、このユースケースはかなり狭く具体的であるためです。

@GSPPこれは基本的に、今日7z-Extraでできることのようです。この場合は、まったく持っていない方がよいことに同意します。

申し訳ありませんが、このパーティーに遅れました。追跡していた重複チケットに投稿されたリンクをたどった後、ここに到着しました。
ここで最新のコメントを読んだ後、パッキングと抽出を検討していることをお詫び申し上げます。 これはやり過ぎのようですが、基本的なコンソールアプリにSFAを展開する機能から始めてみませんか？ いくつかのネットワーク、IO、および単一のファイルにあるいくつかの外部依存関係（nugetなど）を使用して、基本的なコンソールアプリを作成できるはずです。
私が言おうとしているのは、すべての人の要件を収集するのではなく、誰の要件​​も収集せず、代わりに、すべての人にとって意味があり、結果がすぐに得られる最初の反復から始めます。

これは基本的に私が7z-Extraで今日できることのようです

この問題に対処するためのプログラミング環境にとらわれないソリューションが今日存在しているのは正しいことです。 多くのうちの別の例： https ：//www.boxedapp.com/exe_bundle.html

ここでの付加価値は、ドットネットツールへの統合であり、専門家でないユーザーでも簡単に実行できます。 あなたが指摘したように、エキスパートユーザーは既存のツールをつなぎ合わせることで今日これを行うことができます。

個人的には、ここで正しい選択をしていることが明確ではないことに同意します。 これについては、コアチーム内で多くの議論がありました。

インターンを配置してグローバルツール（推奨されていますが、サポートされていません）を使用することも同様に機能し、インストールもかなり簡単です。

事実上、私たちはdotnet publish-single-fileについて話していて、それは舞台裏で必要なすべてを行うでしょう。

このシナリオをサポートするためにフレームワークまたはランタイムに実際に必要なものは何もありません。これをフレームワークの外部に明示的に作成することで、ユーザーがこれを変更する方法についてより多くの自由を得ることができます。
フレームワークに変更を加えたい場合に取得するPR（関連するすべてのセレモニー、後方コンパクト、セキュリティなど）を取得する「必要」はありません。
一般的な副業プロジェクトをフォークして使用するだけです。

この機能が欲しいのと同じくらい、外部からも同じように実行できるもの（つまり、常に入力されることを意味します）を入れたくないことに注意してください。

より高いレベルの質問をしたいのですが、単一ファイルの配布を希望する顧客の主な動機は何ですか？
それは主に：

1. 包装？ もしそうなら、ソリューションが受信トレイであるかサードパーティのツールであるかに関係なく、どの特性が最も重要ですか？
   a）起動時間（最初の実行を超えて）
   b）書き込み不可能な環境で実行する機能
   c）実行後にファイルを残さない
   d）インストーラーを実行する必要はありません
   2）パフォーマンス？
   a）速度（ネイティブコードの静的リンク、複数のライブラリのロードの回避、モジュール間の最適化など）
   b）コードサイズ（証明書が1つだけ必要、ツリーの揺れなど）
   3）他に何かありますか？

この機能がそれほど重要ではない、または少なくともここのコア機能セットに含めるのは良い目標ではないかもしれないと一部の人に読まれているのではないかと少し心配しています。 繰り返しになりますが、大規模なアプリケーションのサービスまたはサブモジュールとして機能するアプリケーションにとっては、非常に強力であると思います。 作者であるあなたが開発者でさえないかもしれません。 インストール（自動またはその他）でのみ解決できる依存関係の要件や、ユーザーによる追加のセキュリティ強化が必要になる可能性のあるディスク上の実行後のアーティファクトなどを渡す必要はありません。
今のところ、.NETはこのニッチな問題には適していません。 しかし、それは可能性があります（そしてIMOでなければなりません）。

コンパイルされた実行可能ファイルは次の条件を満たしている必要があります。

• 関連するすべての依存関係をパッケージ化します
• 実行アーティファクトがない（ディスク書き込みがない）

Re @ swaroop-sridhar私はあえて、すべてのアプリケーションに独自のパフォーマンスニーズの順序があると思います。したがって、コアソリューションに取り組んだ後の最善のアプローチは、ぶら下がっている果物を選び、そこから進むことだと思います。

@ swaroop-sridhar私にとって、これはエンドユーザーにとってのパッケージングと使いやすさに関するものです。
システム全体のインストールを処理する必要はありません。クリックして実行するだけです。

ソフトウェアを埋め込むことができ、単一のファイルアドオンの方がはるかに管理しやすいため、これは重要です。

@strich埋め込みについてのポイントは良いものです。 私たちは一般的にマイクロサービスアーキテクチャのコンポーネントとして使用されており、デプロイのオーバーヘッドを減らすことでそれが容易になります。

問題は何でもないか、これが重要な機能であるかどうかです。 問題は、提案されたソリューション（基本的にはこの時点で物事を圧縮する）が_コア内_にある必要があるものです。
コアにあるものは、変更の基準がはるかに高くなっています。 これを外部ツールとして使用すると、変更や拡張が簡単になるため、より適切になります。

正直に言うと、私はむしろもっと良い選択肢を見たいと思っています。 たとえば、ファイルの代わりにメモリからdllをロードすることが可能です（いくつかの作業が必要ですが、可能です）。
その場合は、純粋なメモリに対してアンパックを実行し、ディスクにヒットすることなく、純粋にメモリから_全体_を実行できます。

これを有効にするには、ランタイムを変更する必要がある可能性が非常に高いため、これはコアに組み込まれるべきものです。
そして、それ自体が内外で価値があるでしょう。 そして、私たちが現在できることではありません。

したがって、良い例は、Hashicorpの領事のようなGoツールの経験を調べることです。 実行中の任意のマシンにドロップできる単一のexeファイル。 インストーラーも、フォルダーのコピーも、何百ものファイルのリストにある構成ファイルの検索も、本当に素晴らしいエンドユーザーエクスペリエンスです。

私たちにとって、インメモリアプローチが機能するかどうかはわかりません。これは、プラグインdllでも機能するようにするためです（したがって、プラグインを削除すると、すべての依存関係ではなく単一のファイルになります）。良い。 Fody.Costuraを調べましたが、これはいくつかの問題でうまく機能しますが、.NETCoreで問題が発生しました。

したがって、良い例は、Hashicorpの領事のようなGoツールの経験を調べることです。

ええと、領事のようなツールの場合、理想的な解決策は、この自己解凍型の即興ではなく、corertです。

@mikednなんで？ AOTまたはJITのコンパイルが展開方法と何の関係があるのか​​わかりませんか？

@strichの言葉を2番目に言いたいのですが、単一ファイルのデプロイは、マイクロサービスアーキテクチャのデプロイだけでなく、コマンドラインを備えた小さなツールである（または少なくともその寿命を開始する）コンソールアプリにとっても新鮮な空気の息吹になります。スイッチ。

なんで？ AOTまたはJITのコンパイルが展開方法と何の関係があるのか​​わかりませんか？

それはあなたが望むものを正確に提供するので-あなたがどんなマシン（まあ、適切なOSを持っているどんなマシンでも、結局のところネイティブファイルです）にドロップして実行できる単一のexeファイル。 また、リソースの使用量が少なくなる傾向があります。これは、領事館などのエージェントにとっては良いことです。 これは、自己解凍型ソリューションというよりも、Goが提供するものとほぼ同等です。

@mikedn推測しますが、

1）それは（私が知る限り）生産形態ではまだ実際には存在していません！
2）多くの動的機能（IL生成、任意の反射）を使用します
3）プラグインを追加できるようにしたい（ここでも理想的には圧縮されている）

この問題は人々に何が欲しいかを尋ねることに関するものだったので、私たちは私たちの意見を述べているだけです！ このメリットを得るためだけに、別のランタイムモデルに切り替える必要はありません。 私にとって、彼らは直交する懸念です

AOTまたはJITのコンパイルが展開方法と何の関係があるのか​​わかりませんか？

JITがなければ、デバッグストーリーのようなものを十分にうまく取得するのは簡単です。 JITの部分は問題を難しくします。そのため、Goでは問題を見つけることができません。 これはエンジニアリングであるため、より困難な問題に多くのエンジニアを投入して新しい複雑さに耐えるか、他の場所にスコープを絞ることができます。 必要なスキルを持つエンジニアの数が限られているため、自己解凍型ファイルはそれを調査します。

Goプロジェクト（JIT要件なし）に似たプロジェクトを持っている人は、「実験的」ラベルが付いていれば、CoreRTにかなり満足しているかもしれません。 最近は簡単に試すことができます。 完全なCoreCLRと同じガベージコレクター、コードジェネレーター、CoreFX、およびほとんどのCoreLibを使用し、自己完結型の小さな実行可能ファイル（1桁のメガバイト）を生成します。

それは（私が知る限り）生産形態ではまだ実際には存在していません！

はい、私のコメントは主にMSの人々を対象としていました：笑顔：。 彼らはこれらすべての並行した、関連した、進行中のプロジェクト/アイデア（corert、illinker）を持っており、今ではもう1つ追加しています。これは、多くの人がすでに指摘しているように、「まあ、私たちはそれを行うことができます私たち自身」のようなもの。 また、ファイルを「隠し」ディレクトリに抽出するなどの欠点もあります。

多くの動的機能（IL生成、任意の反射）を使用します

それは、コミュニティ全体が考え直したいと思うかもしれないことです。 確かにそれができるのは便利ですが、単一ファイルの展開のような他の欲求とは一種の矛盾があります。 それでも単一ファイルのデプロイメントを取得できますが、それはコストがかかる傾向があります-かなり大きなファイルです。 あなたがそれで大丈夫なら、それは完全に問題ありません。 しかし、私の経験では、ファイルが大きいほど、「単一ファイル」の側面の有用性は低くなります。

@MichalStrehovsky確かに、さまざまなオプションがあります。 ただし、私たちにとっては実験的なものを使用することはできず（.NET Coreに移行する時期が十分に困難であると確信して）、一時フォルダーへの抽出もこの場合は機能しないと思います。 ただし、最悪の場合は、そのまま続行し、この機能を使用しません。

それが私たちが望むように進んだら、それは私たちが望むものです:)

@mikedn同意します。 複数の並列ソリューションはさらに混乱を招きます。 私たちの理想的な解決策は、ある種のスーパーILLinker /ウィーバーアプローチだと思いますが、これを実行して、最終的にどこに到達するかを確認できてうれしいです。

私はこの機能の着陸に本当に興奮していますが、TBH@morganbrに投稿した最初の提案についても同様に興奮していません。 あなたが提起した質問のリストに対する私の答えは、他の人が投稿したものと似ています（したがって、共通の望ましい機能のセットがあると思います）が、IMHOが提案した「ディスクに解凍」ソリューションは、私が望んでいるものではありません実装され、他の人が言ったように、「病気」よりもほとんど悪いでしょう。 @jkotas

@strichと@ayendeに同意します
コンパイルされた実行可能ファイルは次の条件を満たしている必要があります。
関連するすべての依存関係をパッケージ化します
実行アーティファクトがない（ディスク書き込みがない）

ディスクではなくメモリから.dllをロードするのは簡単ではないかもしれませんが、それはIMOがMSFT低レベル開発者の深い専門知識に値する種類の機能です（そしてCoreClrで活用します）。外部ツール（すでにあります。https：//github.com/dgiagio/warpを参照してください）。 これが達成された場合、最初の実行と後続の実行の間にどのくらいの時間差があるのだろうか？ インスピレーション/例として、Linux3.17以降にはdlopenで使用できるmemfd_createがあると思います。

別のトピックでは、プラグインをサポートするための要件が​​設計提案のインデックスを過剰に作成しているのではないかと思いますか？ この機能をオプトインする価値があるので、この機能を必要とする人だけが潜在的なペナルティ（木の揺れの欠如など）を被り、他のすべての人（大多数？）は展開可能なサイズの縮小、パフォーマンスの利点を得ることができます（？）

@ swaroop- sridhar @MichalStrehovskyに戻ると、異なる可能性のある2つの幅広いユースケースを見ることができます。1つのソリューションですべての人に対応するのを困難にするのに十分な目標/要望です。

• CLIツールは、理想的には、毎回高速で実行され、小さな配布が可能であることを望んでいます。 たぶんCoreRTに適していますか？
• マイクロサービスは、JITや動的コード機能などのより豊富な機能と引き換えに、より長い初回実行（理想的には1秒未満）、より大きな配布可能性をおそらく許容できます。

このブレインダンプがある程度意味があることを願っています。私は急いでいるつもりはありませんが、このトピックに非常に興味があるので、フィードバックを提供するだけです。 大変な努力をしていただき、コミュニティからの意見を募っていただきありがとうございます。 :)

プラグインについて。
基本的に、私が望むのは、 Assembly.LoadFromまたはLoadLibraryの呼び出しでブロックされないことだけです。
私は他に何も必要とせず、残りは自分で行うことができます。

@ayende 「LoadFromなどでブロックされる」とはどういう意味ですか？

たとえば、これに関する提案の一部にはCoreRTが含まれていました。これは、（おそらく）マネージDLLをロードすることはできないことを意味します。
ただし、マネージdllへのパスを指定してアセンブリを取得するか、ネイティブdllでLoadLibraryを呼び出すことができる限り、これがプラグインメカニズムで問題ありません。

プラグインシナリオは_考慮すべき_ものではなく、_ブロックされるべきではないものであることを明確にするためにこれを言っています。

私はコードを掘り下げるのに少し時間を費やしましたが、一見すると、それは_可能_であるはずです（Windowsについて話すのは物事を単純にするためだけです）：

• CoreCLR全体をexecにパックします（たとえば、組み込みリソースなどとして）。
• ネイティブdllを列挙し、 MemoryModule （https://github.com/fancycode/MemoryModule）のようなものを呼び出して、それらをメモリにロードします
• ランタイムを呼び出し、メモリからアセンブリをロードします。

これはそれほど単純ではないと思います。 たとえば、 ICLRRuntimeHost2::ExecuteAssemblyはバッファを提供する方法を提供せず、ディスク上のファイルのみを提供します。
それはそれを実際にそれを機能させるための最初の（私が確信しているものの）ショーストッパーにします。

関連するものを失敗する可能性のあるファイルとして参照する可能性のあるコードはたくさんあると確信していますが、これは、単一のファイルexecが必要であると言ったときに意味することであり、なぜそのようなものであるかソリューションは、外部ではなくCoreCLRで実行する必要があります（zipの例のように）。

MemoryModuleのようなものを呼び出す

MemoryModuleを使用してロードされたバイナリは診断できず（たとえば、通常のデバッガやプロファイラなどは動作しません）、MemoryModuleはすべての組み込みOSセキュリティ対策（たとえば、アンチウイルスなど）をスキップします。 これは、サポートされているソリューションとして出荷できるものではありません。

これはそれほど単純ではないと思います。

そうです、拡張されていない単一のファイルバンドルからの実行をサポートするには、新しいAPI（マネージドとアンマネージドの両方）が必要になります。 既存のプログラムとライブラリは「正しく機能」しません。

マルウェア対策スキャンインターフェイスを合理的に要求することはできますか
最近のように、WindowsエンジニアによってMemoryModuleに実装されました
memからロードされたものを含むすべての.netアセンブリ？

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

編集：うーんMemoryModuleはネイティブモジュールをロードするためにOSに組み込まれているもののように聞こえましたが、明らかにそうではありません、それはおそらく上記の私の提案を無視するのに十分な理由です

2018年12月5日水曜日、01：46 [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の優れたランタイムに固執し、ネイティブコードをビルドしたまま、完全なフレームワーク機能が必要な人のために、JITをCoreRTに組み込む（そしてインタープリターの作業を準備が整うまで拡張する）ことに集中してみませんか？ JIT機能が必要な場合、メタデータとJITをCoreRTのネイティブにコンパイルされた実行可能ファイル内に保持することは可能ではないでしょうか。
これはすべての世界で最高ではないでしょうか？ 例えば。 実行可能ファイルが最小で、起動時間が最も短い場合、CoreRTのAOTコードの制限は、JITを配置し、完全なフレームワーク機能を保持したい人のためにメタデータとILコードを保持することで拡張できます。
IMOは、長期的な目標の妨げとなる可能性のある短期的な機能ではなく、「可能な限り最良の」ソリューションに焦点を当てる必要があります。

私は間違っているかもしれませんが、CoreCLRの一部として単一のファイルを公開することで、顧客をCoreRTからさらに遠ざけることができ、多くの場合、顧客にとってより良いソリューションになる可能性があります。 例えば。 これが「.NETコードを単一のファイルとして公開できるようになりました」とブランド化されても、巨大なファイルを作成している場合、起動パフォーマンスが低下するなどの場合、この「肥大化した.NETランタイム」について人々が再び不満を言うのを見ることができます。 。 .NETには、実際にはCoreRTのまさにそのための優れたソリューションがすでにありますが、公式のサポート/公式の製品コミットメントはありません。

おそらく私の懸念は、ほとんどの場合、並列製品を減らし（@mikednを引用）、ここにある製品（ロードマップの共有を含む）に深くコミットし、拡張し、サポートすることに重点を置きたいということです。

並列性の低い製品

.NETCoreという1つの製品しかありません。 CoreRTは独立した製品ではなく、決してそうなることはありません。 これは、この1つの製品にオプションを追加することです。 現在のオプションの例をいくつか示します。ワークステーションGCとサーバーGC。 自己完結型のアプリ公開とフレームワーク依存のアプリ公開。

@jkotas私は理解しており、オプションを追加することは通常素晴らしいことに完全に同意します。 「製品」という言葉の使用を「オプション/ソリューション」に置き換えた場合、.NET Core全体の製品内のオプション/ソリューションとしてのCoreRTに対する当社の製品の取り組みが、私たちの製品であるかどうかが完全にはわからないという懸念があります。今後何年にもわたってサポートされることに安全に賭けることができます。 APIが時間の経過とともに予測できない重大な変更を行い、APIがそこにとどまることができるかどうかわからないまま、突然非推奨になるとしたらどうなるか想像してみてください。 MS以外のエンティティにとって、製品の一部であるツール/オプションは同じように感じます。 CoreCLRでは（少なくとも現在は）実行できないCoreRTのいくつかの機能に依存しています（そのうちの1つは、実行可能ファイルをPACEで保護し、大量のメタデータ、ILなどを削除する機能です。簡単な静的リンク、基盤となるプラットフォームの理解のしやすさ、難読化をコンパイラーに直接組み込む可能性など）。 基本的に、CoreRTでのあなたやMichalや他の人の作業は、IMOが最初に設計されて以来、.NETエコシステムで起こった最高の出来事の1つであるため、優先されるべきだと思います。 新しいツール/オプションの話があるときはいつでも、CoreRTオプションの代わりに、CoreRTと競合していると内部的に見なすことができ、リソースの割り当てが間違っているように感じます。 申し訳ありませんが、議論を引きずり出すつもりはありませんでした。CoreRTの作業がどれほど高く評価されているか、そしてここにいる私たちの何人かはそれがプラットフォームの未来であるべきだと信じていることを確認したかっただけです。
この議論をこれ以上汚染することは控えます。 チームの皆様のご多幸をお祈りし、思いついたことを楽しみにしておりますので、きっと素晴らしいものになると思います。

@christianscheuerこの問題および他のCoreRT関連の問題に関するフィードバックは非常に貴重です。 あなたはこの議論をまったく汚していません。

CoreRTとの競争のように内部的に見ることができる新しいツール/オプションの話があります

コアチームの中で、私たちはいくつかの異なる、野心的な、またはクレイジーなオプションについて話し合っています。 「ディスクへの解凍」は、CoreRTフルAOTとの重要な競合相手ではないと思います。 それぞれが.NETユーザー/アプリの異なるセグメントを対象としています。

多くの異なるチャネル（githubの問題や対面の顧客との会話を含む）からのデータを編集する当社の製品管理チームは、ここで提案されているようなソリューションが最大の利益になることを示唆しました。 この権利に関するすべてのデータがあり、望ましい結果が得られることをまだ検証しています。

現時点で、CoreRT技術がサポートされている.NETCore製品の一部としていつ出荷されるかをお約束することはできません。 私はそれがユニークな強みを持っていることを知っています、そして私たちはそれから最終的に利益を得る重要な.NETユーザーのセグメントのためにそのようなサポートされたソリューションを出荷するつもりです。

単一ファイルの配布は、次の場合に意味があります。

• 起動時間には影響しません（それ以外の場合は、ごくわずかなアプリケーションのみが使用できます）
• これはVFS（仮想ファイルシステム）として機能します。アセンブリとリソースに、ディスクやアプリケーションフォルダーからのものであるかのようにアクセスできます。
• アプリの「パッチ適用性」には影響しません。 IE：Microsoftは、システムレベルで他の場所にオーバーライドを提供することにより、重要なアセンブリが埋め込まれている場合でも、パッチを適用できるはずです。

埋め込みリソースとしてのアセンブリを抽出して一時フォルダーにコピーすることは、Microsoftの必要なソリューションではありません。 それはそれを必要とするどんな顧客によっても簡単に実行することができます。

「真の」単一ファイルソリューションが必要であり、多くの価値を提供します。

@jkotasあなたのコメントは私に忠実です。 会社の.NET開発者（LOB /バックオフィス/統合）にCoreRTに切り替えるよう説得するのは難しいでしょう。なぜなら、彼らにとっては飛躍的すぎるからです（特に、実験的なラベルが与えられている場合）が、彼らはこのスレッドのようなCoreの比較的単純な（使用する）ソリューションが議論されています。 ありがとう

@ popcatalin81私は実際、ここでのあなたの意見に強く反対します。

多くのアプリケーションにとって、起動時間は意味がありません。 展開の運用上の複雑さを軽減する目的で、長時間実行されるサービスの起動時間の50％から100％の増加を喜んでトレードオフします。

サービスの起動時間に30秒を追加しても、長期的にはサービスにとって意味がありません。
ユーザー向けのアプリケーションの場合、これはキラーになる可能性がありますが、3.0がリリースされるまで、ほとんどすべてのCoreCLRアプリはコンソールまたはサービスのいずれかです。

CoreCLRには、フレームワークをアプリケーションにバンドルできるモード（自己完結型のデプロイメント）がすでにあるわけではありません。
私たちの場合（RavenDB）は、いくつかの目的のためにそれを_信頼_しています。 まず、ユーザーが使用しているものに関係なく、独自のフレームワークを選択する機能。 これは、グローバルにインストールされたフレームワークを使用する必要がなく、管理者がフレームワークであると決定したものに縛られないことを意味するため、これは私たちにとって_主要な_利点です（以前は実行することを考慮に入れていました） .NET 4.0は、たとえば4.5がリリースされてから数年経っても、それが苦痛だったことがあります）。
もう1つの重要な側面は、フレームワークの_独自の_フォークで実行できることです。 これは、変更しなければならないことに遭遇した場合に非常に役立ちます。

その一環として、私たちはパッチサイクルの所有権を取得し、他の誰かがそれをいじってほしくない。

私はVFSを_気にしない_が、これが必要になるとは思わない。 そして、私は専用のAPIを通過するか、いくつかのフープをジャンプして、この方法で生成されたアセンブリ/ネイティブdll/リソースに到達する必要があることで完全に問題ありません。

私は@briachtからこの問題を2日間指摘されたので、議論は本当に遅れています。
私の2セントを追加したいだけです！

最初に@morganbrの質問に対する私の答え：

1. Windowsアプリ、WPFとWinFormsの混合。
2. 現在、
3. はい、さまざまなバリエーションでAssembly.Loadを使用します
4. はい
5. これがすべての起動時に発生するペナルティであるかどうかによって異なります。 数ミリ秒の場合ははい、ただし5秒の場合：いいえ。 1回の場合は5秒で問題ありません。
6. 50MBは、2MB未満に比べてすでにかなり大きいです...しかし、これがdotnetランタイムが含まれていることを意味する場合は...OK。 たぶん私はダウンロードの有無にかかわらず提供することができます。
7. リリース時間は直接問題ではありませんが、長期間多くのCPUを使用してCIプロバイダーを混乱させることはありません。
8. はい！

私が話しているアプリケーションGreenshotは、現在リリースされているバージョンはまだ.NET Framework 2.0をターゲットにしていますが（実際にはそうです）、最新バージョンでは問題なく動作します（下位互換性は良好です）。 インストーラーを含むが.NETFrameworkを含まないZheのダウンロードは、約1.7MBです。 これが開始されるディレクトリには、1つの.exeと4つの.dllが含まれ、サブディレクトリには11のアドオンもあります。

私は以前のコメントを読んでいましたが、それらの多くは、インストーラーを使用する機能を備えたものが必要なようです。 現在、プラットフォームに依存しないソリューションがないため、これはある程度意味があります。

私は8月にマイクロソフトの何人かの人々と現在のトピックについて話し合っていました。私の主な焦点は、すべてをリンクして、展開するアプリケーションのサイズと複雑さを減らし、起動時に多くの時間を要するアセンブリの負荷を減らすことについて話していました。私のアプリケーションの。

.NET Framework4.7.1とdotnetcore3.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を使用して、ここで説明したことをほぼ実行していました。 ビルド中のパッキングと起動時のアンパック！ しかし、ハッキングによってファイルを抽出することなく、単一の実行可能ファイルを作成することもできました。 しかし、それはまたかなり多くの問題を引き起こしたので、これは私の好ましい解決策ではありません。

私は多かれ少なかれ標準的な解決策を望んでいます：それはちょうどうまくいく™
おそらく、標準のフォルダー構造を定義するのが理にかなっているので、実行可能ファイル、readme、ライセンスファイルなどをルートに配置し、ファイルごとに異なる「既知の」ディレクトリ（dotnetコア、依存関係など）を設定できます。 これにより、ツールの操作が簡単になり、誰もが使用したいものと使用しないものを決定できる機能が提供される可能性があります。 ディレクトリでzipを実行するだけでも、いくつかの問題が解決する場合があります。

Fody.Costuryに似たソリューションを使用することで、Greenshotの展開を簡素化するためにイメージングを使用できるようになることは間違いありませんが、サイズと読み込み時間を直接削減することはできません。 ですから、ここでも少し時間がかかることを願っています！

@ayende私もあなたに反対することを許可してください:)

これは真のサービスですが、Webアプリケーション、および一般にサーバーベースの長時間実行アプリは、1回限りの起動コストの影響を受けませんが、同時に、これらのアプリケーションは、単一ファイル配布モデルから最も多くのメリットを享受できるものではありません。 （レイヴンは例外であり、標準ではありません;））

私の見解では、単一ファイルの配布は、主にユーザーを対象としたアプリケーションとユーティリティを対象としています。 そのようなアプリケーションをダウンロード、コピー、実行するユーザー。 そして近い将来、.Net Core 3.0がUIライブラリのサポートを提供するとき、この配布モデルは非常に一般的になります。 ただし、このモデルはどのアプリにも適していないことを強調する必要があります。 主要なアプリは引き続きインストーラーを使用します。

ここで問題となるのは、一時フォルダにコピーされた組み込みアセンブリのこのモデルは、非常に人気が出た場合にうまく機能するでしょうか？

私の見解では、これらは現在のモデルのいくつかの潜在的な問題です。

• 数十のアプリが、アセンブリが複製された数千の一時ファイルを作成します。 ここで混乱を引き起こす可能性があります。 （ユーザーには気づかれませんが、それでも混乱します）
• 圧縮もリンカーもありません。 これは、FDDやイベントの圧縮と比較して、小さなユーティリティアプリに不利になる可能性があります。
• サーバーの展開を簡単にするのではなく、実際に妨げる可能性があります。その理由は、トークンの置換を使用した展開後の構成です。 （構成ファイルを上書きするための一時フォルダーはどこにありますか？サービスに独自のフォルダーへの書き込みアクセスを許可して、そこに構成ファイルを作成しますか？これはセキュリティです。

このモデルがすべての種類のアプリに最適ではないと言っているわけではありません。 私はこれを正常に実装し、過去にfull.Net Frameworkで自分で使用しましたが、特定のアプリに適しています。

最適な実装は、リンカーがすべてのアセンブリを1つのファイルにマージするバージョンだと思います。

@popcatalin81単一の視点を持つ世界は貧弱なものです。 そして、私は自分のデプロイメントモデルが唯一のものであると考えるほど傲慢ではありません。

私が念頭に置いているのは、ダウンロードとダブルクリックのシナリオです。
今のところ、何百ものファイルがあるディレクトリに移動して適切なファイルを見つけるのは面倒なので、実行するにはシェルスクリプトを解凍してクリックする必要があります。

一時ファイルの構成について。 私はそれに非常に反対します。 構成ファイルは、他のユーザーに表示されるものであり、使用されている実際のファイルのすぐ隣に存在する必要があり、どこかに隠されていません。
ユーザーが必要なときにIsolatedStorageファイルがどれほど悪いかはすでに見てきました。

以前のバージョンのRavenDBでは、ディレクトリレイアウトを簡素化し、表示されるファイルの数を減らすために多くのものを統合しました。これは、ソフトウェアの使いやすさに深刻な影響を及ぼしました。

この機能はILMergeを使用しますか？ そうでない場合は、なぜですか？ 落とし穴があれば自分自身を教育したいと思います。

私は提案された「パックアンドエクストラクト」アプローチ、特にディスク上のファイルを抽出する場合は好きではありません。 シンプルですが、問題が多すぎます。 ディスクに抽出せずに、すべて「メモリ内」から動作するはずです。

corertネイティブコンパイラやCostura.Fodyのようなものでなければならないと思います。

オプションで、バイナリサイズの削減も試みる必要があります（未使用の参照を削除し、ILを無効にします）。

再

dotnet core 3.0が登場する前の数か月間、私はFody.Costuraを使用して、ここで説明したことをほぼ実行していました。 ビルド中のパッキングと起動時のアンパック！

costuraは（デフォルトでは）「ディスクに解凍」しないことに注意してください。 リソースから組み込みアセンブリを（メモリ内で）抽出し、バイト経由でロードします

コンテキスト@SimonCroppに感謝します。ディスクへの解凍と、ストリームからの読み込みの両方のオプションを検討しています。 純粋なILのストリームからのロードをカバーすることは、最初の反復で可能かもしれません。

@jeffschwMSFTところで、シームレスにマージするアセンブリ（およびオプションのツリーシェイク）の機能セットは、私が一級市民として見たいものです。 コスチュラは私の最も人気のあるプロジェクトの1つですが、サポートにかなりの時間がかかるプロジェクトでもあります。 したがって、MSが代替案を発表した場合（ベータ版であっても）、私に知らせてください。しばらく時間をかけてレビューし、costuraのreadmeとnugetの説明に「MSの代替案があります」を追加します。

可能性は低いですが、diffライセンスの下でcosturaのコードをリリースする必要がある場合は、お知らせください。

モノラル/イリンカーを.NETCoreツールチェーンに統合し始めた@SimonCroppに感謝します。レビューの申し出について、あなたを取り上げます。

costuraは（デフォルトでは）「ディスクに解凍」しないことに注意してください。 リソースから組み込みアセンブリを（メモリ内で）抽出し、バイト経由でロードします

さらに良いことに、 AppDomain.AssemblyResolveイベントを使用してオンデマンドでロードされると思います。したがって、必要なときにアセンブリを（メモリに）ロードするだけなので、スタートアップに大きな影響を与えることはありません。

ここでの会話に遅れました。 これがすでにカバーされている場合はお詫びします。

ここでのアーティファクトは決定論的であると想定できますか？ したがって、同じビルドは常に同じバイナリを生成しますか？ バイト単位。 正規の付随するチェックサムを使用してバイナリを配布できることも役立ちます。

@morganbrここにはたくさんの読み物が必要です。 これまでに行われた決定をログに記録することは可能でしょうか？

@edblackburnフィードバックに基づいて更新されたデザインをまとめています。 @swaroop-sridharが現在設計を推進しています。

この機能はILMergeを使用しますか？ そうでない場合は、なぜですか？ 落とし穴があれば自分自身を教育したいと思います。

@simplejackcoder ILMergeは、多くのアセンブリのILを1つに結合しますが、その過程で、マージされたアセンブリの元のIDが失われます。 そのため、元のアセンブリ名に基づくリフレクションの使用などは失敗します。

この取り組みの目的は、アセンブリをマージすることではなく、アセンブリのIDを維持しながらアセンブリをパッケージ化することです。 さらに、アセンブリだけでなく、ネイティブバイナリ、構成ファイル、場合によってはランタイム、およびアプリに必要なその他の依存関係もパッケージ化する必要があります。

ILのマージは、ILに適応できるアプリにとって便利な機能であり、この問題とはまったく異なる機能です。

デザインレビューはhttps://github.com/dotnet/designs/pull/52に投稿されています
今後もPRの議論を続けていきましょう。

単一ファイルを使用したい人のためにいくつか質問があります。 あなたの答えは私たちの選択肢を絞り込むのに役立ちます：

1. どのようなアプリで使用する可能性がありますか？ （たとえば、Windows上のWPF？Linux Dockerコンテナー内のASP.NET？他に何か？）
2. アプリに（.NET以外の）C ++ /ネイティブコードが含まれていますか？
3. アプリは、アプリのビルドに元々含まれていなかったプラグインやその他の外部dllをロードしますか？
4. アプリを再構築して再配布し、セキュリティ修正を組み込むことをいとわないですか？
5. アプリの起動が200〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？
6. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？
7. サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？
8. アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

1. dotnet / coreclr＃1のユースケースは、ユーティリティであるコンソールアプリです。 WindowsまたはLinuxの公開を行い、 --single-fileを指定して1つの実行可能ファイルを取得します。 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〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？
6. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？
7. サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？
8. アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

1. WPF.Core3.0アプリ
2. 多分nugetパッケージで
3. 番号
4. はい
5. はい、最大200〜500ミリ秒
6. 元の公開フォルダーのサイズの2倍または3倍にならなければ、重要ではありません
7. それは生産のためなので、それほど重要ではありません
8. はい。ただし、そうしない可能性があります。これは、作業がサードパーティのライブラリに関係している場合に役立つ可能性があります。

あなたが受け取ったフィードバックは、主に2019年以前の開発に関するものでした。これは通常、バックグラウンドで起動されるWebサービス、コンソールアプリケーション、およびその他のサービスです。 しかし、.netコア3.0では、WPFおよびUIアプリのソリューションが必要です。 .NetFramework4.8は.NetStandard2.1をサポートしません。アプリを.netフレームワーク（デッドフレームワーク）から.netコアにアップグレードする必要があるため、これまでWPFアプリケーションに使用していたILMergeを置き換えるソリューションが必要です。

この種のプログラムについて以前に他のコメントで説明されたように、自己解凍型パッケージは明らかに良い解決策ではありません。

1. 主にCLIアプリ。 小さなWindowsサービスと時折のWPFアプリも興味深いものです。 Webの場合、単一ファイルの配布は基本的に無関係のようです。 このため、残りの部分はほとんどWindows指向です。 Linux .NET Coreの関心は、Web関連のものです。
2. ときどき。 その場合、ほとんどの場合、圧縮ライブラリ用です。 ネイティブのものが詰め込まれていなければ、それは世界の終わりではないでしょう。 個別のdllとしてネイティブ依存関係をデプロイする必要がある純粋なマネージドのものに適したソリューションは、依然として価値があります。
3. いいえ、単一のファイルを気にする場合はそうではありません。
4. はい。
5. CLIを起動するのが面倒になる前に、200ミリ秒がおおよその制限です。 > 1秒で、ほぼ確実に.NET Framework（ILMerge + ngen）に固執するか、必要なランタイムが静的にリンクされたネイティブバイナリにコンパイルされる他の言語を調べます。多くの場合、コンパイルされたngen-edC＃アプリは実際にはかなり速く起動するため、C＃で実装されました。 このようなもののいくつかは、複雑さの点で、スクリプト言語で実装するのに合理的ですが、特に多数のモジュールを取り込む必要がある場合は、かなりの起動コストがかかる傾向があります。
6. 依存します。 Hello Worldで10MBを超えると、売り込みが難しくなります。 また、実行可能ファイルは、起動コストが大きくなる傾向があります。 理論的には、OSがすべてを読み取らずに実行を開始できる場合でも、少なくともWindowsでは、セキュリティを重視した目的で最初にハッシュを取得したいものがほとんどの場合あります。 そういえば、これは一時的なものにバイナリの束を開梱し、他に何もないとしても必死にスキャンするリソース使用率の観点から、AV（ディフェンダーは絶対に含まれています）のナットを駆動します。
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コア3の合理化された方法でmsbuild /dotnetCLIに統合する作業が進行中です。これは行われ、これらのツールの使用は簡単に実行できます（例：特定のmsbuildプロパティの設定）。

これらのツールはすべて、トレードオフがあります。 たとえば、crossgenは事前にネイティブコードを生成するため、起動に役立ちますが、バイナリのサイズが大きくなる傾向があります。 単一ファイルオプションを使用すると、アプリを単一ファイルに公開できますが、ネイティブバイナリがディスクに流出するなどの理由で、起動が遅くなる可能性があります。

@ swaroop-sridhar、返信に時間を割いていただきありがとうございます。

このソリューションがあなたのために機能しないと思うかどうかを明確にしたかった

自己完結型のものについてはまだ抽出が行われているように見え、crossgen（または起動時のJIT時間で削減するもの）のステータスは私にはわかりませんでした。 現在のデザインがそれにリンクしているステージングドキュメントを読んで、これを私たちにとってより面白くするもののように見えました。 それを考えると、私は、今後しばらくの間、これらのニッチに.NETFrameworkを使用することに固執し続けるだろうと考えていました。 誤解したかもしれません。

これらのツールはすべて、トレードオフがあります。 たとえば、crossgenは事前にネイティブコードを生成するため、起動に役立ちますが、バイナリのサイズが大きくなる傾向があります。

うん、これらのいくつかは両刃の剣であることを理解した。 JITが従来から機能してきた方法で、ngenは常にCLI/GUIアプリの勝利でした。 階層化されたコンパイルのいくつかの組み合わせと、ランタイム自体のロードが、同じボックスで実行されている他の多くの.NET Frameworkプロセスによって必ずしも償却されないという事実により、Coreでの明確なカットが少なくなる可能性があります。

@ swaroop-sridhar現在受け入れられている提案に関して私が抱えている大きな懸念は、このステップです

残りの216ファイルは起動時にディスクに抽出されます。

「HelloWorld」を実行するには216個のファイルが必要なようですが、それらをある場所のディスクに抽出すると、単純なコマンドラインアプリケーションを削除するのが難しくなります。 インストーラーを介して提供されなかったツールを削除する場合、完全に削除するために他のファイルを探す必要はありません。

私見ですが、golangと同様の公開エクスペリエンスをターゲットにする必要があります。 golangエクスペリエンスと完全に一致させるにはcrossgenを設定する必要がありますが（JITと階層型コンパイルに負けるため、1：1の一致は_良い_ものではないと主張することもできます）、それなしでかなりの部分を達成することができます。 私は何年にもわたって多くのツールを使用して同様のエクスペリエンスを実現してきましたが、最も効果的なのは、アセンブリローダーにフックが付いた組み込みリソースでした（ILMergeは厄介で、Costura.Fodyはまだ存在していませんでした）。 提案に記載されていることは、その機能を完全に複製することすらできません。 .NET Coreには非常に強力な未来がありますが、コマンドラインツールの開発に使用できるのは、数百の依存関係を持ち歩くか、手で波打つブートストラップコードを使用してディスク上のどこかに吐き出す必要がある限り制限されます。

私のdotnet/coreclr＃1のユースケースはコマンドラインユーティリティであり、1つのファイルであり、抽出は私の好みではありません。 しかし、コマンドの一部として選択肢を与えることは、オールインワンとオールインワンの自己解凍のどちらかを切り替えることを指摘しておきます。 自己解凍型の場合、解凍されたファイルをクリーンアップするundoを含める必要があります。 前者の場合、ユーティリティを削除するということは、一般的なユーティリティのフォルダに配置するのに適した1つのファイルを削除することを意味しますが、2番目の場合と同様に、クリーンアップを容易にし、回避するために、インストールには独自のフォルダが必要です。アンインストールによって共有ファイルが削除されるシナリオ。 いくつかの考え。 私が言ったように、1つのファイルユーティリティ（インストールは必要ありません）は、プロジェクトのユーティリティを（ツールスミスとして）頻繁に作成するため、私の主なユースケースです。 しかし、両方のシナリオのユースケースを見ることができます。 しかし、それらは異なります。

単一ファイルを使用したい人のためにいくつか質問があります。 あなたの答えは私たちの選択肢を絞り込むのに役立ちます：

1. どのようなアプリで使用する可能性がありますか？ （たとえば、Windows上のWPF？Linux Dockerコンテナー内のASP.NET？他に何か？）
2. アプリに（.NET以外の）C ++ /ネイティブコードが含まれていますか？
3. アプリは、アプリのビルドに元々含まれていなかったプラグインやその他の外部dllをロードしますか？
4. アプリを再構築して再配布し、セキュリティ修正を組み込むことをいとわないですか？
5. アプリの起動が200〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？
6. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？
7. サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？
8. アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

1. CLI（Windows、Linux、MacOS）、WPFおよびWinForms。
2. ときどき。
3. はい、何度も、プラグインがメインアプリケーションから共有ライブラリを再利用できるというシナリオに対処する必要があると思います！
4. はい。
5. 200〜500ミリ秒で大丈夫です！
6. 多くの依存関係のない単純なCLIアプリケーションの場合、10MBで十分です（圧縮されています）。
7. はい、間違いなく！ ビルド時間（特にリリースビルドの場合）は重要ではありません！ 圧縮サイズや単一ファイルの公開への切り替えはオプションである必要があります。
8. はい、例：CoreRT！

私見ですが、golangと同様の公開エクスペリエンスをターゲットにする必要があります。

@thegreatco ：はい、ネイティブコードへの完全なコンパイルは、単一ファイルのアプリを構築するための優れたオプションです。 GOのような言語は、プライマリモデルとして事前（AOT）コンパイルを使用して構築されています。これには、JITコンパイルによって実現される動的言語機能に一定の制限があります。

CoreRTは、AOTコンパイル済みアプリ用の.NetCoreソリューションです。 ただし、CoreRTが利用可能になるまで、この問題では他の方法で単一ファイルのアプリを実現しようとしています。

「HelloWorld」を実行するには216個のファイルが必要なようですが、

HelloWorldに必要なファイルの数を減らすために利用できるいくつかのオプションがあります」

• フレームワークに依存するアプリを作成します。これには3〜4個のファイルしか必要ありません。
• 自己完結型のアプリを構築する必要がある場合は、 ILLinkerを使用してファイルの依存関係の数を減らします

それらをディスクのある場所に抽出すると、単純なコマンドラインアプリケーションを削除するのが難しくなります。

• 単一ファイル機能の開発が次の段階に進むにつれて、ディスクにこぼれるファイルの数は減少し、ほとんどのアプリでは理想的にはゼロになります。 ただし、初期段階では、いくつかのファイル（ネイティブコードを含むファイル）をこぼす必要があります。
• ディスクにこぼれたファイルの場所は、常に決定論的で構成可能です。 したがって、こぼれたファイルは簡単なスクリプトでクリーンアップできます。 しかし、これは理想的ではないことに同意します。

明確化@mattpwhiteをありがとう。

はい、機能開発の後の段階まで、自己完結型アプリはディスクに抽出されたファイルを確認します。 上記のコメントで書いたテクニックのいくつかを使用して、アプリの状況を改善できる場合があります。

@BlitzkriegSoftwareからのご回答ありがとうございます。

ただし、コマンドスイッチの一部としてオールインワンとオールインワンの自己解凍型のどちらかを選択できることを指摘しておきます。

単一ファイルとして公開されたアプリが抽出を必要とするかどうかは、アプリのコンテンツによって異なります（例：ネイティブファイルが含まれているかどうか）。 バンドラーの設計は、すべてのファイルを抽出するかどうかを決定するためのいくつかの構成を提供します。 アプリが実行時にファイルへの抽出を使用してはならないというプロパティを追加できます。

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

ここでの理解は次のとおりです。SingleFileExtract=Neverをコンパイルするときに、抽出（ネイティブバイナリ）でのみ処理できるファイルがアプリに含まれている場合、単一ファイルへの公開は失敗します。

自己解凍型の場合は、解凍されたファイルをクリーンアップする取り消しを含める必要があります。

合理的に聞こえます。 抽出の正確な場所（存在する場合）は、決定論的で構成可能です。 したがって、アプリとその抽出されたすべての依存関係を削除するスクリプトを作成できます。

@DoCodeのご回答ありがとうございます。 あなたのシナリオは、プラグインを使用するという点で興味深いものです。
プラグイン自体にいくつかの依存関係（メインアプリと共有されていない）がある場合、プラグインも（依存関係が埋め込まれた）単一ファイルとして公開する必要がありますか？ ありがとう。

はい@swaroop-sridhar、それが目標です。 この場合、プラグインには依存関係が埋め込まれている必要があると思います。 共有の依存関係のみが、単一ファイルのメインアプリの外部に留まっている必要があります。

今日、 @ madskristensenは、VisualStudioおよび人気のあるNewtonsoft.JsonNuGetパッケージと優れた説明を共有しました。

私たちは時々同じような状況で同じ状況になります！

@DoCodeに感謝します。 単一ファイルのアプリが実装されて安定したら、単一ファイルのプラグインの機能に対処することを計画しています。 デザインドキュメントでは、プラグインについてここで説明しています。

この機能@swaroop-sridharに継続的に関与していただき、ありがとうございます。 元に戻るコマンドがあると、特に元のステージに最適です。

1. どのようなアプリで使用する可能性がありますか？ （たとえば、Windows上のWPF？Linux Dockerコンテナー内のASP.NET？他に何か？）
   -コマンドラインユーティリティ（コンソールアプリ）
2. アプリに（.NET以外の）C ++ /ネイティブコードが含まれていますか？
   - 番号
3. アプリは、アプリのビルドに元々含まれていなかったプラグインやその他の外部dllをロードしますか？
   -通常はありません
4. アプリを再構築して再配布し、セキュリティ修正を組み込むことをいとわないですか？
   - はい
5. アプリの起動が200〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？
   -<1秒が私の好みです
6. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 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〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？

いいえ、もう少し遅いです

6-アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？

プロジェクトによって異なりますが、単純なコマンドラインツールの場合、1桁のmbよりも大きくなることはないと思います。

7-サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？

開発/イテレーション時間に影響を与えない限り、リリースビルド時間が長くても問題ありません
ただし、.netコアアプリは、従来の.netFrameworkアプリよりも長く構築されていることを忘れないでください

毎年ソフトウェアが遅くなる傾向は受け入れられません。ハードウェアは優れていますが、その速度が遅い理由はありません。

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〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？

私は10秒未満なら何でも大丈夫だと思います。 起動時間は、べき等で予測可能である限り、通常は重要ではありません。つまり、ライブラリが同じ順序でロードされ、変数が同じ順序で初期化されるなどです。

アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 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〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？

net.coreはすでに少し遅すぎます。 ただし、数秒の増加は許容されます。 5秒-絶対にありません。

アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？

最近は関係ありません

サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？

5分までは許容できると感じます。 UWPの15〜20分のリリースビルドは、みんなを怒らせています。

アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

もちろん。

ありがとう@mjr27

これでステージ1の実装が完了し、 3.0.100-preview5-011568から利用できます。

ここで説明するように、 PublishSingleFileプロパティをtrueに設定することで、アプリを1つのファイルに公開できます。

このバージョンでは、ここで説明するように、すべての埋め込みファイルは最初の実行時にディスクに抽出され、以降の実行で再利用されます。

コンパイルスループット
ファイルが個別のファイルとして公開ディレクトリに書き込まれるか、単一のファイルとして書き込まれるかにかかわらず、時間に大きな違いはありません。

ファイルサイズと起動
次の表は、単一ファイルとして構築されたいくつかのアプリのパフォーマンスを示しています。

• Console：HelloWorldアプリ。 報告される時間は、アプリを実行する時間であり、クロックティックを介して測定されます。
• WPFアプリ： msix-カタログアプリ。 報告される時間は、ストップウォッチを介して測定された、初期画面に起動するまでの時間です。
• Fw：フレームワークに依存するビルド
• 自己：自己完結型のビルド。
  外部要因の影響を最小限に抑えるために、アンチウイルスチェックがオフになっているときにすべての実行のタイミングが調整されました。

測定| コンソール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.0RTMで終了しますか？ または、それらが実装されるまで3.0以降待つ必要がありますか？

ここで説明したように、.netコア3.0は、フレームワークに依存する純粋なmsilアプリをバンドルから直接実行できるように、ステージ2を実装することが期待されています。 残りのステージは、今後のリリースで検討されます。

ここで説明したように、.netコア3.0は、フレームワークに依存する純粋なmsilアプリをバンドルから直接実行できるように、ステージ2を実装することが期待されています。 残りのステージは、今後のリリースで検討されます。

:(それがRTMに到達できることを望んでいた。

@cup dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64でできると思いました。 バニラコンソールアプリを作成し、そのコマンドを実行してテストしました。 それはうまくいきました。

.pdbファイルをdotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 /p:IncludeSymbolsInSingleFile=trueにバンドルすることで、さらに先に進むことができます。

詳細なメモを提供してくれた@seesharprunに感謝します。 はい@cup 、コマンドラインの単一ファイル公開に推奨される方法は、コマンドラインからPublishSingleFileプロパティを設定することです。

@etherealjoy coreclrランタイムリポジトリは、ほとんどの場合、1か月ほどで機能が動作するようにロックダウンされます。 すべてのステージに十分な時間はないと思います。 次のリリースで次のステージが来ることを期待しています。

私は今日これを機能させましたが、抽出ベースディレクトリの変更は機能していないようです。 このセクションによると。 ExtractBaseDirと呼ばれるruntimeconfigにアプリケーションスイッチを追加して、アプリケーションが抽出される場所を変更できるはずです。

私はこのようなruntimeconfig.template.jsonを持っています

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

生成されたapp.runtimeconfig.jsonは次のようになります。

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

生成されたexeを実行しているときは、まだtmpフォルダーに移動します。

この機能はPreview5では準備ができていないと思いますが、runtimeconfig.jsonのどこに「ExtractBaseDir」が配置されるのかが明確でなく、例がないため、確認したいと思います。

@igloo15これを持ってきてくれてありがとう。

現在のプレビューでは、環境変数DOTNET_BUNDLE_EXTRACT_BASE_DIRのみが有効になっています。 これは、実装の現在の段階では、 runtimeconfig.jsonを含むすべてのファイルが処理される前にディスクに抽出されるためです。

次のプレビューでExtractBaseDirのサポートを追加する作業をしています。

これをASP.NETCoreプロジェクトで機能させる方法に関するガイダンスはありますか？ 推奨されるアプローチは、リフレクションを使用して、システムタイプがどこからロードされているかを見つけ、そのディレクトリを基準にしてIHostingEnvironment ContentRootPathとWebRootPathを設定することですか？

@keithwill AppContext.BaseDirectoryを使用して、app.dllおよび他のすべてのファイルがディスクに抽出される場所を取得できます。 したがって、これをContentRootPathとして使用できます。

@ igloo15 ：このオプションを使用した場合のシナリオを教えていただけませんか。

• デバッグまたは本番デプロイメントのシナリオで使用しようとしていますか？
• この場合、環境変数で十分ですか、それともruntimeconfig.json設定が必要ですか？

この設定の特定のユースケースがある場合は、他の開発者からも連絡をもらいたいと思います。

@ swaroop-sridhar

私はかなり奇妙な状況にあります。 私のソフトウェアはネットワーク共有に保存され、ネットワーク共有はランダムなWindows VMにリンクされ、ネットワーク共有から直接実行されます。 ネットワーク共有からソフトウェアを実行するためにスピンアップされたWindowsVMは、何も変更または変更できません。 ログ、構成ファイルなどはすべてネットワーク共有上に作成する必要があります。

不思議なことに、この設定により、システム全体で複数のソフトウェアを1つのフォルダーにレイアウトし、そのフォルダー構造をさまざまな構成/バージョンにクローン化できます。 次に、特定のバージョンを実行する必要がある場合、管理ソフトウェアはvmsを起動し、vms上のドライブを特定のバージョンのネットワーク共有にマップしてソフトウェアを実行します。

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）にする方が、実装がより簡単で効率的であることに同意します。 ありがとう。

こんにちは。このトピックについていくつか質問があります。

.NET Framework 4.7.2（たとえば）アプリケーションを単一の実行可能ファイルにパッケージ化するために、単一ファイル配布機能を使用したいと思います。 これはこの機能の目的ですか、それとも.NET Coreアプリケーションをサポートすることだけを目的としていますか？

私の2番目の質問は、パッケージングがどのように行われるかに関するものです。 実行可能ファイルが作成されると、ターゲットフレームワークランタイムが実行可能ファイルにバンドルされますか？ または、アプリケーションを実行するターゲットマシンにプリインストールする必要がありますか？

@gaviriar.NETFrameworkアプリケーションをサポートしているとは思いません。 そして、はい、.NET Coreランタイムを実行可能ファイルにバンドルできます（いわゆる「自己完結型」公開）。

@tomrus88ご回答ありがとうございます。 これは、.NETFrameworkアプリケーションに関しては本当に残念です。 .NET Frameworkランタイムを実行可能ファイルにバンドルするために使用できる推奨方法はありますか？

ドキュメントの関連する作業セクションにツールのリストが表示されます。 上記で提案したユースケースに特に推奨できるものはありますか？

@gaviriar.NETFrameworkはWindowsOSの一部です。 実行可能ファイルにバンドルするためのサポートされている方法はありません。

@gaviriarランタイムをバンドルする必要があることは、.NETCoreに切り替える主な理由の1つです。

@ jnm2と@jkotasの説明に感謝します、ここでは.NETの世界にnoobします。 .NETCoreに切り替えたいと思います。 ただし、.NETFrameworkを対象としているレガシーライブラリと対話する必要がある場合に直面しています。 このような場合、このライブラリを操作する必要がある場合、アプリを.NETCoreに切り替えることはできないと理解しています。 または、私のアプリが.NET Coreでありながら、従来の.NET Frameworkライブラリと対話できるような代替アプローチはありますか？

図書館によって異なります。 .NET Frameworkを対象とする多くのライブラリは、.NETCoreでも正常に機能します。 .NET Coreでライブラリを使用しようとしましたか？ それが機能しないことを確認した場合、それに対する解決策が得られるまで切り替えることはできません。

私は実際にそれを試しましたが、ウィンドウ固有のライブラリについて話しているので、これは機能しません。 .NET Frameworkをターゲットにすることに固執し、あなたが言うように.NET Coreの楽しみを逃す以外に選択肢はないと思います：/

@gaviriarこれはトピックから外れていますが、 Microsoft.Windows.Compatibilityを説明している正確な目的のために.NETCore用のWindowsAPIを提供するWindows互換性NuGetパッケージを試しましたか

@gaviriar ：さらにいくつかの説明：

実行可能ファイルが作成されると、ターゲットフレームワークランタイムが実行可能ファイルにバンドルされますか？ または、アプリケーションを実行するターゲットマシンにプリインストールする必要がありますか？

これはビルドによって異なります。 フレームワークに依存する（ランタイムがターゲットにインストールされる）アプリと自己完結型（ランタイムがアプリにパッケージ化される）アプリの両方を単一ファイルとして公開できますが、.netコア3.0アプリのみです。

ドキュメントの関連する作業セクションにツールのリストが表示されます。 上記で提案したユースケースに特に推奨できるものはありますか？

.net Frameworkの場合、私が提案できる最善の解決策は、アプリがファイル抽出を処理することです。 例：依存関係を管理対象リソースとしてアプリバイナリに埋め込み、起動時にリソースを明示的に抽出します。 バンドルライブラリをバンドルと抽出に使用することもできますが（ライブラリはnetstandardで構築されているため）、管理対象リソースを使用する方が優れたソリューションです。

@igloo15と@swaroop-sridharトピックから外れていることを考慮して、これらの入力に感謝します。 誰か他の人がいつか読んでいるときにこの議論が役に立つと思うことを願っていますが。

私はあなたが私と共有したオプションを評価し、私のユースケースに最適なアプローチが何であるかをお知らせします。

ありがとう！

クイックアップデート！

この単純なHelloWorldアプリケーションをテストしました。 単一ファイルの実行可能ファイルを正常にビルドできます。 ただし、プロジェクト構成からわかるように、自己完結型であることが意図されています。 しかし、.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. 実行可能ファイルを、.NETCoreランタイムがインストールされていないWindows7インストールにコピーします

3. HelloWorld.exe実行します

@gaviriarあなたが公開した例を試してみましたが、うまくいきました。
つまり、正常に実行されるHelloWorld用の自己完結型の単一exeを構築しました。

私が見ることができるのは、アプリをdotnet publish / p：PublishSingleFile =trueまたは/p：PublishSingleFile = falseとしてビルドしても、実行可能ファイルのサイズは変更されないということです。 これは予想される動作ですか？

これは絶対に予想されていません。 単一ファイルアプリは約70MBである必要があります（gitlabページに示されているデバッグビルドの場合）。 それ以外の場合、これは通常のapphostであり、上記で説明したとおりに失敗することが予想されます。 クリーンなディレクトリから公開していますか？

プロジェクトファイルに関するもう1つの注意点-プロパティの1つがIncludeSymbolsInSingleFile ＃$ではなくIncludeSymbolsInFileとして誤って記述されています。 しかし、これはあなたが報告した問題とは何の関係もありません。

@gaviriarターゲットランタイム識別子は何ですか。 正しく設定しないと、正しいhostfxr.dllがバンドルされません。 hostfxr.dllには、Windows7マシンには存在しない特定のvc++再配布可能ファイルが必要である可能性があります。 指定されたパスにdllが存在することを確認し、依存関係ウォーカーツールにロードしようとした場合は、依存しているdllが存在するかどうかを確認できます。

ILのマージ：ILMergeのようなツールは、多くのアセンブリのILを1つに結合しますが、その過程でアセンブリのIDを失います。 これは、単一ファイル機能の目標ではありません。

アセンブリのアイデンティティを失う

これは問題ではありません。
シングルexeの自己完結型機能にzip/unzipまたは他のバンドルソリューションを使用することは常に禁止されています。
これは次の問題を引き起こすからです。
シングルexeファイルのサイズを減らす方法！?? または、なぜexeファイルが大きすぎるのに、Hello Worldだけなのか！??

常に問題があり、対処する必要があります。徹底的にやってみませんか。
実際、最初からIL-Mergeと同様の方法を使用する必要があります。

実際、人々は単一のEXEにそれほど夢中になっているわけではありません。
exe（1）+ dll（1-2）もOKですが、400マウントdllではありません。
pplは、コードがサーバーディスクに実行されないようにし、サーバーメモリを使用して実行することを望んでいません。
人々は単に展開のコストを削減したいだけです。（ディスク、メモリ、帯域幅など...）

3.0マイルストーンを削除したので、この問題は、このドキュメントで説明されている段階を通じて単一ファイル機能の実装を追跡します。これは、3.0リリースの範囲を超えています。

@sgf 、ファイルサイズを小さくするために必要な作業があることに同意します。 サイズ縮小の機会には2つの形式があり、特に単一の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することです。 例： GetModuleFileNameW (Null, <buffer>, <len>)

@ chris3713現在、exeの場所にアクセスするための最良の方法は、ネイティブAPIにPInvokeすることです。 例： GetModuleFileNameW (Null, <buffer>, <len>)

おかげで、私はProcess.GetCurrentProcess().MainModule.FileNameを使用することになりました。

PublishSingleFile = trueで公開されたWindowsサービスとして、asp.netコアワーカー/WebAPIで正常に動作します。

サービスを登録してsc create testwk binPath="[...]/MyAspNetCoreWorker.exe" 、次に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を見るのが待ちきれません😀
ちなみに、ステージ2は引き続き.Net Core 3.0の一部になる予定ですか？

作業ありがとうございます。.netコアでの公開サービスは本当にシンプルになりました👍

CoreRT：（ 2.5mb ）

zipハックなし、隠れたコストなし、エンジンには必要なものだけが含まれ、未使用の機能はcsproj config（リフレクション）を使用して無効にされます

これは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ターゲットを続けて（ /t:Rebuild ）呼び出すと、出力サイズが大きくなります。

ご覧いただきありがとうございます@am11 。 古いバイナリを保持する公開は既知の問題です（cc @nguerrera）。

.Net Core 3プレビュー8以降、単一ファイルで公開されたアプリを起動できません。
イベントビューアでこのエラーが発生しました：

私はWindowsServer2019を使用しています

編集：このエラーは、.Net Core SDKPreview7を.NetCoreSDK 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 .NetCoreP9から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リポジトリに問題を報告してください。

私はこれを調べましたが、これは、一時ディレクトリにアクセスできない環境でアプリが実行されている場合にのみ発生します。 たとえば、これを行う場合：

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 win32APIを使用して一時ディレクトリを探すことに注意してください。 これはenvを使用します。 変数TMP 、続いてTEMPなど。 最初のwith値に無効なパスが含まれている場合、このように失敗します。

これを修正するには、一時パスが正しく設定されていることを確認するか、抽出を実行する場所にDOTNET_BUNDLE_EXTRACT_BASE_DIRを明示的に設定します。

@Safirionリプロの指示を送っていただけますか？ この失敗は決定論的ですか？
@jeffschwMSFTが上記で提案したように、core-setupリポジトリに問題を報告してください。

.Net CoreをRC1に更新してサーバーを再起動した後、この問題を再現できません。 （RC1をアンインストールし、プレビュー9を再度インストールして、RC1に再度アップグレードしようとしましたが、今回はアプリが正常に起動します）

このエラーは、SDK3.0P7からSDK3.0P8およびSDK3.0P9からSDK3.0RC1への移行時に発生しました。
また、2つのケースでは、サーバーを再起動するだけで問題が解決します。

RC1にアップグレードしたときは、.Net Core Windowsサービス（システムによって起動されるため、 C:\Windows\Temp\.netフォルダーを使用して抽出するワーカー）と.Net Core WPFアプリ（ユーザー起動セッションスクリプトによって起動）を使用します。 おそらく、このエラーは、.NetCoreSDKのインストール中に実行されている.Netコアワーカーが原因である可能性があります。わかりません...

ランタイムではなくSDKをインストールすることに注意してください。これは、3 .Coreランタイム（asp.netコア、デスクトップ.netコア、およびコア）を同時にデプロイする必要があり、 https ：//dot.netでは「フルランタイム」が提供されないためです。インストーラー」（Desktop Runtimeインストーラーも見つからないので、選択の余地はありません）...

更新：気にしないで、ドキュメントを見つけました。

ねえ、あなたのハードワークに感謝します！

構成ファイル（たとえば、App.config）はどのように配布されることになっていますか？ 正確なコマンドシーケンスを使用して、RHEL7.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 -system-interface

@morganbr

どのようなアプリで使用する可能性がありますか？ （たとえば、Windows上のWPF？Linux Dockerコンテナー内のASP.NET？他に何か？）

Windows用のヘッドレスおよびWPFアプリ

アプリに（.NET以外の）C ++ /ネイティブコードが含まれていますか？

はい、さまざまなネイティブdll、制御できないサードパーティアイテム、他のチームの内部アイテムをP/Invokeします。

アプリは、アプリのビルドに元々含まれていなかったプラグインやその他の外部dllをロードしますか？

はい。ただし、CompilerServicesを使用してソースからコンパイルします。

アプリを再構築して再配布し、セキュリティ修正を組み込むことをいとわないですか？

はい

アプリの起動が200〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？

はい、私たちのアプリは通常、長期間開いたままになっています。

サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？

はい、数分待つことができます。

アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

はい

ありがとう@john-cullen

抽出せずに単一ファイルアプリを実行するプロトタイプ実装のために、いくつかのPRをsingle-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〜500ミリ秒遅い場合は、それを使用しますか？ 5秒はどうですか？

はい。
（ユーザーに何かが起こっていることを通知するために、テキスト出力またはメッセージボックスを提供するのは素晴らしいことです）

1. アプリで許容できると思われる最大サイズはどれくらいですか？ 5 MB？ 10？ 20？ 50？ 75？ 100？

10〜20 Mb

1. サイズや起動時間を最適化するために、より長いリリースビルド時間を受け入れますか？ あなたが受け入れる最長のものは何ですか？ 15秒？ 30秒？ 1分？ 5分？

1分以上で大丈夫です。

1. アプリのサイズが半分になる場合は、追加の作業を喜んで行いますか？

おそらく。

返信ありがとうございます、@lenardg。

この問題は、.NETCore3.0単一ファイル配布機能の進捗状況を追跡します。
この機能の設計ドキュメントとステージング計画は次のとおりです。

これは、展開を容易にし、サイズを縮小するための非常に便利な機能です。
特に、グループポリシーを介して環境が厳密に制御されているエンタープライズ展開の場合、設計に関する改善点はほとんどありません。

1. 条件付きで、単一の実行可能ファイルをパックしながら圧縮することは可能ですか？
   つまり、ラップのようなロジックを追加するので、他のツールを統合する必要はありません。
   圧縮すると、さらに小さなexeが生成されます。

2. exeを起動すると、その内容が一時フォルダに展開されます。 当社の製品では、特定のユーザーサイトで、クライアントマシンが厳密に制御されており、実行可能ファイルを一時フォルダーまたは％userprofile％の場所から起動することはできません。

抽出する場所を指定/制御することは可能ですか、または「。\ extract」またはそのようなサブフォルダー内の「インプレース抽出」である可能性がありますか？
これにより、グループポリシーへの準拠と、単一のexe機能を使用できるようになります。

1. パックする前に、フォルダーに署名してから、パックするファイルを選択することはできますか？
   単一のexeに署名することはできますが、抽出ファイルは署名されていないため、他の特定のクライアントの場所では、バイナリが署名されていない限り、実行できません。

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

お知らせしたかったのですが、今日は@Safirionと同じ問題が発生しました。 私はubuntuをターゲットにしたdotnetcore3.0アプリを持っていて、それをSynologyサーバーで実行しました。 抽出されませんでした-「致命的なエラーが発生しました。バンドルのコンテンツを抽出できませんでした」というエラーで失敗し続けました。 何度か再構築しましたが、同じことです。 ホストを再起動した後、それは再び正常に動作しました。

ここにファイルロックなどがあるかどうか、そしてそれをデバッグする方法があるかどうかを理解するのに役立ちます。

@RajeshAKumar dotnet / core-setup＃7940

そのリンクがどのように役立つかわかりません。
それは一時的な抽出について話しているだけです、私は上記の3つのポイントをリストしました。

そして、私はあなたにそれらの1つの解決策を与えました。 私は他の2つについてはわかりません

そして、私はあなたにそれらの1つの解決策を与えました。 私は他の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 ：バンドルされたsingle-exeの圧縮は、.net 5で検討中の機能です： https ：//github.com/dotnet/designs/blob/master/accepted/single-file/design.md#compression

今のところ、生成されたsingle-exeを圧縮するには、他のユーティリティを使用する必要があります。

@RajeshAKumar 、署名に関しては、公開されてsingle-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 、署名に関しては、公開されてsingle-exeにバンドルされるすべてのファイル/バイナリに署名できます。 ホストが埋め込みコンポーネントをディスクに抽出すると、個々のファイル自体が署名されます。 前述のように、ビルドされた単一ファイル自体に署名することもできます。

それはあなたの要件を満たしていますか？

「コンパイル」を解除してパーツを公開する方法を理解しようとしています。
現在、次のコマンドを使用しているため、署名できません。
設定publishargs=-cリリース/p：PublishSingleFile = True / p：PublishTrimmed = True / p：PublishReadyToRun = false
dotnet publish -r win-x64 -o bin \ Output \ Win64％publishargs％

上記はトリムやパッケージと同様にコンパイルされるので、それらを壊す方法がわかりません。
理想的にはあなたのアプローチを使用するために、私はコンパイルし、署名し、最後にそれを公開する必要があります。

@Webreaper問題を再現できる場合は、 COREHOST_TRACEをオンにしてアプリを実行し（ COREHOST_TRACE環境変数を1設定）、生成されたログを共有してください。 ありがとう。

ありがとう。 再起動したため、現在はなくなっていますが、再度発生した場合に備えておくと便利です。

@RajeshAKumarは、バンドルの直前に実行されるターゲットに署名をタグ付けする必要があります。
PublishReadyToRunとPublishTrimmedを使用しているため、標準のAfterbuildまたはBeforePublishターゲットを使用することはできません。

BundlePublishDirectoryの直前で実行され、署名を実行するターゲットを追加できます。

@ swaroop-sridhar
これは非常に優れた機能です。 どのdotnetリリースでさまざまなステージがいつ利用可能になるかについてのリンクはありますか？

@etherealjoyに感謝します。 バンドルから直接実行される単一ファイルの作業は進行中であり、私の理解を深めるために.net5リリースを対象としています。

@RajeshAKumarは、バンドルの直前に実行されるターゲットに署名をタグ付けする必要があります。
PublishReadyToRunとPublishTrimmedを使用しているため、標準のAfterbuildまたはBeforePublishターゲットを使用することはできません。

BundlePublishDirectoryの直前で実行され、署名を実行するターゲットを追加できます。

ありがとう。
あなたが与えたリンクはMSビルドタスクのように見えます。
「BundlePublishDirectory」のハンドラーを作成するにはどうすればよいですか？ これはスタジオ/プロジェクトの小道具/ビルドイベントにありますか、それとも最初から何かを作成する必要がありますか？

この場合、 @ RajeshAKumarは、ビルド前のビルド後のイベントよりもきめ細かいものが必要になります。
したがって、プロジェクトファイルを編集して、次のようなものを追加する必要があると思います。

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

これでdotnet packコマンドの予想される動作は何ですか？ シングルエグゼアーティファクトがローカルのnugetリポジトリにプッシュされたとしましょう。 Chocolateyを使用してインストールしようとすると、プロジェクトファイルにリストされているすべてのnugetdepsを復元しようとします。 これは以前は予想されていたものですが、この動作が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リポジトリにプッシュされたとしましょう。 Chocolateyを使用してインストールしようとすると、プロジェクトファイルにリストされているすべてのnugetdepsを復元しようとします。 これは以前は予想されていたものですが、この動作がSFDに対して正しいかどうかは疑問です。

@catlion PublishSingleFileプロパティは、 dotnet publishコマンドでのみサポートされます。 したがって、 dotnet packには影響しません。 シングルファイルとパッケージングの両方を使用する動機はありますか？

編集：起動時に古いバージョンを自動的にクリーンアップする方法はありますか？

現在のリリースの@Safirionでは、クリーンアップは手動で行われ、ホストは抽出されたファイルを削除しようとはしません。これは、将来の実行で再利用される可能性があるためです。

はい、自分でクリーナーを作ります😉
お返事ありがとうございます。

@cupは、monoについて特別なことではなく、単なる標準のコンパイルであり、nuget参照を追加するようになりました。そのソリューションは、もはや単一のファイルではありません。 モノはmkbundleを持っていますが、単一のファイルを実現するために

@Suchimanよろしいですか？ 上記の私の例では、単一の3KBファイルが生成されます。 dotnetの最小サイズは27MBのようですが、次のようになります。

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

@cupはい

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

@Suchimanよろしいですか？ 上記の私の例では、単一の3KBファイルが生成されます。 dotnetの最小サイズは27MBのようですが、次のようになります。

＃24397（コメント）

3kファイルは、monoがすでにインストールされているためにのみ機能します。 dotnetcore単一ファイル配布の要点は、clrをインストールする必要がないことです。これは、ランタイムを含むスタンドアロンの単一exeです。

@Webreaperは、実際には、モノラルのmcsのみを使用してコンパイルしたと思います。彼はmono sun-mon.exeを記述していなかったため、.NETFrameworkで実行された可能性があります。

ただし、.NET Coreは、ランタイムがプレインストールされているシナリオ、つまりフレームワークに依存する展開もサポートしています。 .deps.jsonや.runtimeconfig.jsonなどの.NET Core用の追加ファイルがいくつかあるため、この場合はまだ完全に単一のファイル展開ではありません。

@ chris3713現在、exeの場所にアクセスするための最良の方法は、ネイティブAPIにPInvokeすることです。 例： GetModuleFileNameW (Null, <buffer>, <len>)

私はまだWindows以外で両方のアプローチを試していませんが、 Environment.CurrentDirectoryの方が優れたソリューションのようです。

編集：いいえ。 そのパスは、アプリケーションのさまざまなエントリポイントで変更される可能性があります。 ダメ。

少し関連したメモで、VS for Macの最新のプレビューで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は同じことを行うことができますが、パスが異なります...

少し関連したメモで、VS for Macの最新プレビューでのBlazorアプリの単一ファイル公開でこのリグレッションを見つけました： aspnet / AspNetCore＃17079 -AspNeCore / Blazorで報告しましたが、これが原因である可能性がありますcoreclrグループにより関連性があります-わからない。 あなたたちが動き回るためにそれを残します！

@Webreaper問題を報告していただきありがとうございます。静的アセットに関するASP.netの問題のようです。 だから、それはそれを提出するのに適切な場所です。

*投稿を他の号からここに移動します。

@ swaroop-sridhar、

DotNet CoreシングルファイルWPFアプリの起動時間は、.net4.7でビルドされた元のILMerge-edWPFアプリケーションよりもはるかに遅くなります。 これは予想されることですか、それとも将来改善されるのでしょうか？

ビルドは私のImageOptimizerから来ています：https：//github.com/devedse/DeveImageOptimizerWPF/releases

| タイプ| 推定初回起動時間| 推定2回目の起動時間| サイズ| ダウンロードリンク|
| -| -| -| -| -|
| .NET 4.7.0 + ILMerge | 〜3秒| 〜1秒| 39.3mb | リンク|
| dotnet publish -rwin-x64-cリリース--self-contained=false / p：PublishSingleFile = true | 〜10秒| 〜3秒| 49mb | |
| dotnet publish -r win-x64-cリリース/p：PublishSingleFile = true | 〜19秒| 〜2秒| 201 mb | |
| dotnet publish -r win-x64-cリリース/p：PublishSingleFile = true / p：PublishTrimmed = true | 〜15秒| 〜3秒| 136mb | リンク|
| dotnet publish -rwin-x64-cリリース| 〜2.5秒| 〜1.5秒| exeファイルの場合は223kb（dllでは+ 400mb）| |

@devedseは、確かに、「2回目の起動」は（最初の起動以外の）複数回の実行の平均ですか？
興味がありますが、 /p:PublishSingleFile=true /p:PublishTrimmed=trueの実行が ` /p:PublishSingleFile=trueの実行よりも遅い理由についての説明がありません。

したがって、調査する前に、「2番目のスタートアップ」の数値が安定した数値であり、スタートアップの違いが再現可能であることを確認したいと思います。

また、この問題は単一ファイルプラグインに関するものですが、perfディスカッションを新しい問題に移動するか、dotnet / coreclr＃20287に移動してください。 ありがとう。

@ swaroop-sridhar、それが平均であるというあなたの質問に答えて：
これを正確に計時するのは少し難しいので、タイミングは、アプリケーションの起動中にカウントし、起動時間に大きな違いがあるかどうかを確認するために数回試行することによって行われました。 より良い方法を知っている場合は、私のソリューションを構築することで簡単に再現できます：https://github.com/devedse/DeveImageOptimizerWPF

私の主な質問は、バンドルされていない.exeファイルと比較して、バンドルされた（単一ファイル）アプリケーションの起動に時間がかかる理由に関するものです。

私はここで間違っているかもしれませんが、単一のファイルにはオーバーヘッドがあるので、それは私には理にかなっています。 基本的に、別のアプリを起動しているアプリがあります。 ILMergeが直接起動している間。 ILMergeは、参照されたdllをexeにマージするだけで、現在PublishSingleFileで実行されている別のレイヤーにすべてをラップしませんでした。

@devedse単一のファイルは、基本的に、ドットネットの実行を開始する前に、チェックサムの抽出やチェックなどを行っています。
それがその時間がかかった理由だと思います。
抽出は「キャッシュ」されるため、次回の実行ではIOオーバーヘッドはありません。

@RajeshAKumar 、うーん、このシナリオで実際に進む方法を抽出していますか？ ILMergeの方法で、実際にDLLを1つのバンドルにマージする方がよいのではないでしょうか。

特に大きな.exeファイルの場合は、すべてのファイルを2回保存するためのディスク容量のコストも発生します。

@devedse私たちは皆、この機能の次の段階（バンドルから実行）を待っていますが、今のところ、それが唯一の解決策です。 😉

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

これは、デスクトップでJITを使用することで得られるものであり、起動が遅く、Appleだけがこれを理解しているように見えます

（ほとんどの場合、すでに述べたことを繰り返します）：
最初の起動ははるかに遅くなると予想されます-アプリをディスクに抽出します-非常に多くのIO。 2回目以降の起動は、アプリの非単一ファイルバージョンとほぼ同じである必要があります。 内部測定では、違いは見られませんでした。

測定方法：トレース（WindowsではETW）を使用しました-プロセスの開始時にイベントがあり、次にこれに使用できるランタイムイベントがあります-しかし、それは必ずしも簡単ではありません。

@Safirionが述べたように、.exeから直接（ディスクへの抽出なしで）マネージコードのほとんどを実行する必要がある単一ファイルの次の改善に取り組んでいます。 しかし、まだリリーストレインを約束することはできません。

JIT：すべてのフレームワークはReady2Run（CoreFX、WPF）でプリコンパイルする必要があるため、起動時にアプリケーションコードのみをJITする必要があります。 完璧ではありませんが、大きな違いを生むはずです。 起動時間が約1〜2秒であることを考えると、すべてのテストですでにそれを使用していると思います。

おかげさまで、次のステップが計画されていることに気づきませんでした。 これはそれを明確にします。

最初の起動ははるかに遅くなると予想されます-アプリをディスクに抽出します-非常に多くのIO。

これは決して起こらないはずです、あなたはユーザーエクスペリエンスをデザインによって恐ろしいものにします、恐ろしい選択、それはあなたがユーザーに開発者が彼らのために使用している技術を嫌う方法です

@Safirionが述べたように、.exeから直接（ディスクへの抽出なしで）マネージコードのほとんどを実行する必要がある単一ファイルの次の改善に取り組んでいます。 しかし、まだリリーストレインを約束することはできません。

すぐに変更されるのに、なぜ今すぐ正式にリリースするのですか？ プレビュー/実験としてマークする必要があります

私の意見では、これは時間とリソースの無駄であり、AOTコンパイルとツリーシェーキングに焦点を合わせ、すべてのリソースをそこに置き、ハックで停止します

@RUSshyなぜそんなに嫌いなの？ 最初に起動するときに起動を遅らせたくない場合は、単一ファイルの展開を使用しないでください。

起動時間は10秒未満で、初めて実行するだけなので問題ありません。 私はサーバー側のウェブアプリをデプロイしています。つまり、ほとんどの場合、一度起動してから数日/数週間実行されるので、最初の抽出は物事のスキームではごくわずかです-したがって、これをコンパイルされたイメージが1つになるまで一時停止します。これは、何百ものDLLをその場所にコピーするよりもはるかに簡単にデプロイできるためです。

私の場合は+1で、単一のexeを生成するビルドドッカーと、アプリを実行するための個別のドッカーがあります（ドットネットのない通常のアルパインドッカーイメージを使用）。 bulidステップの後、ランタイムコンテナを1回ホットロードし、レイヤーをdocker-commitします。 その後、フレームワークに依存する展開と比較して、パフォーマンスの低下は見られませんでした。 バンドルからのロードファイルメカニズムが実装されて出荷されたら、中間のホットロード手順を削除します。

@ vitek-karas、「バンドルからランタイムアセットをロードする」機能の追跡に問題はありますか？ どんな障害があるのか​​を理解することに興味があります。 :)

@ am11現在、詳細な計画をまとめています。 https://github.com/dotnet/coreclr/tree/single-exeで行われたプロトタイプを見ることができます。 実際の実装はおそらくそれほど違いはありません（明らかに、より良いファクタリングなどですが、コアとなるアイデアは正しいようです）。

@Webreaper Webアプリの場合、それはまったく問題ではありませんが、おそらく.NetCore3がWPF/WinForm開発に推奨されており、100個の.dllで失われたデスクトップアプリケーション.exeを共有することはオプションではないためです。この機能の最初の段階に関連するフラストレーションを理解してください。
;）

そして、今日、exeをクリックする前に10秒（または3秒以上）待つユーザーはいません。 読み込みインジケーターがないという事実は、この機能の2番目の大きな問題です。 残念ながら、読み込みインジケーターは.Net Core 3.1の一部ではないようです。そのため、ユーザーは辛抱強く待つ必要があります...

デスクトップ開発者は本当にステージ2を待っています。実際、.Net Coreでのデスクトップ開発はエンドユーザーにとって本当に悪い経験であるため、これは.Net5の一部になると思います。

@RUSshyなぜそんなに嫌いなの？ 最初に起動するときに起動を遅らせたくない場合は、単一ファイルの展開を使用しないでください。

これは嫌いではありません。これは建設的で正直なフィードバックです。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）が、オーバーライドできないオーバーライドなしでシリアル化されたバイトをシリアライザー実装のアセンブリ名に結び付けることが賢明であると判断したため、コードを移動できないことを発見しました。

反省を思いとどまらせることに向けた進歩は進歩です。

ところで、バンドルサイズとロード時間を削減し、プログラム全体を最適化できるように、アセンブリをマージする方法を探していました。 私は、この問題が実際にはそれを対象としていないことを収集します。

編集：この投稿は明確にするためにいくつかの反応を集めたので。 メタプログラミングは、コードがデータであり、私の管理下にある設計時に行われるべきだと思います。

信頼できる不変条件を適用するために使用するのが好きなタイプ。 ランタイムリフレクションはその信頼を壊します。

したがって、ランタイムリフレクションを設計時のメタプログラミングに置き換えたいと思います。 アナライザー、クイックフィックス、リファクタリングなどのユースケースと重複することで、より強力になる可能性もあります。

このエリアへのサブスクライバーのタグ付け：@ swaroop-sridhar
購読を希望する場合は、danmosemsftに通知してください。

単一ファイル機能の設計は、このドキュメントにあります： https ://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md
この問題での単一ファイルアプリの進行状況の追跡： https：//github.com/dotnet/runtime/issues/36590。
この号に関するフィードバックと提案をありがとうございました。