Plugins development ko KR

플러그인 개발

ASF는 런타임 중 로드할 수 있는 사용자 지정 플러그인을 지원합니다. 플러그인을 사용하면 사용자 지정 명령어 추가, 사용자 지정 거래 로직, 혹은 서드파티 서비스 및 API와의 전체 통합 등을 통해 ASF의 동작을 커스터마이징할 수 있습니다.

이 페이지에서는 개발자 관점에서 ASF 플러그인에 대해 설명합니다 - 생성, 유지 관리, 배포 등을 다룹니다. 사용자 관점에서 보고 싶으시다면 **여기**로 이동하세요.

---

코어

플러그인은 ASF에 선언된 공통 IPlugin 인터페이스를 상속받는 클래스를 정의하는 표준 .NET 라이브러리입니다. 내부 ASF API가 호환되는 한, 메인라인 ASF와 완전히 독립적으로 플러그인을 개발하고 현재 및 향후 ASF 버전에서 재사용할 수 있습니다. ASF에서 사용하는 플러그인 시스템은 System.Composition을 기반으로 하며, 이는 예전에 **Managed Extensibility Framework**로 알려졌던 것으로, ASF가 런타임 중 사용자의 라이브러리를 검색하고 로드할 수 있게 해줍니다.

---

시작하기

여러분을 위해 **ASF-PluginTemplate**를 준비해두었으며, 플러그인 프로젝트의 베이스로 사용(하시는 것을 권장)할 수 있습니다. 템플릿 사용은 필수는 아니며(처음부터 직접 만드셔도 됩니다), 다만 올바르게 구성하는 데 걸리는 시간을 크게 단축하고 개발을 빠르게 시작할 수 있으므로 사용을 적극 권장합니다. 템플릿의 **README**를 확인하시면 이후 과정을 안내해줄 것입니다. 그럼에도 불구하고, 처음부터 직접 시작하고 싶으신 분들이나 플러그인 템플릿에서 사용된 개념을 더 깊이 이해하고 싶으신 분들을 위해 아래에서 기본 사항을 다루겠습니다 - 저희 플러그인 템플릿을 사용하기로 하셨다면 일반적으로 이 내용을 굳이 알 필요는 없습니다.

프로젝트는 compilation 섹션에 명시된 대로, 대상 ASF 버전에 맞는 적절한 프레임워크를 타겟팅하는 표준 .NET 라이브러리여야 합니다.

프로젝트는 메인 ArchiSteamFarm 어셈블리를 참조해야 하며, 릴리스의 일부로 다운로드한 미리 빌드된 ArchiSteamFarm.dll 라이브러리를 참조하거나, 소스 프로젝트(예: ASF 트리를 서브모듈로 추가하기로 한 경우)를 참조할 수 있습니다. 이를 통해 ASF의 구조, 메서드, 속성에 접근하고 활용할 수 있으며, 특히 다음 단계에서 상속받아야 할 핵심 IPlugin 인터페이스에 접근할 수 있습니다. 프로젝트는 최소한 System.Composition.AttributedModel도 참조해야 하며, 이를 통해 IPlugin을 ASF가 사용할 수 있도록 [Export]할 수 있습니다. 이 외에도, 일부 인터페이스에서 제공되는 데이터 구조를 해석하기 위해 다른 공통 라이브러리를 참조하고 싶거나 필요할 수 있지만, 명시적으로 필요한 것이 아니라면 지금은 이 정도로도 충분합니다.

모든 것을 올바르게 수행했다면, 여러분의 csproj는 아래와 유사한 형태가 될 것입니다:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <!-- Since you're loading plugin into the ASF process, which already includes those dependencies, IncludeAssets="compile" allows you to omit them from the final output -->
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" IncludeAssets="compile" Version="10.0.0" />
    <PackageReference Include="System.Composition.AttributedModel" IncludeAssets="compile" Version="10.0.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="C:\\Path\To\ArchiSteamFarm\ArchiSteamFarm.csproj" ExcludeAssets="all" Private="false" />

    <!-- If building with downloaded DLL binary, use this instead of <ProjectReference> above -->
    <!-- <Reference Include="ArchiSteamFarm" HintPath="C:\\Path\To\Downloaded\ArchiSteamFarm.dll" /> -->
  </ItemGroup>
</Project>

코드 측면에서, 여러분의 플러그인 클래스는 런타임 중 ASF가 이를 인식할 수 있도록 IPlugin 인터페이스를 상속해야 합니다(더 특화된 인터페이스, 예를 들어 IASF를 통해 암묵적으로 상속하든, 명시적으로 상속하든 상관없습니다) 그리고 [Export(typeof(IPlugin))]도 필요합니다. 이를 충족하는 가장 기본적인 예시는 다음과 같습니다:

using System;
using System.Composition;
using System.Threading.Tasks;
using ArchiSteamFarm;
using ArchiSteamFarm.Plugins;

namespace YourNamespace.YourPluginName;

[Export(typeof(IPlugin))]
public sealed class YourPluginName : IPlugin {
	public string Name => nameof(YourPluginName);
	public Version Version => typeof(YourPluginName).Assembly.GetName().Version;

	public Task OnLoaded() {
		ASF.ArchiLogger.LogGenericInfo("Hello World!");

		return Task.CompletedTask;
	}
}

플러그인을 사용하려면, 먼저 이를 컴파일해야 합니다. 이는 IDE에서 직접 하거나, 프로젝트 루트 디렉터리에서 명령어를 통해 수행할 수 있습니다:

# If your project is standalone (no need to define its name since it's the only one)
dotnet publish -c "Release" -o "out"

# If your project is part of ASF source tree (to avoid compiling unnecessary parts)
dotnet publish YourPluginName -c "Release" -o "out"

이후, 여러분의 플러그인은 배포 준비가 완료됩니다. 플러그인을 정확히 어떤 방식으로 배포하고 게시할지는 전적으로 여러분의 선택이지만, 컴파일된 플러그인과 그 종속성(dependencies) 을 함께 담은 zip 아카이브를 만드는 것을 권장합니다. 이렇게 하면 사용자는 단순히 zip 아카이브를 자신의 plugins 디렉터리 내 독립된 하위 디렉터리에 압축 해제하기만 하면 되고, 그 외에는 아무것도 할 필요가 없습니다.

이는 시작하기 위한 가장 기본적인 시나리오일 뿐입니다. 저희는 여러분 자신의 플러그인 내에서 수행할 수 있는 예시 인터페이스와 동작들을 유용한 주석과 함께 보여주는 ExamplePlugin 프로젝트를 제공하고 있습니다. 동작하는 코드를 통해 배우고 싶으시거나, ArchiSteamFarm.Plugins 네임스페이스를 직접 살펴보고 포함된 문서를 참고해 사용 가능한 모든 옵션을 확인하고 싶으시다면 자유롭게 살펴보세요. 아래에서 몇 가지 핵심 개념도 더 자세히 설명드리겠습니다.

예시 플러그인 대신 실제 프로젝트를 통해 배우고 싶으시다면, 저희가 개발한 여러 공식 플러그인들이 있습니다. 예를 들어 ItemsMatcher, MobileAuthenticator, SteamTokenDumper 가 있습니다. 이 외에도, 저희 서드파티 섹션에는 다른 개발자들이 개발한 플러그인들도 있습니다.

---

API 가용성

ASF는 인터페이스 자체를 통해 접근할 수 있는 부분 외에도, 기능을 확장하는 데 활용할 수 있는 수많은 내부 API를 노출합니다. 예를 들어, Steam 웹에 새로운 형태의 요청을 보내고 싶다면, 처음부터 모든 것을 직접 구현할 필요가 없습니다. 특히 저희가 이전에 이미 처리해야 했던 여러 문제들을 다시 다룰 필요가 없습니다. 인증, 세션 갱신, 웹 속도 제한(web limiting) 등 저수준의 작업들을 처리해주는 UrlWithSession() 메서드를 이미 많이 제공하는 저희 Bot.ArchiWebHandler를 그냥 사용하시면 됩니다. 마찬가지로, Steam 플랫폼 외부로 웹 요청을 보내고 싶다면 표준 .NET HttpClient 클래스를 사용할 수도 있지만, 실패한 요청 재시도 등에서 다시 한 번 도움을 주는 Bot.ArchiWebHandler.WebBrowser를 사용하는 것이 훨씬 더 좋습니다.

저희는 API 가용성에 있어 매우 개방적인 정책을 가지고 있습니다. 따라서 ASF 코드에 이미 포함된 어떤 것을 활용하고 싶으시다면, 간단히 이슈를 열어 ASF의 내부 API에 대해 계획하신 사용 사례를 설명해주세요. 여러분의 사용 사례가 합리적인 한, 저희는 대부분 이를 반대하지 않을 것입니다. 이는 기존 기능을 확장하기 위해 추가하면 좋을 만한 새로운 IPlugin 인터페이스에 대한 제안도 모두 포함합니다.

다만 ASF의 API 가용성과 관계없이, 여러분의 플러그인이 자체적인 종속성을 가질 수도 있다는 점에서 아무것도 여러분을 막지 않습니다. 예를 들어 애플리케이션에 Discord.Net 라이브러리를 포함시켜 여러분의 Discord 봇과 ASF 명령어를 연결하는 다리를 만드는 것도 가능합니다. 가능성은 무궁무진하며, 저희는 여러분의 플러그인 안에서 최대한의 자유와 유연성을 제공하기 위해 최선을 다했습니다. 따라서 인위적인 제한은 존재하지 않습니다 - 여러분의 플러그인은 메인 ASF 프로세스에 로드되며, C# 코드로 현실적으로 가능한 어떤 작업이든 수행할 수 있습니다.

---

API 호환성

ASF는 소비자용 애플리케이션이지, 무조건적으로 의존할 수 있는 고정된 API 표면을 가진 전형적인 라이브러리가 아니라는 점을 강조하는 것이 중요합니다. 즉, 한 번 컴파일된 여러분의 플러그인이 앞으로 나올 모든 ASF 릴리스에서도 계속 정상 작동할 것이라고 가정할 수 없습니다. 저희가 프로그램을 계속 발전시켜 나가려는 이상, 이는 단순히 불가능하며, 하위 호환성을 위해 끊임없이 변화하는 Steam의 변경 사항에 적응하지 못하는 것은 저희 상황에 적합하지 않습니다. 이는 당연하게 느껴지실 수도 있지만, 그럼에도 명확히 짚고 넘어가는 것이 중요합니다.

저희는 ASF의 공개된 부분을 최대한 안정적으로 유지하기 위해 최선을 다하겠지만, 충분한 이유가 있다면 저희 사용 중단(deprecation) 정책에 따라 호환성을 깨는 것도 주저하지 않을 것입니다. 이는 특히 ASF 인프라의 일부로 여러분에게 노출된 내부 구조(예: ArchiWebHandler)와 관련해 특히 중요합니다. 이러한 구조는 향후 ASF 개선의 일환으로 개선(따라서 재작성)될 수 있습니다. 저희는 변경 로그(changelog)에서 이를 적절히 안내하고, 런타임 중 더 이상 사용되지 않는(obsolete) 기능에 대해 적절한 경고를 표시하기 위해 최선을 다할 것입니다. 저희는 재작성 자체를 위해 모든 것을 다시 작성할 의도는 없습니다. 따라서 다음 마이너 ASF 버전이 단지 버전 번호가 더 높다는 이유만으로 여러분의 플러그인을 완전히 망가뜨리지는 않을 것이라고 어느 정도 확신하셔도 좋지만, 변경 로그를 주시하고 가끔씩 정상 작동 여부를 확인하는 것은 매우 좋은 습관입니다.

---

플러그인 종속성(dependencies)

여러분의 플러그인은 기본적으로 최소 두 가지 종속성을 포함하게 됩니다. 내부 API를 위한 ArchiSteamFarm 참조(최소 IPlugin)와, ASF 플러그인으로 인식되기 위해 필요한([Export] 절을 사용하기 위한) System.Composition.AttributedModel의 PackageReference입니다. 이 외에도, 여러분의 플러그인에서 하기로 결정한 작업에 따라 더 많은 종속성이 포함될 수 있습니다(예: Discord와 통합하기로 했다면 Discord.Net 라이브러리).

빌드 결과물에는 핵심 YourPluginName.dll 라이브러리와, 여러분이 참조한 모든 종속성이 함께 포함됩니다. 이미 동작 중인 프로그램을 위한 플러그인을 개발하는 것이므로, ASF가 이미 포함하고 있는 종속성(예: ArchiSteamFarm, SteamKit2, AngleSharp)은 포함할 필요가 없으며, 오히려 포함하지 않아야 합니다. ASF와 공유되는 종속성을 빌드에서 제외하는 것이 플러그인 동작을 위한 절대적인 필수 사항은 아니지만, 이렇게 하면 메모리 사용량과 플러그인 크기를 크게 줄이는 동시에 성능도 향상시킬 수 있습니다. ASF가 자신의 종속성을 여러분과 공유하고, ASF가 알지 못하는 라이브러리만 로드하기 때문입니다.

일반적으로, ASF가 포함하지 않거나 잘못된/호환되지 않는 버전으로 포함하고 있는 라이브러리만 포함하는 것이 권장되는 방식입니다. 그 예로는 당연히 YourPluginName.dll이 있지만, 예를 들어 Discord.Net.dll도 해당됩니다. ASF는 이를 자체적으로 포함하고 있지 않기 때문입니다. API 호환성을 보장하기 위해(예를 들어 여러분이 플러그인에서 의존하는 AngleSharp가 항상 X 버전이도록 보장하고 싶은 경우, ASF가 함께 제공하는 버전이 아니라) ASF와 공유되는 라이브러리를 번들로 포함하는 것도 여전히 의미가 있을 수 있습니다. 다만 이는 당연히 메모리/크기 증가와 성능 저하라는 대가를 치르게 되므로 신중하게 검토해야 합니다.

필요한 종속성이 ASF에 이미 포함되어 있다는 것을 알고 있다면, 위 csproj 예시에서 보여드린 것처럼 IncludeAssets="compile"로 표시할 수 있습니다. 이렇게 하면 컴파일러에게 해당 참조 라이브러리 자체는 게시(publish)하지 않도록 지시할 수 있습니다. ASF가 이미 이를 포함하고 있기 때문입니다. 마찬가지로, ASF 프로젝트를 ExcludeAssets="all" Private="false"로 참조하는 것도 확인하실 수 있는데, 이는 매우 유사한 방식으로 작동합니다 - 컴파일러에게 ASF 관련 파일을 생성하지 말라고 지시하는 것입니다(사용자는 이미 이를 가지고 있기 때문입니다). 이는 ASF 프로젝트를 참조할 때만 해당됩니다. dll 라이브러리를 참조하는 경우에는 여러분의 플러그인 결과물로 ASF 파일을 생성하지 않기 때문입니다.

위 설명이 혼란스럽고 잘 모르시겠다면, ASF-generic.zip 패키지에 어떤 dll 라이브러리가 포함되어 있는지 확인한 뒤, 아직 포함되지 않은 라이브러리만 여러분의 플러그인에 포함시키세요. 가장 단순한 플러그인의 경우, 이는 오직 YourPluginName.dll뿐일 것입니다. 런타임 중 특정 라이브러리와 관련된 문제가 발생하면, 해당 영향을 받은 라이브러리도 함께 포함시켜 주세요. 그 외 모든 방법이 통하지 않는다면, 언제든 모든 것을 번들로 포함하기로 결정할 수도 있습니다.

---

네이티브 종속성

네이티브 종속성은 OS별(OS-specific) 빌드의 일환으로 생성됩니다. 호스트에는 .NET 런타임이 존재하지 않으며, ASF는 OS별 빌드에 함께 번들된 자체 .NET 런타임을 통해 실행되기 때문입니다. 빌드 크기를 최소화하기 위해, ASF는 네이티브 종속성을 다듬어(trim) 프로그램 내에서 실제로 도달 가능한 코드만 포함시키며, 이를 통해 런타임에서 사용되지 않는 부분을 효과적으로 제거합니다. 이는 여러분의 플러그인에 잠재적인 문제를 일으킬 수 있습니다. 만약 여러분의 플러그인이 ASF에서 사용되지 않는 .NET 기능에 의존하고 있다는 사실을 갑자기 발견하게 된다면, OS별 빌드에서는 이를 제대로 실행할 수 없으며 보통 System.MissingMethodException 또는 System.Reflection.ReflectionTypeLoadException이 발생하게 됩니다. 여러분의 플러그인이 커지고 점점 더 복잡해질수록, 결국 저희 OS별 빌드가 다루지 않는 영역에 부딪히게 될 가능성이 높습니다.

이는 제네릭(generic) 빌드에서는 절대 문제가 되지 않습니다. 제네릭 빌드는 애초에 네이티브 종속성을 다루지 않기 때문입니다(호스트에 완전한 작동 런타임이 있어 ASF를 실행합니다). 이것이 바로 플러그인을 오직 제네릭 빌드에서만 사용하는 것이 권장되는 이유입니다. 다만 이 경우 OS별 빌드의 ASF를 사용하는 사용자에게는 여러분의 플러그인이 제외된다는 단점이 있습니다. 문제가 네이티브 종속성과 관련된 것인지 궁금하다면, ASF 제네릭 빌드에 플러그인을 로드해서 정상 작동하는지 확인하는 방법으로도 검증할 수 있습니다. 만약 정상 작동한다면, 플러그인 종속성 자체는 문제가 없는 것이며, 네이티브 종속성이 문제의 원인입니다.

안타깝게도, 저희는 OS별 빌드에서 전체 런타임을 함께 배포할 것인지, 아니면 사용하지 않는 기능을 제외할 것인지 사이에서 어려운 선택을 해야 했습니다. 후자를 선택하면 전체 빌드 대비 크기가 80MB 이상 작아집니다. 저희는 후자를 선택했으며, 안타깝게도 여러분이 부족한 런타임 기능을 플러그인과 함께 직접 포함시킬 방법은 없습니다. 만약 여러분의 프로젝트가 (OS별 빌드에서) 제외된 런타임 기능에 접근해야 한다면, 의존하는 전체 .NET 런타임을 포함해야 하며, 이는 곧 여러분의 플러그인을 generic ASF 버전에서 실행해야 한다는 의미입니다. OS별 빌드에서는 여러분의 플러그인을 실행할 수 없습니다. 이러한 빌드에는 여러분이 필요로 하는 런타임 기능이 아예 빠져 있기 때문이며, 현재 .NET 런타임은 저희가 제공한 것과 여러분이 제공할 수 있는 네이티브 종속성을 "병합"할 수 있는 능력이 없습니다. 언젠가 미래에는 개선될 수도 있지만, 현재로서는 단순히 불가능합니다.

ASF의 OS별 빌드에는 저희 공식 플러그인을 실행하는 데 필요한 최소한의 추가 기능만 포함되어 있습니다. 이것이 가능함과 별개로, 이는 가장 기본적인 플러그인들에 필요한 추가 종속성의 범위도 다소 넓혀줍니다. 따라서 모든 플러그인이 네이티브 종속성을 걱정해야 하는 것은 아닙니다 - ASF와 저희 공식 플러그인이 직접 필요로 하는 범위를 넘어서는 플러그인만 해당됩니다. 이는 부가적으로 이루어진 것입니다. 저희 자체 사용 사례를 위해 어차피 추가 네이티브 종속성을 포함해야 한다면, 이를 ASF와 함께 직접 배포하여 사용 가능하게 만들 수 있고, 그렇게 하면 여러분의 입장에서도 다루기가 더 쉬워지기 때문입니다. 안타깝게도, 이것이 항상 충분한 것은 아니며, 여러분의 플러그인이 더 크고 복잡해질수록 다듬어진(trimmed) 기능에 부딪힐 가능성이 높아집니다. 따라서 저희는 일반적으로 사용자 지정 플러그인을 generic ASF 버전에서만 실행하는 것을 권장합니다. OS별 ASF 빌드가 여러분의 플러그인 기능에 필요한 모든 것을 갖추고 있는지 직접 수동으로 확인할 수도 있습니다 - 다만 이는 여러분의 업데이트뿐만 아니라 저희 쪽의 변경에 따라서도 달라지므로, 유지 관리가 까다로울 수 있습니다.

경우에 따라서는 대체 옵션을 사용하거나, 여러분의 플러그인 안에서 직접 재구현하는 방식으로 누락된 기능을 "우회"하는 것도 가능할 수 있습니다. 다만 이것이 항상 가능하거나 현실적인 방법은 아니며, 특히 누락된 기능이 여러분의 플러그인에 포함된 서드파티 종속성에서 비롯된 경우에는 더욱 그렇습니다. OS별 빌드에서 플러그인을 실행하고 이를 어떻게든 작동시키려고 시도해볼 수는 있지만, 장기적으로는 너무 많은 수고가 들 수 있습니다. 특히 여러분이 원하는 것이 그저 코드가 정상적으로 동작하는 것이지, ASF의 표면(surface)과 씨름하는 것이 아니라면 더더욱 그렇습니다.

---

자동 업데이트

ASF는 여러분의 플러그인에 자동 업데이트 기능을 구현할 수 있는 두 가지 인터페이스를 제공합니다:

• IGitHubPluginUpdates는 일반적인 ASF 업데이트 메커니즘과 유사한 방식으로 GitHub 기반 업데이트를 손쉽게 구현할 수 있게 해줍니다.
• IPluginUpdates는 더 저수준의 기능을 제공하여, 더 복잡한 사용자 지정 업데이트 메커니즘이 필요한 경우 이를 구현할 수 있게 해줍니다.

---

IGithubPluginUpdates

업데이트 기능이 작동하기 위해 필요한 최소한의 체크리스트는 다음과 같습니다:

• RepositoryName을 선언해야 합니다. 이는 업데이트를 가져올 위치를 정의합니다.
• GitHub에서 제공하는 태그와 릴리스를 활용해야 합니다. 태그는 플러그인 버전으로 파싱 가능한 형식이어야 합니다(예: 1.0.0.0).
• 플러그인의 Version 속성은 이를 가져온 태그(tag)와 일치해야 합니다. 즉, 1.2.3.4 태그 아래에서 제공되는 바이너리는 1.2.3.4로 표시되어야 합니다.
• 각 태그마다, 플러그인 바이너리 파일이 포함된 zip 파일 릴리스 자산(release asset)과 함께 GitHub에 적절한 릴리스가 존재해야 합니다. IPlugin 클래스를 포함하는 바이너리 파일은 zip 파일 내 루트 디렉터리에 위치해야 합니다.

이를 통해 ASF의 메커니즘이 다음과 같은 작업을 수행할 수 있습니다:

• 현재 여러분 플러그인의 Version을 확인합니다(예: 1.0.1).
• GitHub API를 사용해 RepositoryName 저장소에서 최신 tag를 가져옵니다(예: 1.0.2).
• 1.0.2 > 1.0.1임을 확인하고, 1.0.2 태그의 릴리스를 확인하여 플러그인 업데이트가 담긴 .zip 파일을 찾습니다.
• 해당 .zip 파일을 다운로드하고 압축을 해제한 뒤, 그 내용을 이전에 YourPlugin.dll이 있던 디렉터리에 넣습니다.
• ASF를 재시작하여 1.0.2 버전의 플러그인을 로드합니다.

추가 참고 사항:

• 플러그인 업데이트를 위해서는 적절한 ASF 설정 값, 즉 PluginsUpdateMode 및/또는 PluginsUpdateList 가 필요할 수 있습니다.
• 저희 플러그인 템플릿에는 이미 필요한 모든 것이 포함되어 있으므로, 단순히 플러그인의 값을 적절하게 이름 변경(rename) 하기만 하면 바로 정상 작동합니다.
• 최신 릴리스와 프리릴리스를 조합해서 사용할 수 있으며, 이는 사용자가 설정한 UpdateChannel에 따라 사용됩니다.
• CanUpdate라는 불리언(boolean) 속성이 있어, 필요에 따라(예를 들어 일시적으로 업데이트를 건너뛰고 싶거나 그 밖의 이유로) 플러그인 업데이트를 여러분 쪽에서 비활성화/활성화하도록 오버라이드할 수 있습니다.
• 서로 다른 ASF 버전을 대상으로 하고 싶다면, 릴리스에 여러 개의 zip 파일을 포함시킬 수도 있습니다. 자세한 내용은 GetTargetReleaseAsset()의 remarks 를 참고하세요. 예를 들어, MyPlugin-V6-0.zip과 MyPlugin.zip을 함께 둘 수 있으며, 이 경우 V6.0.x.x 버전의 ASF는 전자를 선택하고, 그 외 모든 ASF 버전은 후자를 사용하게 됩니다.
• 위 방식만으로는 부족하고 올바른 .zip 파일을 선택하기 위한 사용자 지정 로직이 필요하다면, GetTargetReleaseAsset() 함수를 오버라이드해서 ASF가 사용할 아티팩트를 직접 제공할 수 있습니다.
• 플러그인이 업데이트 전/후에 추가 작업을 수행해야 한다면, OnPluginUpdateProceeding() 및/또는 OnPluginUpdateFinished() 메서드를 오버라이드할 수 있습니다.

---

IPluginUpdates

이 인터페이스는, IGithubPluginUpdates가 여러분에게 충분하지 않은 경우(예를 들어 버전으로 파싱되지 않는 태그를 사용하거나, 애초에 GitHub 플랫폼을 사용하지 않는 경우) 업데이트에 대한 사용자 지정 로직을 구현할 수 있게 해줍니다.

오버라이드해야 할 함수는 단 하나, GetTargetReleaseURL()이며, 이 함수는 대상 플러그인 업데이트 위치의 Uri?를 반환해야 합니다. ASF는 이 함수가 호출된 컨텍스트와 관련된 몇 가지 핵심 변수를 제공하지만, 그 외의 나머지 필요한 로직은 모두 여러분이 직접 구현해서 사용해야 할 URL(또는 업데이트가 없는 경우 null)을 ASF에 제공해야 합니다.

그 외에는 GitHub 업데이트 방식과 유사하며, URL은 루트 디렉터리에 바이너리 파일이 있는 .zip 파일을 가리켜야 합니다. OnPluginUpdateProceeding() 및 OnPluginUpdateFinished() 메서드도 사용할 수 있습니다.