まず、質問に「c++」というタグが付けられており、C++/CLI について何度か言及されているため、「Visual Basic 2010」は「Visual Studio 2010」のタイプミスだと思います。しかし、アプリケーションを Visual Basic (VB.NET) で作成した場合でも、C++/CLI で作成した場合でも、問題はまったく同じです。
私の推測では、実行可能ファイルは、この環境で読み込まれない特定の依存関係なしでは実行できませんが、PE で動作する必要があります。
その通りです。.NET Frameworkを対象とするアプリケーションを作成しました。JVM を必要とする Java アプリケーションと同様に、.NET アプリケーションを実行するには、.NET Framework (またはMonoなどの互換性のある代替実装) をインストールする必要があります。残念ながら、Windows PEは .NET Framework をサポートしていません。
WinForms、WPF、またはコンソール アプリケーションを作成したかどうかは関係ありません。UI の表示方法は大きく異なりますが、いずれもインストールされている .NET Framework に依存しています。
.NET Framework に依存せずにネイティブ コードを生成する別のプログラミング言語でアプリケーションを (再) 作成する必要があります。C と C++ が一般的な選択肢です。C++ を使用する場合は、Visual Studio が "Win32" プロジェクトと呼ぶものを必ず作成してください。これは、基盤となるオペレーティング システム API を直接対象とするもの (つまり、ネイティブ アプリケーション) であり、.NET Framework に依存しません。説明に「.NET」または「CLR」が含まれているものは避けてください。
アプリケーションがいつ .NET を使用しているかどうかを完全に理解しているわけではありません... Linux C/C++ 開発に慣れているだけです。マイクロソフトのたわごとは嫌いだ
コードで .NET Framework ライブラリ/クラスを使用する場合は常に .NET を使用します。なぜこれがそれほど理解しにくいのか、私にはよくわかりません。何らかの理由で特定の環境で利用できないサードパーティ製ライブラリを使用していた場合、Linux でも同じ問題が簡単に発生する可能性があります。これは Microsoft の問題ではなく、仕事に不適切なツールを使用したことによる問題です。.NET Framework は、ネイティブ API のオブジェクト指向ラッパーであり、Windows 用のプログラムを作成して実行することをはるかに容易にします。しかし、「Linux C/C++ 開発に慣れている」場合は、.NET を使用せずにネイティブ API を直接ターゲットとする単純なコンソール アプリケーションを作成するのにほとんど問題はないはずです。
「マイクロソフトのたわごと」に対する憎しみがアレルギーに変わった場合は、Visual Studio を完全に避けて、おそらく使い慣れた GCC コンパイラの Windows ポートであるMinGWをダウンロードできます。Vi のお気に入りの Windows ポートと組み合わせると、慣れ親しんだ環境と非常によく似た環境で作業できます。また、GCC は C++/CLI または .NET Framework をサポートしていないため、間違ったオプションを選んで行き詰まってしまう心配はありません。
.Net フレームワークは、WinPE の過去のいくつかのバージョンの PE ビルド プロセス中に、オプションのパッケージ インストールとしてサポートされています。私は C# でコードを書き、WinPE で毎日実行しています。ブレークポイントなどをウォークスルーできるような方法でデバッグする良い方法をまだ見つけていません.... 私の最善の選択肢は、多くのロギングと、完全なスタック ダンプを書き出すメイン エントリ ポイント周辺のグローバルな例外キャッチです。WinPE を実行している VM でリモート プロセスとしてアプリにアタッチできますが、実行の早い段階で何かをキャッチする必要がある場合は困難です。