Runtime: 調査：ネイティブAOT

この問題に追加するのに最適なエリアラベルを見つけることができませんでした。 書き込み許可がある場合は、エリアラベルを1つだけ追加して、学習に役立ててください。

タイプミスのように見えます- * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply)多分それは「の一部」であるべきですか？

この問題を見てとてもうれしいです！ 😄🚀

質問：.NET Nativeツールチェーンを使用したことのあるUWP開発者の場合、これまでCoreRTを使用したことがない、または.NET NativeがCoreRTと多くの類似点（およびいくつかの共有コードもある）があるため、アンケートに回答する必要があります。メモでこれについて言及し、.NETネイティブでの経験に関して他のCoreRTの質問に回答しますか？ 🤔

@ Sergio0694UWPの質問に感謝します。 私は同意します。オープンソースバージョンを使用したことがある場合は、メモにそのことを記載し、usecorertに返信するのが理にかなっていると思います。

このアンケートを投稿していただきありがとうございます。

また、.NETネイティブのみを使用したUWP開発者として、特定の質問に答える方法についても混乱していました。 UWPの.NETネイティブツールチェーンについて多くの意見がありますが、それらを書き留める場所は実際にはわかりませんでした。 それがこの調査の範囲外であればまったく問題ありませんが、明確にする価値があるかもしれません。

また、「。NET NativeがUWPリリースビルドのデフォルトであり、ストアで必要なため」がAOTを使用する最も一般的な理由であると思われますが、質問5の事前入力された回答の1つではありません。

GUIオプションにAvaloniaを含めていただきありがとうございます:)以前にCoreRT + Avaloniaを試してみましたが、結果はゴージャスなネイティブGUIアプリでした：D2年前から互換性を維持していませんが...

.netの忘れられがちな部分はゲーム開発です。多くのプラットフォームでは、JITの実行が許可されていません。コンソールや、IOSデバイスについて考えてみてください。
ゲーム開発の将来にとって、.netエコシステムの第一級市民として.netネイティブAOTを取得することは非常に重要です。
一部のゲームエンジンは独自のAOTをロールバックしましたが（たとえば、Unityはil2cppを使用します）、これは絶対的な難破です。
したがって、公式の解決策は大歓迎です。 業界を変えるイベントかもしれません。
ゲーム業界は、利益と売上高の両方で映画業界を追い抜いていることを忘れないでください。
コンソールは、主な利益が得られている場所です。

公開アプリケーションを最適化するための既存のオプションは、.NETが現在対象としているほとんどのシナリオでうまく機能します。

..。

AOTは主にGUIアプリで重要です。 それはそれが焦点を合わせる必要があるところです。 それを必要とするウェブアプリやサービスなどは見当たりません

同意しません。 最高のエンドユーザーUXを実現するには、ゲームエンジン、サーバーレスマイクロサービス、デスクトップGUIアプリケーション、iOSおよびAndroidアプリケーション、 WASMベースのクライアント側SPA /ライブラリ、および基本的なCLIツール（数MB）に静的リンク付きのAOTが必要です。

過去数年間、C＃で上記のすべてのシナリオを試しながらコードを簡単にAOTコンパイルできることを望んでいましたが、RustのようなLLVMベースの言語と比較して.NETが大幅に欠落していると感じています。

現在の公開オプションが「うまく機能する」ように見える理由は、.NETが歴史的に上記のシナリオに適していないため、C＃を使用するときに独自のAOT（Unity、UWP、Monoなど）を実装するだけです。ネイティブイメージ（ReadyToRunなど）は、モノリシックサーバーアプリケーションまたは大規模なデスクトップクライアントアプリケーションのコールドスタートシナリオで「役立つ」可能性がありますが、バイナリサイズは、完全なAOTランタイムが生成するサイズよりも何倍も大きくなります。

.NETは、サーバーレス/コンテナ化されたマイクロサービスではすでに「うまく機能」していません。これらは、AOTコンパイル、バイナリサイズの削減、依存関係の最小化から大きな恩恵を受ける可能性があります。
現在のReadyToRun +ティアードコンパイル+ ILリンカーソリューションは、ブログ投稿でAWS Lambdaが推奨しているような、自己完結型のデプロイでは煩わしいファイルサイズの制限にすでに達しています。

本当の問題は、現在、独自の癖で利用できるランタイム/コードジェネレーター/ツールチェーン/実験が多すぎることです：IL2CPP /バースト（Unity）、MonoのAOTバックエンド（Xamarin / Blazor / Uno）、. NET Native / CoreRT（UWP）、 MonoのLLVMバックエンド、CrossGen / ReadyToRun（.NET Core）など。.NETに標準化されたAOTコンパイルツールチェーンがないことは、まったく受け入れられません。

これらすべてのチームが、CoreRT、 Mono LLVMバックエンド、または現在は廃止されているdotnet / lilicなどの一般的なものでエンジニアリング作業を組み合わせた場合、AOTは.NET開発者にとってはるかに優れたエクスペリエンスでした。

静的リンクを使用したAOTは、現在大衆向けのCI / CDを使用している多くの開発者がアクセスでき、パフォーマンスがわずかに向上するだけの煩わしさではなくなりました。

C＃エンドゲーム：ネイティブコード、ネイティブUI、高速で簡単な相互運用、ネイティブエクスポート、パフォーマンス指向のAPI（System.IO.Pipelines、System.Text.Jsonなど）。

私は、webappsはこれから利益を得られないという声明に同意しません。 AOTは、サーバーレスワークロード（別名Azure Functions）で大いに役立ちます。 CLIツールの起動時間によるメリットは言うまでもありません。

私は調査に回答しましたが、正直なところ、.NET Core 1.0が開始されて以来、状況がどこに向かっているのか明確な方向性がなければ、このような継続的な調査の質問は受けられません。

.NET Nativeは、Ext-VOSプロジェクトが開始されたときから、.NETがずっと存在していたはずのことであり、SingularityとMidoriからの経験があり、皆さんは確かに関係することができます。

Javaでさえ、不足しているAOT機能に追いつくことを決定しました。チームは、Javaを機能させたいワークロードを尋ねていません。

.NETリリース以降、コード品質の生成が改善されることはなく、展開ワークフローが他のAOTコンパイル言語と比較して面倒であるため、NGENはほとんど使用していません。

したがって、今後、AOTは.NETから再び削除され、マネージド言語でのすべての競争は現在AOTツールチェーンに集中していると見なされ、コンパイラを使用するワークフローも尋ねられません。

シナリオに関係なく、.NETが引き続き繁栄し、最初のオプションになることを望んでいます。Microsoftがワークフローを引き継ぐために、他のAOTコンパイル言語では問題がない.NETと一緒にC ++を使用するように強制されます。

私は調査に回答しましたが、正直なところ、.NET Core 1.0が開始されて以来、状況がどこに向かっているのか明確な方向性がなければ、このような継続的な調査の質問は受けられません。

MSが私たちが何を望んでいるのかを指示するだけでなく、コミュニティに耳を傾けようとしているのは素晴らしいことだと思います。

@jkotasこの調査の2つの異なるリンクが広がっていることに気づきましたが、大丈夫ですか？
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruceは、クロスプラットフォームGUI、WCF、およびEFツールサポートに関する同様の調査に回答した他の開発者に、それがどれだけ役立ったかを尋ねます。

ですから、彼らが私たちに尋ねるのは良いことですが、実際に行動が起こったときのほうがいいでしょう。 クロスプラットフォームのGUIの場合でも、MAUIが実際に発生するのか、それともWebウィジェットのBlazorが解決策として押し出されるのかはまだわかりません。

私にとって唯一受け入れられるAOTソリューションは、リリースモードでJITがまったくない（すぐに実行できるサイドバイサイドソリューションエイリアスがない）真のネイティブアプリケーションを生成し、すべての¹.NETプロジェクトで機能する場合です。の上。 これには、特にWinformsとWPFが含まれます。 最良の場合、3MBから80MBに肥大化することなく、ランタイムの依存関係なしにスタンドアロンでも動作するはずです。

¹技術的な理由により、AOTがサポートできないケース/ APIが存在する可能性があります。 「すべて」とは、すべてのAPIをサポートするのではなく、すべてのプロジェクトの種類をサポートすることを意味します。.NETCoreは次をサポートします。dll/ winforms / wpf / winui / console / maui / ...開発者が既存のアプリケーションを引き継ぐことは、私が念頭に置いていることです。

_私はDelphiでアプリケーションも作成しましたが、コンパイルしてから、単一のDelphi実行可能ファイルを別の場所に出荷すると、実行されるだけでバグが発生します。 そして、そのちょうど速い。 特定の方法でコンパイルされた場合、同じことがC ++アプリケーションにも当てはまります。 また、両方のアプリケーションをデバッグすることもでき、PDBを含めることにした場合でも、両方のアプリケーションが有用なスタックトレース/ダンプを提供します。 ただし、セキュリティ上の理由から、これを含めないこともできます。これも問題なく機能します。 なぜC＃でそれができないのかと自問するのは私を悩ませます。 AOTの計画について聞いたとき、私はこれを期待していました。_

リフレクションの問題は常に多く言及されていますが、ASP.netコアが大きな実行可能ファイルを生成する場合は実際にはそれほど重要ではないと思います。

AOTが厳しい要件となる場所のほとんどは、CLIツール、ゲーム、UIアプリケーションなどです。これらは、どのライブラリを含めるかを慎重に検討し、リフレクションの問題の一部を回避することができます。 優先順位は、「クリーンスレート」アプリケーションを有効にすることです。

リフレクションの問題は常に多く言及されていますが、ASP.netコアが大きな実行可能ファイルを生成する場合は実際にはそれほど重要ではないと思います。

Blazor WebAssemblyのリリースにより、実行可能ファイルのサイズと実行速度が非常に重要になり、AOTの恩恵を受けることができると思います。 しかし、何らかの理由で、それは調査で具体的に言及されていませんでした。

はい、かなりお願いします！ メモリの安全性を維持し、ネイティブの速度を実現し、コードをネイティブで呼び出し可能にするために、RustまたはCoreRTの使用を検討していました。 しかし、AOTが.NETに含まれていると、信じられないほどリッチでパワフルになり、Rustは素晴らしいものの、移行が容易ではないため、素晴らしいでしょう。

@jkotasこの調査の2つの異なるリンクが広がっていることに気づきましたが、大丈夫ですか？

はい、投稿ごとに異なるSurveyMonkeyリンクを使用しています。 すべてのリンクは同じ調査を指しています。 これにより、人々が調査を見つけた場所によって回答の分布がどのように変化するかを確認できます。

gamedevの場合、これが必要です。c++を使用するネイティブエンジンを優先して、ゲームエンジンhttps://github.com/amerkoleci/alimer_sharpでの作業を中断しました。また、DirectXとvulkanのバインディングも維持しています。ここで、パフォーマンスが必要です。

gamedevの場合、これが必要です。c++を使用するネイティブエンジンを優先して、ゲームエンジンhttps://github.com/amerkoleci/alimer_sharpでの作業を中断しました。また、DirectXとvulkanのバインディングも維持しています。ここで、パフォーマンスが必要です。

ここで同じシナリオ😄、ただし、一時停止しませんでした。 私はAOTが好きです。起動時間の短縮だけでなく、（そして私の場合はもっと重要なことですが）コードをより最適化する機会もあります。ビルド時間が50％増加し、10％のスピードアップが得られますが、これは明らかにそうではありません。本当にJITの態度

ビルド時間が50％増加し、10％の高速化が実現しましたが、これは明らかにJITの姿勢ではありません。

これは、実際には、別のエコシステムに切り替えるのではなく、.NETでAOTが必要な大きな二次的な理由の1つです。 大規模なC ++またはRustプロジェクトと比較して、大規模な.NETプロジェクトのコンパイル時間が速いことに完全に甘やかされています。

開発中の高速イテレーションにはJITが必要ですが、顧客に何かを出荷したらAOTになります。

CoreRTを使用してクロスプラットフォーム（およびクロスプラットフォーム）のネイティブライブラリを作成しました。

静的リンクを使用したAOTは、jitを無効にし、複数のaotコンパイルモードが必要なiOSおよびコンソールプラットフォームのゲームエンジンに緊急に必要です。

1. 完全なaot
2. jit + aotまたはインタープリター+ aot実行モードをサポートするハイブリッドaot
   ハイブリッドaotはゲーム業界にとって非常に重要であり、ゲームチェンジャーになる可能性があります

静的リンクを使用したAOTは、jitを無効にし、複数のaotコンパイルモードが必要なiOSおよびコンソールプラットフォームのゲームエンジンに緊急に必要です。

1. 完全なaot
2. jit + aotまたはインタープリター+ aot実行モードをサポートするハイブリッドaot
   ハイブリッドaotはゲーム業界にとって非常に重要であり、ゲームチェンジャーになる可能性があります

iOSプラットフォームのモノラルのように、aot + interpreter実行モード。

完全なAot、単一のexe、独立したランタイム、不要なコードのクリッピングは間違いなく私をkreygasmXDにします

私はこの質問を10年間待っていました。 くそー、私はハードドライブにほこりを集めている5つのクールなプロジェクトを持っています。なぜなら、それらを解放すると、子供はそれらを元に戻し、GUIに少し変更を加えて、自分のものとして販売できるからです。

私はPCプラットフォームでUnityを使用してRobocraft、Cardlife、Gamecraftを開発しましたが、ゲームサーバーであっても、必要な場合（Xbox oneを読む）を除いて、IL2CPPを使用する必要はありませんでした。 個人的には、パフォーマンスが必要な場合は、JITコンパイルとバースト（明示的な組み込み関数を使用して実行できるよりも優れた仕事をする）のようなソリューションを組み合わせるだけで十分だと思います。 ただし、完全にネイティブなコードを必要とするプラットフォームや、ハードウェアリソースが貴重なプラットフォームには、AOTが必要であることを理解しています。 .netプラットフォームの開発者がAOTについてさまざまな感情を抱く可能性があることは理解していますが、ゲーム開発でより広く採用されることを望んでいるのであれば、それは選択肢ではないと思います。 正直なところ、UnityがIL2CPPやBurstなどのテクノロジーを独占しているのは少し怖いです。

高性能で拡張性の高い金融/科学シミュレーターを開発しています。 私たちのシミュレーションは、ユーザーが作成するモデルの複雑さに応じて、数分から数日までどこでも実行できます。

シミュレーションソフトウェアの性質上、起動時間やソフトウェア/バイナリのサイズが問題になることはほとんどありません。 さらに言えば、製品のインストールにかかる時間でもありません。 たとえば、コンパイルがインストールの一部である場合、そのようなプロセスに長い時間がかかったとしても、それは私たちにとって完全に受け入れられます。

実行中のコードの約25％が動的に作成されるため、ハイブリッドアプローチが推奨されます。 AOTとJITコンパイルのいくつかの組み合わせ。 動的ビットを解釈する必要がある場合、少なくとも私たちのユースケースでは、AOTの利点の多くが損なわれると思います。

GCは、より高いスケーラビリティを達成することを妨げる最大の問題です（たとえば、約44コアを取得した後）。 コンパイラーがより詳細なアセンブリー間最適化、積極的なインライン化、およびエスケープ分析を実行できるようにすることで、ヒープではなくスタックに、より短期間のオブジェクトを割り当てることができる場合があります。

コードベースには、特にレジスタ割り当てや多くの構造体の処理でJITコードの品質がボトルネックになる場所がたくさんあります。 これにより、JITコンパイラを操作して正しいこと（壊れやすく、難読化され、維持するのが難しい綱引き）を実行するコードを記述したり、ネイティブコードにドロップしたりする必要があります（インライン化の欠如から多くのメリットが失われます）。およびGC / PInvoke遷移からのオーバーヘッド）。

場合によっては、コード品質を少し改善するだけで、多数のコアで何時間も実行されるモデルの過程で、クレイジーな勝利を収めることができます。 私たちにとって、JITは、開発に伴ってコードベースが変化するため、パフォーマンスに関して少し脆弱になりました（決定論的ではありません）。 AOTコンパイラが、はるかに高品質のコードのコンパイルと生成にはるかに長い時間を要し、これらの不要なパフォーマンスの変動の一部を減らし、C＃でより多くのコードベースを維持できるようになることを願っています。

一般的に、JITテクノロジーとAOTテクノロジーの両方にもっと投資してもらいたいと思います。

cc @AndyAyersMS

静的リンクを使用したAOTは、iOSおよびコンソールプラットフォームのゲームエンジンでjitを無効にするために緊急に必要です。

私はここで完全に同意します。 この問題（Unity以外のプロジェクトのゲームコンソールで実行されているC＃コード）の解決策が必要なため、Mono-AOTベースのツールチェーンを使用しています。 しかし、それはいくつかの深刻な制限があり、それをうまく実行しません。

そのため、3つのポプラゲームコンソール（XBox One、PlayStation 4、Nintendo Switch）でCoreRTを実行することを検討しています。 コンセプトの最初の教授は、それが実際に機能することを示していますが（まだいくつかの制限があります）、Monoベースのソリューションと比較して実行時のパフォーマンスが大幅に向上しています。

しかし、ゲーム機を取り巻くNDAの状況では、この使用原因に対する公式のサポートは、最初に公式のネイティブAOTを取得するよりもはるかに適切に取得されます。

私たちにとって、JITは、開発に伴ってコードベースが変化するため、パフォーマンスに関して少し脆弱になりました（決定論的ではありません）。

@ jpapp05あなたのアプリ、特に上記の問題についてもっと知りたいのですが、それは私の重要な関心事の1つです。 それが助けになるなら、オフラインで（プロフィールの電子メールを介して）私に連絡してください。

こんにちは@AndyAyersMS 、それは素晴らしいことです。 もう少し自由に話すことができるので、オフラインで連絡しますが、他の人の利益のために、私たちの議論からの要約を投稿できてうれしいです。

これが問題であるかどうかはわかりませんが、ここで言及するだけです。
私たちにとって重要な機能は、実行時にネイティブアセンブリを動的にロードおよびアンロードする機能です。

@movedoaはNativeLibrary APIを参照https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

私の最大の問題は、少なくとも私がテストした限りでは、UWP Nativeを除いて、通常.NETを簡単に逆コンパイルできることです（正しいことを願っています）。 「通常の」会社の考え方ではなく、誰かがプロジェクトに大量のIPを入れて、簡単に逆コンパイルできるようにします。
Linuxは問題ありませんが、すべてのデスクトップアプリケーションはエンタープライズ向けのWindows用です。

たぶん、生活を楽にするために、次のようなチェックボックスを入れてください。
ネイティブコンパイル（WINDOWS 10デスクトップでのみ機能します！）
男、そうすれば、私はもうAOTを気にしません。 ASP.NET Coreで機能する場合は、かっこいいです。 そうでなければ、私は本当に気にしません。

ちなみに、質問をしてアンケートを作ってくれてありがとう、テクノロジーを使っている人たちに意見を聞いてくれて、とても良かったです。 （実際、私は確信していますが）Githubで通常はこのことに関与しないデスクトップ開発者の意見をまだたくさん見逃していると思います。 .NETコードは簡単に逆コンパイルできることを誰もが覚えている（または知っている）わけではありません。彼らが知っていれば、上司は気が狂うでしょう： grin:。

.NETコードは簡単に逆コンパイルできることを誰もが覚えている（または知っている）わけではありません

Shhh ... Unityまたはサードパーティのパッケージの舞台裏で何かがどのように機能するかを理解しようとしているときに、Riderが自動的にこれを行うという事実は驚くべきことです。 そもそも多くのコードがオープンソースであるため、今ではそれほど重要ではありませんが、私が言っていることは理解できます。

@jcbepplerあなたは間違っています、それはバイトコード対ネイティブの一般的な誤解です、それはちょうど正しいツールを持っていることの問題です。

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Raysは単なる可能な解決策であり、他にも選択できるものがあります。

@MostHatedええ、わかりました。 実際、.NETでソフトウェアを逆コンパイルするのは非常に簡単なので、オープンソースのようであり、多くの企業はソフトウェアがオープンソースであることを望んでいません。 「フリーランチのようなものはありません」😄

@pjmlp逆コンパイルと逆アセンブルの違いを知っています。 私は自分のソフトウェアを分解することに対して何もできませんが、ネイティブコンパイルは、人が非常に単純な逆コンパイルを行うことができないため、ソフトウェアをはるかに安全にすることができます。 逆アセンブルされたソフトウェアは間違いなく奇妙に見え、逆アセンブルされたコードは正しく実行されない可能性があります。

@jcbepplerあなたは間違っています、それはバイトコード対ネイティブの一般的な誤解です、それはちょうど正しいツールを持っていることの問題です。

現在、逆コンパイルされた.NETプログラムは、ソースコード全体を明らかにします。 これには、すべてのメソッド名と変数名も含まれます。 これはデバッグに最適であり、例外が発生したときに「読み取り可能な」スタックトレースを作成できます。 しかし、それは巨大なセキュリティ上の欠陥であり、.NET難読化ツールの巨大な市場がある理由です。

ネイティブアプリケーションは分解できます。 しかし、完全なC ++ / Delphiなどのソースコードを明らかにすることはできません（このソースコードを再構築しようとするツールがいくつかありますが、結果はひどいものです）。 得られるのは、せいぜいアセンブラコードと制御フローチャートです。 運が良ければ、シンボルファイルが付属していますが、関数名も取得できますが、リリースモードでは、セキュリティ上の理由から、このシンボルファイルは通常含まれていません。

ネイティブコードが実際の保護である方法についての詳細に没頭する可能性があります。 私の意見では、クラッキング（完全なメソッド/変数名と完全なC＃ソース生成のおかげで、特別な知識を必要とせずにライセンスチェックを削除できます）やデバッグの観点からの保護ではなく、スティーラーに対する保護です。 dnSpyのようなツールは、シングルクリックで.NETアプリケーションを完全なVSプロジェクトにエクスポートすることもできます。 ネイティブコードで同じように機能するツールはありません。 したがって、商用アプリケーションの場合、最終的なアプリケーションのすべてのメソッドと変数の名前を変更するだけで、年間数千ドルを支払う必要がなくなるという事実に加えて、ネイティブコードを生成することは大きなメリットになります。

この調査の結果に興味があります。 人々がどのように投票したかについて彼らを公表する計画はありますか？

@Symbai IPを保護する手段としてNDKを使用しようとしたAndroid開発者なら誰でもわかるように、これは何に対する保護でもありません。 簡単に説明したアプリケーションは、シングルクリックで同じことを実行できます。通常、元のソースコードとしてCまたはC ++コードを想定していますが、アルゴリズムを盗むには十分です。

.NETがRust、Go、Swift、C ++、Java（GraalVM）、デスクトップ、コンソール、および起動時間が非常に重要なモバイル/ IoTアプリケーションに対して長期的に失われるシナリオでは、AOTが必要です。メモリ使用量には高い制約があります。また、一部のASP.NETシナリオと同様に、アセンブリの負荷に対するJITによる速度の低下は許容できません。たとえば、100個のK8Sポッドインスタンスをスケーリングする場合は、AOTコードが関連する可能性があります。

一方で、JITが進むべき道であるシナリオでは、JIT機能を維持し、それらを改善することにも関連性があると思います。

両方のコンパイルモデルを提供する言語はたくさんあり、ユーザーが状況に応じて選択できるようにするため、基本的にJITを維持し、NGENという臆病な試みを忘れながらAOTストーリーを.NETネイティブの方向に改善します。

@Symbai IPを保護する手段としてNDKを使用しようとしたAndroid開発者なら誰でもわかるように、これは何に対する保護でもありません。 簡単に説明したアプリケーションは、シングルクリックで同じことを実行できます。通常、元のソースコードとしてCまたはC ++コードを想定していますが、アルゴリズムを盗むには十分です。

私が生きることができるアルゴリズムを盗むことはできますが、今日の.NETで許可されているもの（WPFなど）ではありません。このアルゴリズムでは、完全なアプリケーションを美しく簡単にVSプロジェクトとして実行する準備ができています。 ネイティブコンパイルを使用したUWPは良い仕事をしていると思います。誰かがそれを逆アセンブルしたい場合は、幸運を祈ります。 何があっても、私は常にネイティブコンパイルを使用します。 Androidの世界について話すことはできません。XamarinFormsでAOTを一度試してみましたが、期待どおりに機能しませんでした。

ネイティブコンパイルを使用したUWPは良い仕事をしていると思います。誰かがそれを逆アセンブルしたい場合は、幸運を祈ります。 何があっても、私は常にネイティブコンパイルを使用します。 Androidの世界について話すことはできません。XamarinFormsでAOTを一度試してみましたが、期待どおりに機能しませんでした。

ネタバレ-あなたの情報源を手に入れようとしている人々は、おそらくあなたを引き裂くのではなく、あなたと改善/拡張/統合しようとしています。 彼らがあなたを引き裂こうとしているのなら、あなたの測定基準は本当にばかげています。

私が本を書いたら、それを出版する前に誰かに日本語に翻訳してもらいましょう。私は日本語がわからないし、友達も理解できないので、私は本当に賢いと思うかもしれません。 しかし、現実には、その本を読むことができる国は世界中にあります。私は、他のふりをしているとしたら、自分をだましているだけです。

これは、ネイティブバイナリを分解した経験がなく、スターシチズンの暗号化とデータ形式をリバースエンジニアリングすることにした開発者として言います。

経験のない私は、暗号化されたデータファイルを復号化できるだけでなく、独自のデータ形式をXML / JSONに変換できるプログラムを作成するまでに、2週間かかりました。

この2週間後、完全なアプリケーションをVSプロジェクトとして実行する準備ができていない可能性がありますが、その必要がないこともわかりました。 自分のコードを既存のアプリケーションに挿入する方がはるかに簡単で、すべてのコードを処理する必要はありません。

暗号化されたデータファイルを復号化できるだけではないプログラムを持つことに

暗号化はまったく異なるものです。 ビデオゲームを逆コンパイルしてMODを作成することは、まったく別のことです。 ほとんどのゲーム開発者は、ファンがModを作成してもかまいません。むしろ、ゲームへの情熱と愛情を示しています。 そして、おそらく「暗号化」は暗号化ではなく、ファイルはより小さなサイズでパックされただけでしたか？ 何千もの単一ファイルをディスクに保存する必要がないため。 パフォーマンスも理由である可能性があります...ディスクから多くの小さなファイルを読み取ることは、1つの大きなファイルを読み取るよりも遅くなります。 そして2週間後、パックされた画像を解凍することができました。 一部のデータファイル内のテキストを変更することができました。 これは素晴らしいことですが、私のような人々がJITを取り除きたい理由ではありません。

私たちが今抱えている問題は、JITコードを完全に逆コンパイルして完全なソースコードにすることができるということです。Javaには他のJIT言語と同じ問題があります。 ネイティブコードは逆アセンブルでき（これによりマシンコードがアセンブリコードに変わります）、ネイティブアプリケーションを十分な余裕を持ってクラックできます。これはすべて当てはまりますが、ネイティブコードをコンパイルして完全なソースコードにすることはできません。 dnSpy for C ++コードのようなツールを見たことがありますか？ Delphiコード？ 私はしていません。 変数名とメソッド名を取得できないため、正しくコンパイルすると単純に存在しなくなります。 逆アセンブリをC ++に変換して、コンパイルできる完全に機能するプロジェクトを生成することはできません。 これはあなたにとってそれほど重要ではないように聞こえるに違いありませんが、商用アプリケーションにとっては非常に大きなことです。 .NETアプリケーションは、知識がまったくない人なら誰でも読むことができるオープンブックであるという事実を取り除きたいだけです。 私たちが数千ドルを研究に投入するとき、私たちは誰もがそれを見て、数秒以内にそれをコピーすることを望んでいません。 すべての変数とメソッド名の名前を変更することだけが目的である難読化ツールに数千ドルを支払うことをなくしたいので、アプリケーションを開いて「ライセンス」を検索してすぐにアクセスすることはできなくなります。 その（しかしほとんど）難読化のコストだけでなく、難読化が追加の問題を引き起こすこともあります。 特に.NETCoreのリリースの頻度で、私はこれに頻繁に遭遇しました。 難読化ツールを最新の.NETCoreバージョンで動作させるパッチを待つだけで数週間待たなければなりませんでした。

そして、開発者としてこれらすべての問題に直面している間、あなたはまたあなたのビジネスマネジャーにそれらを説明しなければなりません。 ある時点で、彼は別のプログラミング言語を選択する方が良いのではないかと尋ねるかもしれません。

C ++とDelphiを使用すると、この問題は発生しません。 これは誰にとっても問題ではないことを私は知っています。 オープンソース開発者は、JITがより面白くて便利だと感じるでしょう。 開いた本の方が優れていると信じているのに、なぜ誰かが自分のソースコードを閉じた本にしたいのかを説明するのは難しいです。 したがって、理想的には、完全に異なるビューを互いに説明する必要はありません。AOTは、必要に応じてリリースモードでオンにできるスイッチにすぎません。 そして、あなたが望まないのであれば、JITを進めてください。

.NETチームがAOT❤を必要とする理由として「保護」を選択させてくれたことに本当に感謝しています。 それは、彼らが何人かの人々が持っているニーズを認識していることを示しています。 そして、世論調査で人がそれに投票することが明らかになった場合、AOT実装がC ++コンパイラと同じ方法でこれを処理する可能性が最終的にあるかもしれません。 参考：AOTが実際にどの程度保護されているかについてこれ以上議論しないように引用符で囲んでいます。すでにお気づきかもしれませんが、これについては非常に幅広い見解があります。

セキュリティはすべてかゼロかではありません。 ILを削除しても、特定の攻撃者がアプリケーションを元に戻すことを防ぐことはできません。 しかし、それは実際的な意味で関連性のあるハードルを生み出します。 多層防御です。 これが、IL難読化製品の使用が合理的である理由です。

私の友人は、ILをC＃に逆コンパイルし、かなり些細な変更を加えることで、.NET製品をクラックしました。 彼はネイティブアプリケーションをクラックすることはできません。 それははるかに難しいです。 彼はまた、逆コンパイラツールがそれらのバイナリでクラッシュしたため、IL難読化ツールの存在下で諦めなければなりませんでした。 繰り返しますが、これらの製品は実用的な意味で保護されていました。 動いた。

@Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-RaysはCに適しています。また、意思決定プロセスを支援するマクロがあります。

Cソースがあるので、C ++またはDelphiに変換するのは子供向けの遊びです。

さらに、今では十分に熟練していない人を支援するAIがあります。

ストリップされたバイナリのニューラルリバースエンジニアリング

Hex-RaysはCに適しています。また、意思決定プロセスを支援するマクロがあります。

あなたはHex-Raysで働いていますか、それとも難読化ソフトウェアを販売している会社で働いていますか？ どうやら。

とにかく、それをCに変換しても、コードは優れたC＃アーキテクチャからはほど遠いものになります。 コードの一部を入手したとしても、変更や改善などを行うには、かなりの労力を費やす必要があります。
ネイティブコンパイルが関係ない場合は、OKです。 しかし、多くの人にとって、それは適切です。

ところで、あなたはJITコンパイルを維持することに非常に興味を持っているように見えます。また、ソフトウェアの逆アセンブルに多くの経験があるようです。 なぜ、どこでそれを使わなければならなかったのだろうか？

ILとマシンコードの逆コンパイルの容易さについてどのように感じているかにかかわらず、それが実際のビジネスでの実際の要件であるという事実は変わりません。 （そして、牛が家に帰るまで、その要件がどれほど有効か無効かについて議論することができます。）

私の以前の雇用主は、この理由から、.NETまたはJVMツールを外部に出荷することを明示的に禁止していました。 私が去る直前に、あるチームは、高度な難読化が適用されたツールを出荷できるように高官を説得しましたが、それ以外の場合は、企業ポリシーを満たすためにC ++で外部ツールを作成していました。

この議論は軌道に乗っていません。 AOTがIP保護に関連しているかどうかについて炎上したい場合は、別の場所で行ってください。

Hex-RaysはCに適しています。また、意思決定プロセスを支援するマクロがあります。

あなたはHex-Raysで働いていますか、それとも難読化ソフトウェアを販売している会社で働いていますか？ どうやら。

とにかく、それをCに変換しても、コードは優れたC＃アーキテクチャからはほど遠いものになります。 コードの一部を入手したとしても、変更や改善などを行うには、かなりの労力を費やす必要があります。
ネイティブコンパイルが関係ない場合は、OKです。 しかし、多くの人にとって、それは適切です。

ところで、あなたはJITコンパイルを維持することに非常に興味を持っているように見えます。また、ソフトウェアの逆アセンブルに多くの経験があるようです。 なぜ、どこでそれを使わなければならなかったのだろうか？

それどころか、私はネイティブコードをサードパーティがさらに使用できるソースコードにリバースエンジニアリングするスキルを持っているので、ネイティブコードへのコンパイルはスクリプトキディのハードルにすぎないことを十分に認識しています。ここ。

編集：私のコメントも停止します。 個人的な攻撃に返信したかっただけです。

クラウドネイティブとWPFはAOTである必要があります。
Windowsクライアントランタイムなし！ JITなし

調査の結果は投稿されています-https：//github.com/dotnet/runtime/issues/41522。 現在、連絡先情報を提供してくださった方々にフォローアップを行っており、追加のフォローアップ質問があります。

静的リンクを使用したAOTは、iOSおよびコンソールプラットフォームのゲームエンジンでjitを無効にするために緊急に必要です。

私はここで完全に同意します。 この問題（Unity以外のプロジェクトのゲームコンソールで実行されているC＃コード）の解決策が必要なため、Mono-AOTベースのツールチェーンを使用しています。 しかし、それはいくつかの深刻な制限があり、それをうまく実行しません。

そのため、3つのポプラゲームコンソール（XBox One、PlayStation 4、Nintendo Switch）でCoreRTを実行することを検討しています。 コンセプトの最初の教授は、それが実際に機能することを示していますが（まだいくつかの制限があります）、Monoベースのソリューションと比較して実行時のパフォーマンスが大幅に向上しています。

しかし、ゲーム機を取り巻くNDAの状況では、この使用原因に対する公式のサポートは、最初に公式のネイティブAOTを取得するよりもはるかに適切に取得されます。

@RalfKornmannEnvision LLVMcodegenでXamarinXbox One / PS4 Monoポートを使用していますか？

@RalfKornmannEnvision LLVMcodegenでXamarinXbox One / PS4 Monoポートを使用していますか？

@lateralusX統合は他の誰かによって行われたので、詳細はわかりません。 しかし、私が知る限り、彼らはXBox One / PS4に提供されているモノラルポートを使用し、スイッチ用のシンプルなポートを作成しました。 彼ら自身。

@RalfKornmannEnvision連絡を取り、これに関連する経験について話し合うのは素晴らしいことです。 LLVM codegenは（プロジェクトによっては）生成されたコードに非常に良いパフォーマンス効果をもたらすため、それが使用されなかった場合（有効にする必要があります）、通常は有効にするだけで多くのメリットがあります。 あなたはDotNetEvolutionの不和サーバーを使用していますか？もしそうなら、これに関連してオフラインで議論することができますか？

@lateralusXこれに取り組んだチームメンバーは、LLVM codegenを有効にし、他のことを試したと確信しています。 別のプロジェクトに移る前の彼らの最後の声明は、これが彼らができる最善のことであるということでした。

調査の一環として、Xamarin Androidを使用してコアコンポーネントでベンチマークを作成し、Tegra X1ベースのデバイスで実行して、Monoのカスタムスイッチポートの問題が原因でパフォーマンスが低下したかどうかを確認します。 残念ながら、Xamarinプロジェクトのパフォーマンスは、Switchで見たものとそれほど変わりませんでした。

申し訳ありませんが、私はこの不和サーバーに参加していません。正直なところ、現在のMONO統合について私が知っていることはそれほど多くありません。 私の見解では、とにかくこのプロジェクトの行き止まりです。 現在のCoreRTプロトタイプ（公式サポートはさらに少ないですが）は、パフォーマンスと使いやすさに関してはすでにはるかに優れています。

@RalfKornmannEnvision OK、あなたの情報とフィードバックに感謝します、すべて非常に貴重です。