-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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があります。 これは公式の ジェネリック ASFビルドと同じです。 しかし、UpdateChannel と UpdateChannel と UpdatePeriod の 0を強制しました 自己構築に適しています
特定の必要性がある場合は、OS 固有の .NET パッケージを生成することもできます。 一般的には、インストール済みの ジェネリック フレーバーをコンパイルしたばかりなので、これを行うべきではありません。 最初の場所でコンパイルに使用したETランタイムですが、念のため次のようにします:
dotnet publish ArchiSteamFarm -c "Release" -o "out/linux-x64" -r "linux-x64" --self-containedもちろん、 linux-x64 を、 win-x64 のように、対象とするOSアーキテクチャに置き換えます。 このビルドではアップデートも無効になります。 When building --self-contained you can also optionally declare two more switches: -p:PublishTrimmed=true will produce trimmed build, while -p:PublishSingleFile=true will produce a single file. 両方を追加すると、独自のビルドで使用する同じ設定になります。
上記のステップは、ASFの完全に動作するビルドを持つために必要なすべてです。 また、 は、 **ASF-ui**の構築に興味がある可能性があります。 From ASF side, all you need to do is dropping ASF-ui build output in standard ASF-ui/dist location, then building ASF with it (again, if needed).
ASF-ui is part of ASF's source tree as a git submodule, ensure that you've cloned the repo with git clone --recursive, as otherwise you'll not have the required files. また、作業中の NPM、 Node.js が付属しています。 If you're using Linux/macOS, we recommend our cc.sh script, which will automatically cover building and shipping ASF-ui (if possible, that is, if you're meeting the requirements we've just mentioned).
In addition to the cc.sh script, we also attach the simplified build instructions below, refer to ASF-ui repo for additional documentation. 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はそれらのファイルをブラウザに提供することができます。
Alternatively, you can simply build ASF-ui, whether manually or with the help of our repo, then copy the build output over to ${OUT}/www folder manually, where ${OUT} is the output folder of ASF that you've specified with -o parameter. これはまさにASFがビルドプロセスの一環として行っていることです。 ASF-ui/dist (存在する場合) を ${OUT}/wwwにコピーします。
ASFコードを編集したい場合は、任意のものを使用できます。 その目的のためのET互換のIDEは、それでもオプションですが。 メモ帳を使って編集し、上記で説明した dotnet コマンドでコンパイルすることもできます。
より良い選択肢がない場合は、 **最新の Visual Studio Code**をお勧めします。 より高度なニーズにも十分です もちろん、好きなものを使うことができます 参考には、ASF開発に JetBrains Rider を使用しますが、無料のソリューションではありません。
メイン ブランチがコンパイルに成功したり、最初の場所で完璧なASF実行を可能にする状態にあることは保証されません。 リリースサイクル に記載されているように開発ブランチなので、. ソースからASFをコンパイルまたは参照したい場合。 そのためには、適切な タグ を使用する必要があります。 これは少なくともコンパイルが成功することを保証し、(ビルドが安定版リリースとしてマークされている場合)非常にも完璧な実行を保証します。 ツリーの現在の「健全性」を確認するには、CI - GitHub を使用します。
Official ASF releases are compiled by GitHub, with latest .NET SDK that matches ASF runtime requirements. テストを渡した後、すべてのパッケージはリリースとして、またGitHub上でデプロイされます。 GitHubは常にすべてのビルドに公式のパブリックソースを使用しているため、これは透明性も保証します。 GitHubのアーティファクトのチェックサムとGitHubのリリースアセットを比較できます。 ASFの開発者は、プライベートな開発プロセスとデバッグを除いて、自分自身でビルドをコンパイルまたは公開しません。
上記に加えて、ASFメンテナは、追加のセキュリティ対策として、GitHubのリモートASFサーバーから独立してビルドチェックサムを手動で検証し、公開します。 この手順は、既存のASFがリリースを自動更新機能の有効な候補とみなすために必須です。







