Compilation ja JP
コンパイルは、実行ファイルを作成するプロセスです。 ASFに独自の変更を追加したい場合は、これを行います。 何らかの理由で公式の で提供されている実行可能ファイルを信頼しない場合は、 をリリースします。 あなたが開発者ではなくユーザーであれば、ほとんどの場合は、すでにプリコンパイル済みのバイナリを使用するのがよいでしょう。ただし、自分で用意したものを使いたい場合や、新しいことを学びたい場合は、このまま読み進めてください。
ASFは、現在サポートされているプラットフォーム上でコンパイルすることができます。
プラットフォームに関係なく、ASFをコンパイルするには、完全な.NET SDK(実行時だけでなく)が必要です。 インストール手順は、 .NET ダウンロードページ にあります。 OS に適切な .NET SDK バージョンをインストールする必要があります。 インストールに成功した後、 dotnet コマンドは動作し、動作する必要があります。 dotnet --info で動作するか確認できます。 また、.NET SDK が ASF の**ランタイム要件**を満たしていることも確認してください。
.NET SDK が動作可能で適切なバージョンであることを前提として、ASF のソースディレクトリ（クローン、またはダウンロードして展開した ASF リポジトリ）に移動し、次を実行します：
dotnet publish ArchiSteamFarm -c "Release" -o "out/generic"Linux/macOSを使用している場合は、代わりに cc.sh スクリプトを使用することができます。
コンパイルが正常に終了した場合は、 ソースの フレーバーの out/generic ディレクトリにASFがあります。 これは公式の generic ASF ビルドと同じですが、セルフビルド向けとして UpdateChannel と UpdatePeriod が強制的に 0 に設定されています。
特定の必要性がある場合は、OS 固有の .NET パッケージを生成することもできます。 一般的には、これを行うべきではありません。というのも、先ほどコンパイルしたのは generic 版であり、そもそもコンパイルに使用した、すでにインストール済みの .NET ランタイムで実行できるためです。ただし、念のため実行したい場合は、次のようにします：
dotnet publish ArchiSteamFarm -c "Release" -o "out/linux-x64" -r "linux-x64" --self-containedもちろん、 linux-x64 を、 win-x64 のように、対象とするOSアーキテクチャに置き換えます。 このビルドではアップデートも無効になります。 --self-contained でビルドする場合、任意でさらに 2 つのスイッチを指定することもできます。-p:PublishTrimmed=true はトリミング済みビルドを生成し、-p:PublishSingleFile=true は単一ファイルを生成します。 両方を追加すると、独自のビルドで使用する同じ設定になります。
上記の手順だけで ASF の完全に動作するビルドを用意できますが、さらに、グラフィカルな Web インターフェースである ASF-ui のビルドにも関心があるかもしれません。 ASF 側で必要なのは、ASF-ui のビルド出力を標準の ASF-ui/dist の場所に配置し、その状態で ASF をビルドすることだけです（必要であれば再度）。
ASF-ui は ASF のソースツリーの一部として **git サブモジュール**になっています。必要なファイルが取得されないため、リポジトリは必ず git clone --recursive でクローンしてください。 また、作業中の NPM、 Node.js が付属しています。 Linux/macOS を使用している場合は、cc.sh スクリプトの使用をおすすめします。このスクリプトは、ASF-ui のビルドと同梱を自動的に処理します（可能な場合、つまり先ほど述べた要件を満たしている場合）。
cc.sh スクリプトに加えて、以下に簡略化したビルド手順も記載しています。追加のドキュメントについては、**ASF-ui リポジトリ**を参照してください。 上記と同じく、ASF のソースツリーの場所から、以下のコマンドを実行します：
rm -rf "ASF-ui/dist" # ASF-ui は古いビルド後に自身をクリーンアップしません
npm ci --prefix ASF-ui
npm run-script deploy --prefix ASF-ui
rm -rf "out/generic/www" # ビルド出力に古いファイルが残らないようにします
dotnet publish ArchiSteamFarm -c "Release" -o "out/generic" # または、上記に従って必要に応じて変更しますこれで、 out/generic/www フォルダにASF-uiファイルが見つかるはずです。 ASFはそれらのファイルをブラウザに提供することができます。
または、手動でも私たちのリポジトリを利用しても構いませんので、ASF-ui をそのままビルドし、そのビルド出力を手動で ${OUT}/www フォルダーにコピーすることもできます。ここで ${OUT} は、-o パラメーターで指定した ASF の出力フォルダーです。 これはまさにASFがビルドプロセスの一環として行っていることです。 ASF-ui/dist (存在する場合) を ${OUT}/wwwにコピーします。 何も特別なものではなく、必要に応じてポストビルドも行えます。
ASFコードを編集したい場合は、任意のものを使用できます。 その目的のためのET互換のIDEは、それでもオプションですが。 メモ帳を使って編集し、上記で説明した dotnet コマンドでコンパイルすることもできます。
あなたがより良い選択を持っていない場合。 JetBrains Rider と **Visual Studio Code**をお勧めします。 1つ目はASFチームが個人的に使用しているIDE、2つ目は実行可能な代替手段です。 両方のプログラムはクロスプラットフォームであり、Linux、macOSおよびWindowsで利用できます。
main ブランチは、そもそも正常にコンパイルできる状態や、ASF を問題なく実行できる状態であることは保証されていません。**リリースサイクルで述べているように、これは開発ブランチだからです。 ASF をソースからコンパイルまたは参照したい場合は、その目的に適したタグ**を使用してください。これにより、少なくとも正常にコンパイルできることが保証され、問題なく実行できる可能性も非常に高くなります（そのビルドが安定版リリースとしてマークされている場合）。 ツリーの現在の「健全性」を確認するには、CI - GitHub を使用します。
公式 ASF リリースは、ASF の**ランタイム要件に一致する最新の .NET SDK を使用して、GitHub** によってコンパイルされています。 テストを渡した後、すべてのパッケージはリリースとして、またGitHub上でデプロイされます。 GitHubは常にすべてのビルドに公式のパブリックソースを使用しているため、これは透明性も保証します。 GitHubのアーティファクトのチェックサムとGitHubのリリースアセットを比較できます。 ASFの開発者は、プライベートな開発プロセスとデバッグを除いて、自分自身でビルドをコンパイルまたは公開しません。
上記に加えて、ASFメンテナは、追加のセキュリティ対策として、GitHubのリモートASFサーバーから独立してビルドチェックサムを手動で検証し、公開します。 この手順は、既存のASFがリリースを自動更新機能の有効な候補とみなすために必須です。
