القائمة
Use when building C# projects with xmake — `.cs` sources with the Mono `mcs` or .NET `dotnet` toolchain, binary / library output, adding references, and mixing with native code via P/Invoke.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when switching xmake's output theme (colors, progress style, emoji) or fixing garbled/unreadable terminal output — `xmake g --theme=...`. Built-in themes: default, ninja, emoji, dark, light, plain, powershell.
Use when the user is starting a new Xmake project, installing Xmake, or needs the minimal xmake.lua structure. Covers installation, `xmake create`, the project layout, and the smallest valid xmake.lua.
Use when writing or reviewing an `xmake.lua` (project, package recipe, or toolchain) and you want to follow idiomatic xmake style — description vs script domain separation, naming, indentation, `set_` vs `add_`, option/config organization, and common conventions used across xmake-repo and the xmake project itself. Apply this alongside `xmake-targets`/`xmake-packages`/etc. as a stylistic overlay.
Use when creating a new xmake project from a built-in or third-party template (`xmake create -t <template>`), listing available templates, or authoring and distributing custom templates (built-in, user-global, or via xmake-repo). Covers template layout, `${TARGET_NAME}` / `${FAQ}` substitution, and language selection.
Use when invoking Xmake from the command line — configuring, building, running, cleaning, installing, packing, or inspecting a project. Covers the common flags for `xmake f`, `xmake`, `xmake run`, `xmake install`, `xmake pack`, and friends.
Use when exporting an xmake project to another build system or IDE — `compile_commands.json` for clangd/LSP, `CMakeLists.txt`, `build.ninja`, Visual Studio solution (`vsxmake`), or an Xcode project. Covers `xmake project -k <kind>` and how each generator is typically used.
| name | xmake-csharp |
| description | Use when building C# projects with xmake — `.cs` sources with the Mono `mcs` or .NET `dotnet` toolchain, binary / library output, adding references, and mixing with native code via P/Invoke. |
Xmake drives the C# compiler (Mono mcs or modern .NET csc/dotnet) through a target model similar to C++.
add_rules("mode.debug", "mode.release")
target("hello")
set_kind("binary")
add_files("src/*.cs")
target("app") set_kind("binary") -- .exe
target("mylib") set_kind("shared") -- .dll (class library)
xmake f --toolchain=mcs -- Mono compiler
xmake f --toolchain=dotnet -- .NET SDK (csc)
Pin a specific install with --sdk:
xmake f --toolchain=dotnet --sdk=/usr/share/dotnet/sdk/8.0.100
target("app")
add_files("src/*.cs")
add_csflags("/reference:System.dll", "/reference:System.Core.dll")
-- Or the modern, portable form:
add_values("cs.references", "System.dll", "System.Core.dll")
For NuGet / .NET SDK projects, prefer a real .csproj consumed via dotnet build — xmake's direct C# support is best for small / standalone tools.
target("nativelib")
set_kind("shared")
add_files("native/*.c")
target("app")
set_kind("binary")
add_files("src/*.cs")
add_deps("nativelib")
In Program.cs:
using System.Runtime.InteropServices;
class Program {
[DllImport("nativelib")]
static extern int hello(int x);
}
Xmake places nativelib.dylib/.so/.dll next to the managed binary so the runtime loader finds it.
target("app")
add_files("src/*.cs")
add_csflags("-unsafe", "-nowarn:1591")
add_csflags maps to C# compiler flags.
xmake is not dotnet build. Complex .csproj projects (NuGet, SDK-style projects, Razor, WPF designers) should go through dotnet build inside a task(...) instead of xmake's native C# support.System.dll references. Modern .NET Core doesn't need them (implicit); Mono does. Test with the toolchain you'll ship on.PATH or next to the .exe. Xmake's default placement handles the common case.xmake-targetsxmake-xpack