Cómo contribuir
🇬🇧 Prefer English? Read the English version.
¡Gracias por querer ayudar! Esta guía explica cómo compilar el proyecto y cómo hacer los cambios más habituales.
Requisitos
- Windows, Linux o macOS (la interfaz usa Avalonia, multiplataforma).
- .NET 9 SDK.
- (Solo para generar el instalador) Inno Setup 6.
Compilar y ejecutar
git clone https://github.com/JuanP-G/MC-ServerLauncher.git
cd MC-ServerLauncher
dotnet run --project McServerLauncher
Generar el sitio de documentación en local (esta página):
dotnet tool install -g docfx # solo la primera vez
.\docs\build-docs.ps1 # compila y sirve en http://localhost:8080
Convenciones
- Los comentarios y nombres del código van en inglés. El texto que ve el usuario no se escribe a mano: pasa por el sistema de localización (ver abajo).
- Mantén la separación MVVM: lógica en
Services/, estado/comandos enlazables enViewModels/, y solo code-behind ligero enViews/. - Nada de rutas absolutas del equipo. Usa
Environment.GetFolderPath(...)y%APPDATA%. - Los tipos/miembros públicos llevan un resumen XML
///— es lo que alimenta la referencia de API.
Recetas paso a paso
Añadir un idioma
- Copia
Resources/Strings.resxaResources/Strings.<código>.resx(p. ej.Strings.it.resx) y traduce cada<value>. - Añade el código a
<SatelliteResourceLanguages>enMcServerLauncher.csproj. - Añádelo a la lista
LanguagesdeMainViewModelpara que salga en el selector de la barra lateral.
Añadir un texto traducible
- Añade la misma entrada
<data name="MiClave">a los cinco archivos.resxcon la traducción. - Úsalo desde XAML como
{loc:Loc MiClave}, o desde código comoLocalizer.Get("MiClave")(usastring.Format(Localizer.Get("MiClave"), arg)si tiene huecos{0}).
Añadir un ajuste de server.properties al editor visual
- Añade el control + etiqueta/descripción en
Views/ServerConfigDialog.axaml(y enlázalo en su code-behind). - Lee/escribe la clave con
ServerPropertiesService.Read/Update, que conserva el resto del archivo, los comentarios y el orden.
Añadir un diálogo o servicio nuevo
- Diálogo: crea
Views/MiDialogo.axaml+.axaml.cscomo unaWindownormal de Avalonia, localiza sus textos con{loc:Loc ...}y ábrelo desde un comando del ViewModel (miraWhatsNewDialogoPlayitApiKeyDialogcomo ejemplos pequeños). - Servicio: añade una clase centrada en
Services/, sin interfaz, e instánciala desde el ViewModel correspondiente (mira cómoServerViewModelcompone sus servicios).
Sacar una versión nueva
- Sube
<Version>enMcServerLauncher/McServerLauncher.csproj— es la fuente única de verdad.publish.ps1la lee y se la pasa a Inno Setup. Mantén alineado el fallbackMyAppVersiondel.isssolo para que una compilación manual/directa con Inno Setup no genere un nombre antiguo. - Añade una entrada de novedades para que el diálogo de actualización tenga algo que mostrar:
- Una nueva tupla al principio de
EntriesenServices/Changelog.cs(la más nueva primero), p. ej.(new Version(1, 6, 0), "Whatsnew_1_6_0"). - La clave
Whatsnew_x_y_zcorrespondiente en los cinco archivos.resx(el texto en español en el neutralStrings.resx, las traducciones en el resto). Mira Añadir un texto traducible más arriba.
- Una nueva tupla al principio de
- Ejecuta
publish.ps1. Publica el build self-containedwin-x64, genera el instalador de Inno Setup endist/y escribedist/SHA256SUMS.txtjunto a él. - Crea la release con ambos assets y notas bilingües:
gh release create vX.Y.Z dist/MC-ServerLauncher-Setup-X.Y.Z.exe dist/SHA256SUMS.txt- El actualizador de la app busca el asset
.exe(así que adjúntalo siempre) y elSHA256SUMS.txt, que usa para verificar el instalador antes de ejecutarlo (UpdateService.CheckAsync). La verificación es obligatoria: sin ese archivo el actualizador rechaza la instalación silenciosa y solo abre la página de la release — no lo omitas nunca.
- El actualizador de la app busca el asset
Antes de cambiar cómo se numeran las versiones, comprueba qué sabe leer la versión instalada. Una release cuyo tag tiene una forma que los clientes antiguos no entienden es invisible para ellos por muy correcto que sea el código nuevo — y el código que la entiende viaja dentro de esa release. Ha pasado dos veces: las pre-releases eran invisibles antes de la 1.10.1, y los tags de cuatro números antes de la 1.10.3.1, porque en ambos casos había que cambiar
UpdateServicepara verlas. La primera release de una forma nueva siempre hay que pasarla a mano; dílo en vez de prometer una actualización automática.
Numeración. Una beta lleva un cuarto número que prolonga la estable a la que sigue: tras
1.10.3vienen1.10.3.1,1.10.3.2, y lo terminado sale como la siguiente estable (1.11.0). Es así a propósito: numerar las betas según la versión a la que llevan haría que la estable quedara por debajo de sus propias betas y dejara tirado a quien las probó.
- Si es una beta, publícala como pre-release desde su rama:
GitHub deja las pre-releases fuera degh release create vX.Y.Z --prerelease --target <rama> dist/MC-ServerLauncher-Setup-X.Y.Z.exe dist/SHA256SUMS.txt/releases/latest, así que a quien está en la línea estable no se le empuja a una. Desde la 1.10.1 el actualizador lee la lista de releases, que es lo que hace que una beta sea alcanzable, y avisa de que lo es antes de que se pulse Actualizar. Cualquier versión anterior a la 1.10.1 no puede ver betas, así que la primera beta después de una estable hay que pasarla a mano. - Publicar la release dispara automáticamente los workflows de Linux (
release-linux.yml) y macOS (release-macos.yml), que generan y adjuntan el.AppImagey los dos.dmg. No los subas a mano — basta con esperar a que terminen los workflows.
Sitio de documentación (GitHub Pages)
La referencia de API + estos artículos se publican automáticamente en GitHub Pages mediante
.github/workflows/docs.yml en cada push a main. El sitio se genera con DocFX a partir de los
comentarios /// y el markdown de docs/.
Paso único del propietario del repo: activar Pages en Settings → Pages → Source: “GitHub Actions”. A partir de ahí, cada push actualiza el sitio solo.