-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Compilation no NO
Compilation is the process of creating executable file. This is what you want to do if you want to add your own changes to ASF, or if you for whatever reason don't trust executable files provided in official releases. If you're user and not a developer, most likely you want to use already precompiled binaries, but if you'd like to use your own ones, or learn something new, continue reading.
ASF can be compiled on any currently supported platform, as long as you have all needed tools to do so.
Regardless of platform, you need full .NET Core SDK in order to compile ASF. Installation instructions can be found on .NET Core installation page. You need to install appropriate .NET Core SDK version for your OS. After successful installation, dotnet
command should be working and operative. You can verify if it works with dotnet --info
. Also ensure that your .NET Core SDK matches ASF runtime requirements.
Example of dotnet --info
on Windows:
C:\Users\Archi>dotnet --info
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9
Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.0\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
Assuming you have .NET Core SDK operative and in appropriate version, simply navigate to ASF directory and execute:
dotnet publish ArchiSteamFarm -c "Release" -o "out"
If you're using Linux/OS X, you can instead use cc.sh
script which will do the same, in a bit more complex manner.
If compilation ended successfully, you can find your ASF in source
flavour in ArchiSteamFarm/out
directory. This is the same as official generic
ASF build, but it has forced UpdateChannel
and UpdatePeriod
of ``.
You can also generate OS-specific package if you have a specific need. In general you shouldn't do that because you've just compiled generic
flavour that you can run with your already-installed .NET Core runtime that you used for the compilation in the first place, but just in case you want to:
dotnet publish ArchiSteamFarm -c "Release" -o "out-linux" -r "linux-x64"
Of course, replace linux-x64
with OS-architecture you want to target, such as win-x64
. This build will also have updates disabled.
If you'd like to edit ASF code, you can use any .NET Core compatible IDE for that purpose, although even that is optional, since you can as well edit with a notepad and compile with dotnet
command described above. Still, for Windows we recommend latest Visual Studio (free community version is more than enough). We also suggest to use it together with ReSharper, although it's not a free product.
If you'd like to work with ASF code on Linux/OS X instead, we recommend latest Visual Studio Code. It's not as rich as classic Visual Studio, but it's good enough.
Of course all suggestions above are only recommendations, you can use whatever you want to, it comes down to dotnet build
command anyway. Originally we use Visual Studio + ReSharper for ASF development, with a small part of third-party tools
that you can find in the repo.
master
branch is not guaranteed to be in a state that allows successful compilation or flawless ASF execution in the first place, since it's development branch just like stated in our release cycle. If you want to compile ASF from source, then you should use appropriate tag for that purpose, which guarantees at least successful compilation, and very likely also flawless execution (if build was marked as stable release).
Official ASF releases are compiled by AppVeyor on Windows, with latest .NET Core SDK that matches ASF runtime requirements. After passing tests, generic and OS-specific packages are deployed on GitHub. This also guarantees transparency, since AppVeyor always uses official public source for all builds, and you can compare checksums of AppVeyor artifacts with GitHub assets. ASF developers do not compile or publish builds manually, except for private development process, including debugging.
- π‘ Hjem
- π§ Konfigurasjon
- π¬ FAQ
- βοΈ Oppsett (start her)
- π₯ Bakgrunn-spillinnlΓΈser
- π’ Kommandoer
- π οΈ Kompatibilitet
- 𧩠ItemsMatcherPlugin
- π HΓ₯ndtering
- β±οΈ Ytelse
- π‘ Fjerntilgang
- πͺ Steam familiedeling
- π Bytting
- β¨οΈ Kommandolinjeargumenter
- π§ Utfasing
- π³ Docker
- π€ Utvidet FAQ
- π HΓΈy-ytelse oppsett
- π IPC
- π Lokalisering
- π Logging
- πΎ Lavt-minne oppsett
- π΅πΌββοΈ MonitoringPlugin
- π Utvidelser
- π Sikkerhet
- 𧩠SteamTokenDumperPlugin
- π¦ Tredjepart
- π΅ To-faktor autentisering