컴파일은 실행가능한 파일을 만드는 과정입니다. 만약 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 디렉토리에 source 형태의 ASF가 있습니다. 이것은 공식 일반 ASF 빌드도 동일하지만, 자체 빌드에 적합하도록 UpdateChannel과 UpdatePeriod이 0 값으로 되어있다는 점만 다릅니다.

특별한 필요가 있는 경우, OS별(OS-specific) .NET 패키지를 생성할 수도 있습니다. 일반적으로는 이렇게 할 필요가 없습니다. 이미 generic 버전을 컴파일했고, 이는 애초에 컴파일에 사용했던 기존 설치된 .NET 런타임으로 실행할 수 있기 때문입니다. 하지만 혹시 필요하신 경우를 위해 안내드리면:

dotnet publish ArchiSteamFarm -c "Release" -o "out/linux-x64" -r "linux-x64" --self-contained

물론 대상으로 하는 OS 아키텍쳐에 따라 linux-x64를 win-x64 등으로 변경하십시오. 이 빌드도 업데이트가 비활성화됩니다. --self-contained으로 빌드할 때는 선택적으로 두 가지 스위치를 추가로 지정할 수 있습니다: -p:PublishTrimmed=true는 trim된 빌드를 생성하고, -p:PublishSingleFile=true는 단일 파일을 생성합니다. 두 가지를 모두 추가하면 저희가 자체 빌드에 사용하는 설정과 동일해집니다.

위 단계들만으로도 완전히 작동하는 ASF 빌드를 만드는 데 충분하지만, 저희의 그래픽 웹 인터페이스인 ASF-ui 빌드에도 추가로 관심이 있으실 수 있습니다. ASF 측에서는 ASF-ui 빌드 결과물을 표준 위치인 ASF-ui/dist에 넣기만 하면 되며, 그 다음(필요한 경우) 그것과 함께 ASF를 빌드하면 됩니다.

ASF-ui는 git submodule 형태로 ASF의 소스 트리에 포함되어 있으므로, git clone --recursive로 저장소를 클론했는지 확인하세요. 그렇지 않으면 필요한 파일이 없을 수 있습니다. 정상 작동하는 NPM도 필요하며, Node.js 를 설치하면 함께 제공됩니다. Linux/macOS를 사용 중이라면, 저희의 cc.sh 스크립트를 사용하시길 권장합니다. 방금 언급한 요구사항을 충족하는 경우, 이 스크립트가 ASF-ui의 빌드 및 배포 과정을 자동으로 처리해줍니다.

cc.sh 스크립트 외에도, 아래에 간략화된 빌드 안내를 함께 첨부합니다. 추가 문서는 ASF-ui 저장소 를 참고하세요. 위와 마찬가지로, ASF 소스 트리 위치에서 다음 명령어를 실행하세요:

rm -rf "ASF-ui/dist" # ASF-ui doesn't clean itself after old build

npm ci --prefix ASF-ui
npm run-script deploy --prefix ASF-ui

rm -rf "out/generic/www" # Ensure that our build output is clean of the old files
dotnet publish ArchiSteamFarm -c "Release" -o "out/generic" # Or accordingly to what you need as per the above

이제 out/generic/www 폴더에서 ASF-ui 파일을 찾을 수 있을 것입니다. ASF는 이 파일들을 브라우저에 제공할 수 있게 됩니다.

또는, 수동으로 혹은 저희 저장소의 도움을 받아 ASF-ui를 빌드한 다음, 빌드 결과물을 ${OUT}/www 폴더에 직접 복사할 수도 있습니다. 여기서 ${OUT}은 -o 매개변수로 지정한 ASF의 출력 폴더입니다. 이것이 바로 ASF가 빌드 과정에서 수행하는 작업입니다. ASF-ui/dist가 존재하면 이를 ${OUT}/www로 복사할 뿐이며, 특별할 것은 없고, 보시다시피 필요하다면 빌드 이후에도 수행할 수 있습니다.

ASF 코드를 편집하고 싶다면 .NET과 호환되는 IDE를 사용할 수 있지만, 이마저도 필수는 아닙니다. 메모장으로 편집한 뒤 위에서 설명한 dotnet 명령어로 컴파일하는 것도 가능하기 때문입니다.

더 나은 선택지가 없다면 JetBrains Rider 와 Visual Studio Code 를 추천드립니다. 전자는 ASF 팀이 개인적으로 사용하는 선호 IDE이며, 후자는 실용적인 대안입니다. 두 프로그램 모두 크로스 플랫폼이며 Linux, macOS, Windows에서 사용 가능합니다.

main 브랜치는 저희 릴리스 주기 에서 언급했듯 개발 브랜치이기 때문에, 애초에 성공적인 컴파일이나 완벽한 ASF 실행이 가능한 상태라고 보장되지 않습니다. ASF를 소스에서 컴파일하거나 참조하려면 목적에 맞는 적절한 태그 를 사용해야 합니다. 이는 최소한 성공적인 컴파일을 보장하고, 안정 릴리스로 표시된 빌드는 거의 흠없는 실행도 가능합니다. 트리의 현재 "상태(health)"를 확인하려면, 저희 CI인 GitHub 를 활용하실 수 있습니다.

공식 ASF 릴리스는 ASF 런타임 요구사항 에 맞는 최신 .NET SDK를 사용하여 GitHub 에서 컴파일됩니다. 테스트를 통과하면, 모든 패키지는 GitHub에서도 릴리스로 배포됩니다. 이는 투명성도 보장하는데, GitHub는 모든 빌드에 항상 공식 공개 소스를 사용하기 때문이며, GitHub 아티팩트의 체크섬을 GitHub 릴리스 자산과 비교해볼 수도 있습니다. ASF 개발자는 개인 개발과정과 디버깅을 제외하고는 스스로 컴파일하거나 빌드를 게시하지 않습니다.

위 사항에 더해, ASF 관리자들은 추가적인 보안 조치로서 GitHub와는 독립된 원격 ASF 서버에서 빌드 체크섬을 수동으로 검증하고 게시합니다. 이 단계는 기존 ASF가 자동 업데이트 기능의 유효한 후보로 해당 릴리스를 인식하기 위해 반드시 필요합니다.