ソース コードを読んで、Azure Dev-ops パイプラインを構築している職場の新しい C# プロジェクトを継承しました。
約複数のバックグラウンド スレッドと 1 つのサービスがあります。
私はまだ Dev-ops Pipelines に少し慣れていませんが、完全な馬鹿ではありません
ばかのほとんど
[サービス名]service.cs というモジュールが 1 つあります。
x86 ビルド プラットフォーム上に構築され、残りは任意の CPU 上に構築されます。
(コードを実行するためのバグ修正を除いて、コードはまだ作成していません。
モジュールの 1 つから 2 番目のモジュールに構成 app-settings をコピーして、
構成マネージャーはそれを見るでしょう
そして、見過ごされたブール値を追加しました
それでおしまい）
私は自分の論理を問題の内容に基づいています。Dev-opsではなく、私のマシンで問題なくビルドできるということです
ここにあるこのちょっとした情報に
そして、それをどのCPUにも切り替えることができず、86にビルドされないことに注意してください
ただ確認するため
そのページには、参照を含む using ステートメントがあるだけではありません。
それを分割する行は、名前空間が含まれている新しいステートメントを呼び出すため、using が存在しなくても問題ありません。
これは、Dev-ops 環境がその [サービス名]service.cs プロジェクトを構築していないことを意味します。
パイプラインでエラーをスローするのはx86ビルドモジュールです
私は主に独学で、このモジュールのコンテキストについて読んでいます
そのモジュールのコードベースに複数のIntptrsとアンマネージコードへの参照があることに関係があると思います
//structure for the Process32First API
[StructLayout(LayoutKind.Sequential)]
private struct PROCESSENTRY32
{
public uint dwSize;
public uint cntUsage;
public uint th32ProcessID;
public IntPtr th32DefaultHeapID;
public uint th32ModuleID;
public uint cntThreads;
public uint th32ParentProcessID;
public int pcPriClassBase;
public uint dwFlags;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
public string szExeFile;
}
アンマネージド コードとマネージド コードとは何かを読む必要がありましたが、それは理解していると思います。
そして、私が見る限り、その違いは私の論理にもっと役立ちます
そのすべてを尋ねる
私のマシンが既に行っているように、Azure でこれをビルドするにはどうすればよいですか
私のパイプラインのコンテキストもこの会話に追加されるように思われるので、その目的のために
