Runtime: 単一のexe自己完結型コンソールアプリ

このシナリオは現在サポートされていません。 この道をたどる作業については、 https：//github.com/dotnet/corertリポジトリに注目して

CoreRTは、このソリューションを検索するのに適した場所です。

ありがとう。 CoreRTはまさに私が探していたもののようです。

これにつまずくかもしれない他の人のために、ここを読んでください

特に、事前にコンパイルせずにこの機能が必要です。 corertは必要ありません。通常の自己完結型アプリと同じjit、デバッグ、およびランタイムエクスペリエンスが必要ですが、ユーティリティごとに4つのファイルを配布することも必要ありません。 これは、ユーティリティを使用したい人にとっては不便です。 私はそれをパックして単一のexeから実行したいだけです。 これにより、多くのユーティリティで.NETCoreではなく.NETFrameworkを選択するようになりました。

.NET Frameworkは、OSにすでに多数のファイルが存在するため、「不正行為」を行っています。
必要に応じて、マシン全体で共有される.NET Coreをインストールすることで、.NETCoreでも同じことができます。

CoreCLRをリファクタリングしてすべてのファイルを1つ（ネイティブ+マネージドを含む）にマージすることは簡単な作業ではなく、あまりにも多くの顧客にとってこのシナリオはそれほど興味深いものではないと思います。

違いは、すべてのWindowsマシンに.NET Frameworkが保証されているが、.NET Coreは保証されていないことです。したがって、展開をより複雑にする価値のある特別な理由がない限り、私はそこにとどまることになります。
顧客は通常、単一のexeユーティリティを作成しないと思います。 いつの日にか。 :-)

展開をより複雑にする価値のある特別な理由がない限り

.NETFrameworkよりも.NETCoreを好む理由はたくさんあります。 パフォーマンス、モジュール性、保守性、分離など。そして、それはクロスプラットフォーム性を無視しています。

単一のexeユーティリティを持つことは、ほとんどの場合、見た目の問題です。 実行可能ファイルが単一のファイルである場合、または少数のファイルが含まれる単一のフォルダーである場合、（関係者全員にとって）実際の機能の違いはありません。

@mellinoeああ、私はプロジェクト全般に同意します、それは確かに真実です。 この見た目が望ましい小さなユーティリティでは、.NETFrameworkはこれまでのところ十分な仕事をしています。 組立会社や著作権表示を指定できるのと同じ意味で見た目が良いと思います。 しかし、化粧品であることは私がそれを好きになることを少なくしません。 明らかにここでは優先事項ではありませんが、それは非常に理解できます。

おそらく関連： https ：

それはほとんど化粧品ではありません。 Idsrv4やRavenDb +自分のものなど、いくつかのコンポーネントが埋め込まれているアプリケーションを配布したいとします。 それらはaspnetコアビットに依存します。 同じバージョンのaspnetコアに依存している限り、これはすべて正常に機能します。 それらの1つが次のバージョンにロールフォワードするとすぐに、おそらく機能しなくなります。 OTOHが各コンポーネントを単一の.dllに統合できれば、問題は解決します。

覚えておくべきことの1つは、ILMergeが機能しないだけではなく、技術的な問題が多いということです。 ランタイム自体は基本的に多くのファイルに分割されており、CLRホスト、ランタイム依存関係テキストファイルなどの補助ファイルもあります。 単一ファイルの実行可能ファイルが過去に機能した唯一の理由は、グローバルなシステム全体のインストールである.NETFrameworkが信頼されていたためです。 .NET Frameworkには実際には「自己完結型」オプションがないため、2つのシナリオを比較するのは少し不公平です。

同じバージョンのaspnetコアに依存している限り、これはすべて正常に機能します。 それらの1つが次のバージョンにロールフォワードするとすぐに、おそらく機能しなくなります。

これは本当に真実ではありません。 異なるランタイムバージョンに対していくつかの異なるアプリケーションを公開し、それらを同じ「uber-app」にバンドルすることができます。 それらの依存関係を単一のフォルダーに混在させることはできません。 フレームワークに依存する公開オプションを使用する場合でも、バージョンを組み合わせて組み合わせることができます。 これは文字通り単一のファイルを持つよりも便利ではなく、PEのリソースとしてexeを埋め込むなどのことを妨げる可能性があることを理解しています。 それがあなたが参照しているものであるかどうかはわかりませんが、おそらくそれを実行するためにファイルを抽出する必要があるので、それはディレクトリで行うことができます。

私はランタイムバージョンを意味していませんでした、私はそれがうまくいかないことを知っています。 つまり、各コンポーネントが[email protected]に依存している場合、シナリオで何が起こるかということです[email protected]に更新され

@thefringeninjaの適切なポイントと同様に、単一のデプロイ可能なバイナリユニットがopsのオーバーヘッドを削減することをお勧めします。 これにより、デプロイメントで問題が発生する可能性が減り、出荷したものを認知的に評価する負担が軽減され、スクリプトや目的の状態など、opsツールの構成が削減されます。

dotnetツールはまだ初期段階であり、2.0に到達したばかりですが、golangなどの代替ツールと比較すると、この機能が非常に不足しています。 ロードマップに追加することを検討してください。

lib開発者として、ILMergeをCoreに戻していただければ幸いです。 👍

Dotnet.exeは単一のファイルです。 NuGet.exeは単一のファイルです。 見た目は重要だと思います。1つのファイルのexeファイルは、100個のファイルを含むフォルダーがそうではない方法で単純さを叫びます。 dotnetcoreでこれを達成する方法を見つけるのは素晴らしいことです

私はこれが可能だと思い、数週間の作業の後、CLIコンソールツールを単一の.exeに公開するようになりました...うーん、現時点では単一の* .exeを取得できないようです??
それが自己完結型のコアアプリのポイントだと思いましたか？

@PRIMETSS

それが自己完結型のコアアプリのポイントだと思いましたか？

自己完結型アプリのポイントは、自己完結型であるということです。つまり、アプリ自体に実行に必要なすべてのものが含まれているため、ターゲットマシンに.NetCoreをインストールする必要はありません。

このようなアプリをデプロイするには、ファイルのディレクトリ全体をコピーする必要があります。 ファイルが1つしかない場合はデプロイが簡単になりますが、それだけです。それがなくても、自己完結型のアプリです。

大規模でサービスのようなアプリの場合、これはそれほど重要ではないかもしれませんが、コマンドラインツールと小さなアプリができるだけシンプルでCOPY展開に適していることが不可欠です。

私は定期的に.NETでコマンドラインツールを作成しており、それらを1つのEXEとして使用すると、アップグレード/展開/パッケージ化が簡単になります。 私は常にすべての.configおよびその他の必要なファイルをEXE内にパックします。

その単一のEXEをミニコンテナと考えてください。 コンテナベースの展開のほとんどすべての利点がここに適用されます。

これは恐ろしいことです。なぜこれが設計プロセス中に承認されたのか、アプリケーションをクライアントの1つに配布したいのですが、何を開くかを見つけるために彼に幸運を祈ります。

これはただ醜くて完全な混乱です

ランタイム/
MyProgram.exe
MyLib.dll

これはずっと良い考えだっただろう

Javaでさえそれをうまく処理します：

はい、私は同じように考えていました。自己完結型のアプリにはランタイムファイルを含める必要があるため（明らかに！）（そしてそれらをマージする方法はありません）、フォルダーを分離するだけでよいと思いましたきちんとしていて、はい、ランタイムファイルはランタイムフォルダに保存する必要があると思います。そのため、コアで記述されたコマンドラインツールを使おうとすると、実行するものとして少なくとも少し直感的になります。

@ Scellow @ PRIMETSS同意する必要があります

これはまだ問題ですか？ このための需要は屋根を通り抜けています。

はい、この別のフォルダーに、それをbinに圧縮し、exeとbinの2つのファイルを追加します。 簡単な配布。

再び開いて機能として持つための別の+1。

自己完結型のデプロイメントが自己完結型であると期待していたので、ここで自分の道を見つけました。 私もこれが起こるのを見たいです。

これは単なる表面的な問題であると誰がどのように言うことができますか？ （フレームワーク開発者のみ...）
インストールされていないツールについて誰も考えませんでしたか？ （.NETはdll-hellを解決し、.netコアはそれを元に戻します）

コマンドラインツールを自己完結型にしたいだけです。

これは悪いです、本当に悪いです！

+1

+1 .netコアランタイムのないクラスターでAzureBatchでカスタムアクティビティを実行しようとしましたが、「自己完結型」バージョンで作成される多数のファイルを処理できません。

Total size of resourceFiles cannot be more than 32768 characters

これは公式の解決策ではありませんが、役立つ場合があります。 私はwarpの作成者です。これは、自己完結型の単一バイナリアプリケーションを作成できるツールです： https ：

ワープは基本的に誰もがここで探しているものだと思います！ それは、バックグラウンドにあるものが何であれ、単一のexeファイルを持つ機能についてだけです。 NuGetパッケージについて考えてみてください。これは単一の.nugetファイルであり、それだけです。 他のファイルをパッケージ化したファイルよりも複雑なものではありません。

ワープはハッキーな解決策です、これは私たちが望むものではありません

私たちが欲しいのは：

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

そしてそれは生成します：

App.exe
runtime/

またはGO / Rustなどのように

App.exe

他のすべては望まれていません

WarpはApp.exeを生成します...どのようにハッキーですか？ 明らかにそれはフレームワークの一部ではありませんが、「1つのexeファイル」の目標を達成します。

これは私が意味することです、それはサードパーティのソリューションを使用するのではなく、デフォルトの動作でなければなりません（私は思う）

ワープはおやつです。 @dgiagioの作業に感謝します！

+1

実行可能ファイルとすべての依存関係をバンドルした、ある種の単一ファイルアーカイブが欲しいです。 ネイティブのものを含める必要はありません-ドットネットコアをシステムにインストールする必要があるのはまったく問題ないと思います。 Javaのjarファイルに非常によく似たもの。 darファイル？

何かのようなもの：
dotnetpublish-自己完結型
dotnet run --self-contained MyApp.dar

現在、これに関する提案があるようです： https ：

追跡の問題は次のとおりです： https ：

また、 @ shanselmanにはWarpソリューションに関するブログ投稿があります。

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

私は提案を読み、これを見ました：

それは私が考えていたものではありません。これは遅いプロセスのように聞こえます。基本的にはすべてを圧縮するだけです。
すべてのコードが単一の実行可能ファイル/ dllにマージされますが？ または多分私は提案で何かを逃しましたか？

@RUSshyすべてのマネージコードをネイティブコンパイルし、すべてをリンクして1つの実行可能ファイル（CoreRTのように）を取得することについて質問していますか？ これは、.NetCoreでの現在の単一ファイル作業の目標ではありません。

ただし、ディスクの抽出と起動時間を短縮するための解決策が提案されています（例：バンドルから直接特定のファイルタイプをロードし、抽出されたファイルを再利用します）。 ここでは、単一ファイルソリューションの開発段階について説明します。

CC： @jeffschwMSFT

なぜファイルを抽出する必要があるのですか？ 以前は、ILMergeを使用して.NETでこれを回避していました。

@ phillip-haydon、ここで説明

ILMergeは、多くのアセンブリのILを1つに結合しますが、その過程で、マージされたアセンブリの元のIDが失われます。 そのため、元のアセンブリ名に基づくリフレクションの使用などは失敗します。 アプリがこの変更に耐えられる場合は、ILMergeを引き続き使用できます。

CoreRTは別のものであり、.NETコードのAOTコンパイルです。面白そうに見えますが、まだ準備ができていません（MSがそれに焦点を合わせ、より多くのリソースを割り当てることを望みます。これはまさに人々が望んでいることであり、彼らがGOに移行した理由です）

とにかく、私は詳細について話すための技術的な知識を持っていませんが、ユースケースは次のとおりです。

単一の自己完結型の実行可能ファイルを公開します。それだけで、圧縮も抽出も、オーバーヘッドも、実行可能ファイルだけです。

@ swaroop-sridhar Linuxのdotnetcoreでこれが機能する例はありますか？ https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13によると、これはWindows /モノラルのみのプロジェクトです。

@thefringeninja ILMergeはWindowsツールであり、ILMergeを他のプラットフォームに移植する計画はありません。
単一ファイルソリューションは、クロスプラットフォームで実装されます。 これは開発中です。

@karelz @mellinoe
デプロイデプロイデプロイ！1〜3ファイルのように単一またはそれ以下の場合、デプロイ（公開、更新を含む）に適しています！

CoreRTはAOTです
しかし、pplはAOTが欲しいですか？
プロジェクト（CoreRT）は常にすぐに使用できるわけではありません（2014年から）。 今は2019年です！（約5年かかります）
プラグラム言語にとってなんと貴重な5年でしょう。CoreRTは、次のリリースの計画もありません!!!pplをさらに5年間待たせますか？

@ swaroop-sridharそれは残念です。 ILMerge / ILRepackは、ライブラリ開発者がひし形の依存関係の問題を回避するのに最適です。

.NET Core3.0でサポートする計画があります-
.NET Core 3.0のブログ投稿で言及されています-例： https ：
また読む： https ：

.netは、小さな単一の自己完結型実行可能ファイルを生成するためにこれらすべてのハックを必要としないはずです。これはデフォルトの動作である必要があります。GOによって生き生きと食べられ、Rustも登場し、CoreRTまたはILMergeに焦点を合わせます。.netコアアプリもすでに存在します。ロードするすべてのファイルのために開始するのに長いです、提案で述べられているようにzip / unzipでこれに耳にしたものを追加しないでください、これは行く方法ではありません

.netは、小さな単一の自己完結型実行可能ファイルを生成するためにこれらすべてのハックを必要としないはずです。これはデフォルトの動作である必要があります。GOによって生き生きと食べられ、Rustも登場し、CoreRTまたはILMergeに焦点を合わせます。.netコアアプリもすでに存在します。ロードするすべてのファイルのために開始するのに長いです、提案で述べられているようにzip / unzipでこれに耳にしたものを追加しないでください、これは行く方法ではありません

pplにはjavaがあるので、.netが生きている必要はありません。
go、rust、dlangは、Fuck Zip / Unzipを備えているため、単一の実行可能プログラムへのビルドターゲットをサポートするべきではありません。

@RUSshy

.netは、小さな単一の自己完結型実行可能ファイルを生成するために、これらすべてのハックを必要とすべきではありません。

同意しました。 同時に、.NETは、静的リンカーの要件との調整が難しい他の言語に比べて特定の機能を提供します（たとえば、オンザフライのコード生成、リフレクション、データバインディングなど）。 単一ファイル/静的リンクが重要なシナリオでは、これらの機能を除外することを試みました。 お客様のフィードバックから、エコシステムから消費できるライブラリの数が大幅に減少したこともあり、この結果は.NETのようには感じられなくなったことがわかりました。

したがって、.NETで依存関係を持ち、愛用している機能の忠実度を損なうことなくリンカーを適切に実行することは、難しい問題です。 これを解決する一環として、さまざまなアプローチを試しています。 あなたはこれをハックと呼んでいます、私はこれを心を開いて、箱の外で考えることをいとわないと呼びます。 しかし、やみくもに.NETをGo / Rust / C ++に変えるのは正しい答えではありません。

単一ファイル/静的リンクが重要なシナリオでは、これらの機能を除外することを試みました。 お客様のフィードバックから、エコシステムから消費できるライブラリの数が大幅に減少したこともあり、この結果は.NETのようには感じられなくなったことがわかりました。

チームは、jetbrainsがkotlin JVM / kotlin NATIVEで行ったように、ネイティブ開発と制約のある環境に焦点を合わせた.netの別のバージョンを作成することを考えましたか？

あなたが言ったように、.netをすべてのユースケースに適合させようとすることは最も賢い選択肢ではないので、特定のフレーバーがこの問題に対する正しい答えかもしれません

そして、tbh、afaik、この問題は.netコアの前には実際には存在しませんでした。すべてのWindowsインストールにはすでに.netフレームワークが含まれていたため、数KBのexeファイルを配布するだけで済みました。基本的に.netフレームワークの書き直しであった.netコアを設計する際の問題の問題..これが、言及されたこれらのオプションが単純なハックであると言っている理由です、それらは設計ミスを修正するためにここにあります

https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.mdを読んだ後、提案にはさらに多くのステップがあるようですが、zip / unzipで終わらないので、そうではありません。負けた戦い、うまくいけば、チームはそのドキュメントに記載されているより軽いものを手に入れることができるでしょう、良いです！

このようなことが、WindowsがおもちゃのOSのままである理由です。

@kjkrum何のようなもの？

@cryruそれは彼らが何をしているのかわからないときに人々が言うことです。

@Cryruスタンドアロンの実行可能ファイルを構築できないことや、そうする必要があるという非常に現実的なことを忘れて却下することなどです。 存在する他のほとんどすべてのビルドシステムは、静的にリンクされた実行可能ファイルをビルドするだけでなく、依存関係の未使用部分を取り除きます。 依存関係の除去は、少なくとも10年間は​​標準機能でした。 コンパイラの発明以来の静的リンク。

@Cryruスタンドアロンの実行可能ファイルを構築できないことや、そうする必要があるという非常に現実的なことを忘れて却下することなどです。 存在する他のほとんどすべてのビルドシステムは、静的にリンクされた実行可能ファイルをビルドするだけでなく、依存関係の未使用部分を取り除きます。 依存関係の除去は、少なくとも10年間は​​標準機能でした。 コンパイラの発明以来の静的リンク。

同意します。これは、実際にはオペレーティングシステムでのC＃プログラムの位置に関連しています。
C＃プログラムは、常に第一級市民になることはできません。二流になるためだけに。

これは解決されました。
TLDR： dotnet publish -r win10-x64 /p:PublishSingleFile=true

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

これは解決されました。
TLDR： dotnet publish -r win10-x64 /p:PublishSingleFile=true

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

この機能はどのバージョンのdotnet-coreに追加されましたか？ 3.0.100-preview5-011568を使用していますが、次のエラーが発生しました。
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE：実際には機能していますが、 https：//github.com/dotnet/designs/blob/master/accepted/single-file/design.mdに構文エラーがあり、 dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true公開しているようです。 --self-containedを追加していません。

ありがとう@mihaimyhデザインドキュメントのタイプミスを修正します。

シングルexeの自己完結型機能にzip / unzipソリューションを使用することは常に反対
これは次の問題を引き起こすからです。
単一のexeファイルのサイズを減らす方法！

実際、最初からIL-Mergeと同様の方法を使用する必要があります。

議論があるべきではありません、これは時間の無駄です、誰もすべてを圧縮/解凍することを求めませんでした、それでも彼らはこのデザインを持って来て、彼らの時間と私たちの時間を無駄にしました

人々は単一の実行可能ファイルとAOTを要求し、Microsoftの時間を無駄にしないでください

AOTなしの単一ファイルが明示的に必要です。 リフレクション、ジェネリック、およびランタイムで生成されたコードを使用できるように、JIT機能を好みます。

MSは聞きたくないと思います

シングルexeの自己完結型機能にzip / unzipソリューションを使用することは常に反対
これは次の問題を引き起こすからです。
単一のexeファイルのサイズを減らす方法！

圧縮されているかのように、私にはわかりません。 それとも、冗長な依存関係を減らして、圧縮前にサイズを減らすことを意味していますか？

否定性を理解していない。 クイックテスト以外はまだ使っていません。 ただし、単一の実行可能ファイルは、アプリをクライアントにデプロイする状況やCLIツールとして適切に機能するようです。 ここで、この機能が役立つと思います。 それ以外では、Devまたは他の環境では、そのユースケースは見当たらないので、彼らが行ったことは今のところ解決策としてうまく機能します。

@RUSshy

MSは聞きたくないと思います

それどころか、彼らはあなたが関連するスレッドで見ることができる幅広いユースケースを求めて集めています。 あなたの意見は重要ですが、コミュニティの他の人の意見も同様に重要であり、それらを聞いてマイクロソフトを嘲笑するべきではありません。

あなたの声明に基づいて、あなたは私をマイクロソフトと間違えたのではないかと思います。 私はあなたのようなコミュニティのメンバーであり、マイクロソフトのことを一切話しません。

シングルexeの自己完結型機能にzip / unzipソリューションを使用することは常に反対
これは次の問題を引き起こすからです。
単一のexeファイルのサイズを減らす方法！

圧縮されているかのように、私にはわかりません。 それとも、冗長な依存関係を減らして、圧縮前にサイズを減らすことを意味していますか？

WebApi、MVC、またはConsoleAppを使用する場合は、HelloWorldを作成してください。 私の意味をよく知っています。
パックされたファイルが大きすぎます。コードが多すぎますが、実行されることはありません。
IL-Mergeの方法で未使用のコードブランチが削減される場合。

はい、確かに私はコンソールHelloWorldを実行しました、そしてはい、確かにその68K

自己完結型は67Kでした
しかし、そのC＃はアセンブリではありません。 <1K HelloWorldが必要な場合は、なぜc＃を使用するのですか？
大規模なアプリはより多くのフレームワークを使用するため、ある時点でフレームワークよりもカスタムコードが多くなります。
私たちは本当に数百Kについて心配していますか？ もしそうなら、フレームワークを使用して、最初からすべてを書くことに時間を費やさないでください？
ここで何が欠けていますか？

シングルexeの自己完結型機能にzip / unzipソリューションを使用することは常に反対
これは次の問題を引き起こすからです。
単一のexeファイルのサイズを減らす方法！
WebApi、MVC、またはConsoleAppを使用する場合は、HelloWorldを作成してください。 私の意味をよく知っています。
パックされたファイルが大きすぎます。コードが多すぎますが、実行されることはありません。
IL-Mergeの方法で未使用のコードブランチが削減される場合。

@sgfここには2つのやや別個の問題があります。

• アプリのコードを減らす方法は？
• アプリを1つのファイルにパッケージ化する方法は？

コード削減には、さらにいくつかの手法があります

• ILのマージ：プロセスでアセンブリIDが失われるため、これはすべてのアプリに当てはまるわけではありません。 これは、現在の単一実行作業の目標ではありません。
• 未使用のILのトリミング： ILLinkerは、未使用のILのトリミングを目的としています。 この機能はdotnetSDK（ PublishTrimmedプロパティ）に統合されており、ILLinkerでさらに多くの最適化が開発されています。
• Zip / Unzip：dotnet publishは現在、公開された単一ファイルをzipしませんが、圧縮することはできます。

アプリを1つのファイルにパッケージ化する方法は？
dotnet publishは、単一ファイルへの公開をサポートしています。公開されたファイルは、アプリと同じ大きさになります。

ネイティブコードの生成について：

• 現在、ネイティブコードの生成のサポートは、すぐに実行できるコンパイラ（ PublishReadyToRunプロパティ）を介して行われます。
• AOTコンパイルによる公開は素晴らしいですが（ CoreRT ）、まだ利用できません。 AOTコンパイルでも、実行可能ファイルのサイズはコンパイルオプションによって異なります。例：生成されたコードを実行するためのjitなどを含めますか？

はい、確かに私はコンソールHelloWorldを実行しました、そしてはい、確かにその68K

自己完結型は67Kでした
しかし、そのC＃はアセンブリではありません。 <1K HelloWorldが必要な場合は、なぜc＃を使用するのですか？
大規模なアプリはより多くのフレームワークを使用するため、ある時点でフレームワークよりもカスタムコードが多くなります。
私たちは本当に数百Kについて心配していますか？ もしそうなら、フレームワークを使用して、最初からすべてを書くことに時間を費やさないでください？
ここで何が欠けていますか？

ur imgが示すように申し訳ありませんが、自己接続されています。68626KB、約68mb = 68KK、68Kだけではありません!!!
<1kbは必要ありません（自己継続では不可能です）、<3000KBは問題ありません。
しかし、68MBは30倍以上です
いつもHelloWorldプログラムを書くだけではありません!!!

謝罪、Kの深夜の間違い
追加された説明/情報swaroop-sridharに感謝します、そこに私が気づかなかったいくつかの新しいスイッチ。
次のスイッチを使用して3.preview6で試してみました

dotnet publish -r RID / p：PublishTrimmed = true / p：PublishSingleFile = true
そして今29,000Kまで

確かに、すべてのアプリがHello Worldになるわけではありませんが、C＃Core SelfContainedアプリの場合、ランタイムも含まれています...個人的には心配する必要はありません。 確かに、あなたが小さなコンソールツールを書いているのなら、それを3Kにしておくといいでしょう。 しかし、そもそもなぜC＃を使用するのでしょうか。
みんなで面白い議論！

30mb LOL、1〜3mbのようなものになったら電話してください、ランタイムは膨満感でいっぱいです、GOをチェックしてください、人々は波に乗って移動します

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

kotlinでさえシェアを獲得し始め、kotlinネイティブではc＃を恥ずかしく思います

そして、SwiftはWindowshttps ： //forums.swift.org/t/swift-win32-programming/20686に来てい

だからここにいくつかの提案：

• リフレクションを削除するオプションを追加
• JITのものを削除するオプションを追加
• JITに依存しないように、C＃コードをより適切に最適化する

30mb LOL、1〜3mbのようなものになったら電話してください、ランタイムは膨満感でいっぱいです、GOをチェックしてください、人々は波に乗って移動します

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

kotlinでさえシェアを獲得し始め、kotlinネイティブではc＃を恥ずかしく思います

そして、SwiftはWindowshttps ： //forums.swift.org/t/swift-win32-programming/20686に来てい

だからここにいくつかの提案：

• リフレクションを削除するオプションを追加
• JITのものを削除するオプションを追加
• JITに依存しないように、C＃コードをより適切に最適化する

これは公平ではないと思います。 .NETは、最小の単一ファイルコンソールアプリケーションを構築するために設計されていません。 Asp.NetWebサイトおよびAPIに使用します。 したがって、フレームワーク自体は、含めることができる大量のnugetパッケージに加えて、大量の機能を備えています。 Webアプリケーションのサイズが50メガバイトまたは数百メガバイトであるかどうかが懸念されることは想像できません。 主な関心事は、速度、メモリ使用量、および長期的な保守性です。 サーバーのサイズを気にする人。

小さなシングルMBサイズのコンソールアプリケーションを構築することが唯一の目的である場合は、その仕事に適したツールを使用してみませんか。 フル機能のフレームワークが1つのファイルにパックされているアプリケーションは、「ハローワールド」でも数十メガバイトのサイズであると文句を言う代わりに、たとえばRustを使用してみませんか。

マイクロソフトは、.NETの開始以来、そして過去2年間でさらに多くのことを行っており、すばらしい仕事をしています。ありがとうございます。

そのようなナンセンス、嘘、効率性の欠如に何を答えるべきでしょうか？

あなたは.netコアの方向性がいかに間違っているかを理解できず、つい最近、彼らは配布/ ILマージ/ AOTに取り組んでそれを認識し始めました

そして今、Webアセンブリワゴンに移動することはできません。.netランタイムは非常に大きな肥大化であり、適切なサイズのファイルを展開できないためです。

そして、あなたはまだ「サーバーのサイズを気にする人」に固執しています。この考え方が、「現代的であると思われる」.netコアをすでに時代遅れで無関係な技術スタックにした理由です。

マイクロソフトは.netで素晴らしい仕事をしていません、彼らは.netフレームワークの互換性のために老人を喜ばせたかったので失敗しました、それは彼らの間違いの1つでした

失礼に聞こえたら申し訳ありませんが、時々変更を加える必要があります

失礼に聞こえたらごめんなさい

あなたは失礼に聞こえます、期間。 それと、あなたの解雇と結論へのジャンプは、説得力があるという効果はありません。

謝罪、Kの深夜の間違い
追加された説明/情報swaroop-sridharに感謝します、そこに私が気づかなかったいくつかの新しいスイッチ。
次のスイッチを使用して3.preview6で試してみました

dotnet publish -r RID / p：PublishTrimmed = true / p：PublishSingleFile = true
そして今29,000Kまで

確かに、すべてのアプリがHello Worldになるわけではありませんが、C＃Core SelfContainedアプリの場合、ランタイムも含まれています...個人的には心配する必要はありません。 確かに、あなたが小さなコンソールツールを書いているのなら、それを3Kにしておくといいでしょう。 しかし、そもそもなぜC＃を使用するのでしょうか。
みんなで面白い議論！

現代語として、世界を統一するという少しの野心があるべきではありませんか？
すべての開発者がC ++用にC＃を家に書き戻したいですか？ またはそれらをGo、Kotlin、Swiftにプッシュしますか？
市場シェアとc＃のさらなる侵食？

.Netは、クロスプラットフォームを実装していないため、素晴らしい開発の機会の最初の15年以上を逃しました。
しかし今、.netは正しい方向に戻っています。

ええ、私が前にコメントしたように、なぜ否定性なのかわかりません。
.Net Coreは、フルフレームワークを使用している場合は素晴らしいものです。 そして、.Net Standard + Coreの統合ビジョンは、賢明で進歩的だと思います。

.NETをGOまたは他の言語/フレームワークと比較することは無意味です。
とにかく、このトピックについては、Im OUTが取り組んでおり、Single .exe用に改善しているソリューションによって、数年前からの私の「質問」が非常にうまく解決されたと思います。

だからGuys＆Galsに感謝します！

アウト

このスレッドのすべての人に行動規範について思い出させたいと思います。

意見の相違や意見の相違は問題ありませんが、礼儀正しく、技術的な議論として表現しましょう。 強い言葉を使う必要はありません。
また、アイデアをターゲットにして、あなたの意見で実装することは公正なゲームです。 ただし、背後にいる人々を攻撃することは容認できません。 お互いに敬意を払い、さまざまな意見を聞き、強い発言や不快なコメントは控えましょう。

また、他の視点や意見にも心を開いていただきたいと思います。 判断を下す前に、通常、反対側の意見を聞くのは良いことです。多くの場合、物事が現状のままである理由の背後にある話があります。 アイデアや解決策を、なぜそのようになっているのかがわかっているときに突くと、通常は生産性が向上します。

ありがとうございました！

シングルexeの自己完結型機能にzip / unzipソリューションを使用することは常に反対
これは次の問題を引き起こすからです。
単一のexeファイルのサイズを減らす方法！
WebApi、MVC、またはConsoleAppを使用する場合は、HelloWorldを作成してください。 私の意味をよく知っています。
パックされたファイルが大きすぎます。コードが多すぎますが、実行されることはありません。
IL-Mergeの方法で未使用のコードブランチが削減される場合。

@sgfここには2つのやや別個の問題があります。

• アプリのコードを減らす方法は？
• アプリを1つのファイルにパッケージ化する方法は？

コード削減には、さらにいくつかの手法があります

• ILのマージ：プロセスでアセンブリIDが失われるため、これはすべてのアプリに当てはまるわけではありません。 これは、現在の単一実行作業の目標ではありません。
• 未使用のILのトリミング： ILLinkerは、未使用のILのトリミングを目的としています。 この機能はdotnetSDK（ PublishTrimmedプロパティ）に統合されており、ILLinkerでさらに多くの最適化が開発されています。
• Zip / Unzip：dotnet publishは現在、公開された単一ファイルをzipしませんが、圧縮することはできます。

アプリを1つのファイルにパッケージ化する方法は？
dotnet publishは、単一ファイルへの公開をサポートしています。公開されたファイルは、アプリと同じ大きさになります。

ネイティブコードの生成について：

• 現在、ネイティブコードの生成のサポートは、すぐに実行できるコンパイラ（ PublishReadyToRunプロパティ）を介して行われます。
• AOTコンパイルによる公開は素晴らしいですが（ CoreRT ）、まだ利用できません。 AOTコンパイルでも、実行可能ファイルのサイズはコンパイルオプションによって異なります。例：生成されたコードを実行するためのjitなどを含めますか？

必要に応じて、ネイティブDLLを1つの名前に動的にマージします：XXX.exe（UnManaged）。
静的分析を使用して、nativeDLLs（UnManaged）関数レベルリンクをコンパイルするときに分析します。

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

うまくいけば、結果はおそらく2〜3メガバイトになります。 それらすべてを7zipで直接パックすると、約4.85mbかかります。これでXXX.exeが取得されます。

IL-mergeを使用して同様の機能レベルリンクを開発します。
マネージDLLの場合も、同じ古いトリックです。
最後に、マネージDLLをPE.exeセクション（.netセクションとしてマーク）として埋め込みます。

リフレクトの場合、リフレクションタイプの分析DLL。 メタデータとリフレクションのタイプ（関数を含む）およびそのすべてのツリーを保持します-依存します。

申し訳ありませんが、これ以上の議論に時間をかけたくありません。意見を統一することはできません。
最初は結果を期待していました。 しかし今、私はおそらく私のニーズを満たすために他のプログラミング言語を検討する必要があります（多分Dlang多分Go多分Kotlin多分Nimまたは多分Rustが最高です）。

これを私と話してくれてありがとう。 しつこくてごめんなさい。 アウト

@sgfあなたはいくつかの良い点を指摘したと思いますが、あなたはこの承認したと思います。 あなたが求めている機能は、今後数年で.NETCoreに導入されると私は信じています。 実際、今日ファイルサイズを小さくしたい場合は、monoをターゲットにすれば可能かもしれません。

1. Monoは、ファイルサイズを削減するために、Linkingを使用したAOTコンパイルをすでにサポートしています。 これが、ブラウザの.netランタイム実装にmonoが選択された理由の1つです。 https://www.mono-project.com/docs/advanced/aot/そして私はBlazorプロジェクトがリンカーを持つことができる理由だと思います。

2. Microsoftは、.NETランタイムを1つの「すべて強力な」ランタイムに統合することを宣言しました。 あるものにはモノラル、他のものには.NET Coreを用意するのではなく、すべてのシナリオで提供できる単一のランタイムが必要です。 この事実は、AOTやリンク/コードストリッピングなどをサポートする必要があることを意味します。したがって、今後数年間で、.NET Coreランタイムがこれらの機能を取得するか、Monoおよび.NETCore機能が新しい機能に統合されると予想しています。ランタイム。

誰かがもっとよく知っているなら、私に知らせてください。

+ 2¢

問題は、多くの情報なしに決定が下されているように見えることはC＃からより良いAOT /展開性を備えた他の言語に移行しています。 これはかなり確立された事実であり、コミュニティで活動している場合に非常に明白になると思います。 それでも、それは決定に少しも影響を与えていないようです。

問題は、これがどの程度重要であるかを正確に誰も知らないようです。 個人的には非常に重要なので、もちろん偏見がありますが、全体的にこれが最も重要であり、MSがそれにふさわしい注意を払っていないようで、多くの人に印象を残しているという印象があります。彼らは統一された決定を下しているので、テクノロジー全体の将来について私たちに自信を持たせることはできません。

@RUSshyに同意します。 CoreRTは素晴らしいプロジェクトであり、間違いなく正しい方向に進んでいますが、全体として、すべての取り組みはサーバー/ Webテクノロジーに集中しているようです。 ランタイム、ジット、大きなバイナリのようなものは、その点でそれ自体を物語っています。 ソフトウェアを展開する人は誰もそれらを望んでいません。

そうは言っても、私はまだ技術を使用していますが、一部の分野ではその将来についてあまり息を止めていません。

個人的に期待しているのとは逆の方向に進んでいきたいと思います。 しかし、これまでのところ、それを考慮せずに決定が下されているようです。 サーバー/ウェブがお金を稼ぐものであり、プログラムを展開する人々は（少なくとも利益の点では）ごくわずかな少数派であるようですが、その場合、少なくともそれが彼らの決定の基礎になっていることを知りたいと思います（外から見ると、彼らはコインを弾いているように見えるからです。

@アラン-FGR

しかし、これまでのところ、それを考慮せずに決定が下されているようです。

詳細を知りたいので、共有するそのような決定の具体例はありますか。

MSは、現在のdotnetコアランタイムの欠点を十分に認識していると思います。そのため、MSは将来的にモノランタイムと同等の機能を求めます。

.net core3.0.0プレビュー6のリリースノートをご覧ください。

本日、.NET Core 3.0 Preview 6を発表します。これには、起動を改善するためのアセンブリのコンパイル、リンカーを使用したアプリケーションのサイズの最適化、およびEventPipeの改善に関する更新が含まれています。 また、ARM64でAlpine用の新しいDockerイメージをリリースしました。

私には、特定のシナリオではアプリケーションのサイズが重要であることを非常に認識しているようです。特に、Blazorが混在している場合はなおさらです。

@ Alan-FGR同意しました。IISの市場シェアが約8％で低下していることを考えると、Webの焦点はかなり奇妙です。 ASP.NETは無関係であり、C＃またはその標準ライブラリを改善してもそれが変わることはありません。 C＃は、コンソールアプリ、Windowsサービス、モバイルアプリ、およびPCゲームによって維持されています。 UnityとXamarinのおかげで存続しています。 C＃は開発するのに本当に楽しい言語なので、これは残念です。これは、MicrosoftがWindowsXPで最高水準を維持したとまだ考えている長年のJava開発者からの高い評価です。

必要に応じて、ネイティブDLLを1つの名前に動的にマージします：XXX.exe（UnManaged）。
静的分析を使用して、nativeDLLs（UnManaged）関数レベルリンクをコンパイルするときに分析します。

動的マージの意味はわかりませんが、ネイティブコンポーネントをホストと静的にリンクする計画があります。 このセクションを参照し

IL-mergeを使用して同様の機能レベルリンクを開発します。
リフレクトの場合、リフレクションタイプの分析DLL。 メタデータとリフレクションのタイプ（関数を含む）およびそのすべてのツリーを保持します-依存します。

アセンブリを1つにマージし、動的機能をサポートするためにサイドメタデータテーブルを用意するオプションについて説明しました。 それはかなりのサイズ節約を提供します。 しかし、それを実装するコストは非常に高くなります-新しいメタデータのサポートと、それを処理するためにデバッガー/プロファイラーなどで必要な変更のためです。

バイナリサイズを減らすための他のいくつかのオプションがあります-たとえば、単一のファイルを直接実行できる場合（ファイルに抽出する必要はありません）、各DLLの署名/証明書を削除して優先することができますアプリ全体に署名します。 これにより、数MBを節約できる場合があります。

しかし、これまでのところ、それを考慮せずに決定が下されているようです。

詳細を知りたいので、共有するそのような決定の具体例はありますか。

MSは、現在のdotnetコアランタイムの欠点を十分に認識していると思います。そのため、MSは将来的にモノランタイムと同等の機能を求めます。

@dazinator MSがどういうわけかMonoが何に対してもまともな解決策であると考えているという事実は、彼らが本当に彼らの製品を知らないことを示していると思います。 私はMonoを使用しましたが、これは重要な技術であり、.NETの普及に大きく貢献しましたが、確かに品質が不足しています... Xamarinは、技術を宣伝するための優れたマーケティング作業を行いましたが、それは過大な期待と過小評価に基づいていました。 MSでこれらの決定を下している人は、プロモーション資料の一部を見ただけで、実際に技術を使用したことはないようです。 一方、CoreRTは、これまでのところ大幅に過剰に提供されてきたテクノロジーです。 私の意見では、それは別のレベルの品質ですが、それでも、ガムテープと一緒に保持されていると思われるいくつかの技術を支持して、MSによって無視されています。

同意しましたが、IISの市場シェアが約8％で低下していることを考えると、Webの焦点はかなり奇妙です。 ASP.NETは無関係であり、C＃またはその標準ライブラリを改善してもそれが変わることはありません。 C＃は、コンソールアプリ、Windowsサービス、モバイルアプリ、およびPCゲームによって維持されています。

@kjkrumがポイントです。 ただし、おそらく彼らにとって、Webでの8％の市場シェアは、Windowsやモバイルアプリよりもはるかに重要です。 優れたWeb技術者は、少なくともWindowsサーバーの販売に役立つので、それに関心があることは明らかですが、それに焦点を当てることも非常に浅い戦略であり、それが彼らの決定を左右するものだとは信じません。 MSは、dotnet Foundationと非常に多くの有望なプロジェクトが進行中であり、正しい方向に進んでいるように見えましたが、支配的な技術を通過させる機会を与えているようです。

これは逸話的でおそらく意味がないことはわかっていますが、プロジェクトにC＃を使用していたすべての人（主にゲーム開発者）は、完全に解決可能な制限のために別の場所に移動しました。 彼らはRust、D、Go、C ++に移行しました。 私自身も定期的にC ++を使用しており、Rustを学んでいますが、高品質の製品を展開するのは後部の苦痛ですが、C＃の方がはるかに優れているため、個人的なプロジェクトではまだC＃を使用しています。

UnityとXamarinのおかげで存続しています。

はい、多くの技術的な問題があるため、祝福と呪いは何ですか。 たとえば、Unityの評判は非常に悪いですが、幸いなことに.NET / C＃には影響しなかったようです。
ただし、XNAは完全にはほど遠いものの、ユーザーと開発者の間で非常に高い評価を得ています。

今日、.NET Core3.0でこの土地を見ることができてうれしいです。 みんなありがとう！ 👍

それが人々が望んでいるものかどうかはわかりませんが、141mb exeである単純な計算機になってしまうと、機能は失敗します（そして、実際のコストは141mb * 2だと思います。これは、どこかで適切なものを抽出するためです）

はい、それは間違いなく私が欲しいものです。 それでも、通常の自己完結型の展開よりも小さいです。

より積極的なアセンブリトリミングとツリーシェイクは歓迎されますが、これは非常に便利なスタートです。 漸進的な改善は、価値を提供するための最も賢い方法です。

ああ、これはあなたが欲しいものですか？ 私の悪い、私は肥大化したアプリケーションが人気があることを知りませんでした

電卓はJITを必要とせず、Reflectionも必要ありませんが、それが必要なので、最初から間違っていると思います。プログラミングを停止する必要があります。

@RUSshy他の自己完結型のデプロイメントほど肥大化することはありませんよね？

JITとリフレクションの削除は、すべてが1つのexeにパックされているかどうかとは無関係です。 つまり、single-exeなしでJITとリフレクションを削除でき、JITとリフレクションを削除せずにsingle-exeを実行できます。 それらは別々の作品です。

それが人々が望んでいるものかどうかはわかりませんが、141mb exeである単純な計算機になってしまうと、機能は失敗します（そして、実際のコストは141mb * 2だと思います。これは、どこかで適切なものを抽出するためです）

ファイルをC：Users [YourUserName] AppDataLocalTemp.netに抽出します

単一のexeが解凍される場所を上書きする方法はありますか？
ユーザーが書き込み権限を持たない/ var / ....に抽出しようとすると、問題が発生しました。

@eivaこれはどのOSでしたか？ AWSラムダでしたか？
https://github.com/dotnet/core-setup/issues/7940は、この問題の修正を追跡してい

それまでの間、 DOTNET_BUNDLE_EXTRACT_BASE_DIR環境変数を設定して、バンドルされたファイルを抽出する場所を制御できます。

@ swaroop-sridhar返信ありがとうございます！
これは、「制限付き」サービスアカウントからのcentos.7起動アプリです。

@ jnm2あなたがC＃を愛してくれてありがとう、私もそうです。 しかし、正直に言うと、電卓が128メガバイトであるのは狂気です。

@TechnikEmpire 「

自分のコードとライブラリ、参照されているサードパーティのライブラリ、および.NET自体のツリーシェイクを実行できるようになるまで、個人的に完全に満足することはありません。 しかし、それが今日の私にとってシングルexe機能の価値を低下させるわけではありません。 それは一次元に沿った一歩です。 ツリーシェイクは独立した次元であり、私が多くの注目を集めることを望んでいます。