Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Für Informationen, die üblicherweise in der .csproj-Projektdatei liegen, hat Microsoft für File-based Apps eine eigene Syntax eingeführt.

Die Syntax beginnt mit der Raute # (eine Präprozessor-Direktive in C#) gefolgt von einem Doppelpunkt (aus der Sicht des C#-Compilers eine zu ignorierende Direktive):

• Festlegung des SDKs: #:sdk Microsoft.NET.Sdk.Web. Bei der Angabe des SDK kann man ab Preview 6 auch die Versionsnummer nach @ angeben, beispielsweise #:sdk Aspire.AppHost.Sdk@9.3.1
• Referenz auf ein NuGet-Paket: #:package Console@0.48.*
• Referenz auf Projekte: #:project ./ClassLib/ClassLib.csproj
• Build-Eigenschaften, z. B. Versionsnummer: #:property Version=1.1.2 (vor Preview 6 noch ohne Gleichheitszeichen, sondern mit Leerzeichen als Trennung)
• File-based Apps verwenden im Standard den NativeAOT-Compiler. Wenn man ihn mit #:property PublishAot=false deaktiviert, wird der Just-in-Time-Compiler verwendet.

Weitere Features von Files-based Apps sind:

• Man kann eine Datei .settings.json im gleichen Ordner mit den Settings für die File-based App anlegen.
• Man kann in der Datei .run.json im gleichen Ordner ein Launch-Profil für die File-based App anlegen.
• Man kann dotnet build Dateiname.cs oder dotnet restore Dateiname.cs ausführen.
• Man kann solche File-based Apps mit dotnet publish cs zu einer ausführbaren Datei (.EXE) übersetzen.
• Innerhalb einer File-based App können Entwicklerinnen und Entwickler seit Preview 6 den Standort der Datei mit AppContext.GetData("EntryPointFileDirectoryPath") und den ganzen Pfad zur ausgeführten C#-Datei mit GetData("EntryPointFilePath") bestimmen. Das funktioniert allerdings nur mit File-based Apps, nicht in normalen, projektbasierten C#-Anwendungen.

Es gibt aber in .NET 10.0 noch keine Möglichkeit, in einer File-based App eine andere .cs-Datei direkt einzubinden. Das ist für .NET 11.0 geplant.

Folgender Code zeigt ein Beispiel einer File-based App mit zwei referenzierten NuGet-Paketen:

#!/usr/bin/env dotnet
#region Einstellungen für File-based App
// 
#:package Humanizer@2.14.1 
// 
#:package Spectre.Console@0.*
#:property LangVersion=preview
#:property Version=1.2.0
#:project ./ClassLibrary/ClassLibrary.csproj
#endregion
using Spectre.Console;
using Humanizer;

var title = "C# Script v" + System.Reflection.Assembly.GetExecutingAssembly().GetName().Version +
" mit " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription + "\n" +
AppContext.GetData("EntryPointFilePath");

// Header
AnsiConsole.Write(
    new Panel(title)
        .Header("[yellow]File-based App[/]", Justify.Center)
        .Border(BoxBorder.Rounded)
        .BorderStyle(new Style(foreground: Color.Green))
        .Padding(1, 1, 1, 1)
);

// Parameter auflisten
foreach (var arg in args)
{
    Console.WriteLine($"Argument: {arg}");
}

Console.WriteLine();

// Daten
(Data net80, Data net90, Data net10) = GetData();

// Textausgabe in Wochen
var dotNet8Released = DateTimeOffset.Parse(net80.Release);
TimeSpan dotNet8Since = DateTimeOffset.Now - dotNet8Released;
Console.WriteLine($"It has been {dotNet8Since.Humanize()} since .NET {net80.Version} was released.");

var dotNet9Released = DateTimeOffset.Parse(net90.Release);
TimeSpan dotNet9Since = DateTimeOffset.Now - dotNet9Released;
Console.WriteLine($"It has been {dotNet9Since.Humanize()} since .NET {net90.Version} was released.");

var dotNet10Released = DateTimeOffset.Parse(net10.Release);
TimeSpan dotNet10Since = DateTimeOffset.Now - dotNet10Released;
Console.WriteLine($"{dotNet10Since.Humanize()} since .NET {net10.Version} release.");

Console.WriteLine();

// Zeichne Balken für die Anzahl der Tage seit der Veröffentlichung
var bar = new BarChart()
    .Width(100)
    .AddItem("Days since .NET 8.0 release", dotNet8Since.TotalDays, Color.Red)
    .AddItem("Days since .NET 9.0 release", dotNet9Since.TotalDays, Color.Blue)
    .AddItem("Days since .NET 10.0 release", dotNet10Since.TotalDays, Color.Purple);
AnsiConsole.Write(bar);

Console.WriteLine();

// Lokale Funktion
static (Data, Data, Data) GetData()
{
    var net80 = new Data
    {
        Version = "8.0",
        Release = "2023-11-14"
    };
    var net90 = new Data
    {
        Version = "9.0",
        Release = "2024-11-12"
    };
    var net10 = new Data
    {
        Version = "10.0",
        Release = "2025-11-11"
    };
    return (net80, net90, net10);
}

// Datenklasse
class Data
{
    public required string Version { get; set; }
    public string Release { get; set; }
}

(rme)

Cloudflare hat EmDash als Preview veröffentlicht, ein Open-Source-CMS mit einem Fokus auf Sicherheit. Das Unternehmen schickt es als den „geistigen Nachfolger“ des seit über 20 Jahren bestehenden WordPress ins Rennen. EmDash zeichnet sich dadurch aus, dass es Plug-ins in einer eigenen Sandbox ausführt, um die Sicherheit zu erhöhen. Integrierte KI-Funktionen dürfen ebenfalls nicht fehlen.

EmDash ist serverlos, lässt sich jedoch auf eigener Hardware oder einer Plattform nach Wahl ausführen. Das Fullstack-Content-Management-System (CMS) ist in TypeScript geschrieben und nutzt unter der Haube das Open-Source-Webframework Astro, dessen Hersteller Astro Technology Company erst Anfang des Jahres von Cloudflare übernommen wurde. Benannt ist das CMS nach dem Geviertstrich (—), der unter anderem in der englischen Typografie als Gedankenstrich verwendet wird.

Plug-ins in eigener Sandbox

Wie Cloudflare in seinem Blog beschreibt, haben 96 Prozent aller Security-Probleme in WordPress ihren Ursprung in Plug-ins. In EmDash läuft daher jedes Plug-in innerhalb seiner eigenen, isolierten Sandbox. Dazu kommt die Cloudflare-Technologie Dynamic Workers zum Einsatz. Ein Plug-in erhält seine Fähigkeiten in EmDash via Bindings und kann ausschließlich die im Manifest des Plug-ins explizit deklarierten Aktionen durchführen. Das soll Entwicklerinnen und Entwicklern bereits vor der Installation die Gewissheit geben, welche Befugnisse eine Erweiterung haben wird.

Plug-ins für EmDash können zudem eine beliebige Lizenz haben, da sie von EmDash unabhängig sind. Das soll einen Marketplace-Lock-in verhindern. WordPress-Erweiterungen unterliefen dagegen aus Sicherheitsgründen einer manuellen Review und seien eng mit WordPress-Code verwoben. Daher würde teils argumentiert, dass die WordPress-GPL-Lizenz genutzt werden müsse, so Cloudflare.

Integrierte KI-Features

Als „KI-natives CMS“ angepriesen, bietet EmDash einige Features für die Nutzung künstlicher Intelligenz. EmDash-Instanzen enthalten Agent Skills und bieten einen integrierten Remote-MCP-Server (Model Context Protocol). Auch befähigt das EmDash-CLI KI-Agenten dazu, mit lokalen oder Remote-Instanzen von EmDash zu interagieren. Darüber lassen sich beispielsweise Medien hochladen, Inhalte durchsuchen oder Schemas erstellen und verwalten.

Auf verschiedene Arten können Entwicklerinnen und Entwickler ihre WordPress-Seiten in EmDash importieren. Um mit EmDash loszulegen, sind drei Starter-Templates enthalten: Blog, Marketing und Portfolio. Das Admin-Interface von EmDash können Interessierte in einem Playground ausprobieren.

Im GitHub-Repository ist der Quellcode des MIT-lizenzierten Projekts zu finden, das sich derzeit in der Beta-Preview-Version 0.1.0 befindet. Weitere Informationen zu EmDash teilt der Hersteller Cloudflare in seinem Blog mit.

(mai)

Mit über 90.000 Contributors und rund 4,4 Millionen Contributions ist Kubernetes nach Linux das zweitgrößte Open-Source-Projekt weltweit. Hierzulande stuft mittlerweile auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) Kubernetes als De-facto-Standard für Container-Orchestrierung ein. Doch wie funktioniert ein Projekt dieser Größenordnung eigentlich von innen? Im Rahmen des Cloud-Native-Festivals CloudLand 2025 hat Mario Fahlandt, der im Kubernetes-Projekt unter anderem in den Special Interest Groups (SIG) Contributor Experience und K8s Infra aktiv ist, einen detaillierten Einblick in die Strukturen, Einstiegsmöglichkeiten und Karrierepfade der Kubernetes-Community gegeben.

Fahlandt, der selbst als Host für die EMEA/APAC-Region bei der Kubernetes New Contributor Orientation (NCO) fungiert, machte in seinem Vortrag deutlich: Beiträge zum Projekt beschränken sich keineswegs auf Code. Meeting-Notizen anfertigen, Fragen im Slack-Channel beantworten, Dokumentationen korrigieren oder Blog-Posts verfassen – all das zählt als Contribution.

Drei Kategorien von Special Interest Groups

Die Community organisiert sich unter dem Dach der Cloud Native Computing Foundation (CNCF) in einer ausdifferenzierten Struktur. An der Spitze steht ein Steering Committee mit sieben gewählten Mitgliedern. Die eigentliche Arbeit findet in 24 Special Interest Groups (SIGs) statt, die sich in drei Kategorien gliedern: Project-SIGs wie Architecture, Docs oder Release unterstützen das Gesamtprojekt organisatorisch. Horizontal-SIGs – darunter API-Machinery, Auth oder Scalability – kümmern sich um querschnittliche Kernfunktionalität. Vertical-SIGs wie Network, Storage oder Node verantworten jeweils spezifische technische Komponenten. Ergänzt wird diese Struktur durch sieben Working Groups für temporäre Themen und drei Committees. Jeder Code- und Dokumentationsteil ist dabei einer konkreten SIG oder einem Subproject zugeordnet.

Wer sollte sich engagieren und wie gelingt der Einstieg?

Wer einsteigen möchte, findet über den Kubernetes-Slack (Kanal #kubernetes-new-contributors), die K-Dev-Mailingliste und den Community-Kalender Anschluss. Die monatliche NCO-Session findet jeweils am dritten Dienstag statt – für die EMEA/APAC-Region beispielsweise um 10:30 Uhr CET. Die Sessions laufen seit September 2024 und werden auch 2026 fortgesetzt.

Die Contributor Ladder als Karrierepfad

Fahlandt zufolge definiert die sogenannte Contributor Ladder einen transparenten Aufstiegspfad. Vom Non-member Contributor gelangt man über die Org-Membership – für die zwei bestehende Reviewer bürgen müssen – zum Reviewer, Approver und schließlich zum Subproject Owner oder SIG Chair. Fahlandt warnte allerdings vor einer typischen Einstiegsfalle: Wer sich isoliert ein „Good First Issue“ aus dem Repository schnappt und ohne Kontakt zur jeweiligen SIG daran arbeitet, scheitert häufig. Labels wie „good first issue“ oder „help wanted“ in Repositories wie kubernetes/kubernetes markieren zwar geeignete Aufgaben – etwa Dokumentationsverbesserungen, Link-Korrekturen oder Test-Ergänzungen. Doch der Schlüssel zum Erfolg liegt darin, zunächst einer SIG beizutreten, an deren Meetings teilzunehmen und sich dauerhaft einzubringen. Besonders niedrigschwellig sind sogenannte Evergreen-Aufgaben wie Meeting-Protokolle, SIG-Spotlight-Blogposts oder Reviews für die SIG Docs.

Wer den persönlichen Austausch sucht, findet im deutschsprachigen Raum zunehmend Gelegenheit, auf Konferenzen wie CloudLand 2026, den ContainerDays, den Cloud Native Days Austria oder der CLC 2026. Darüber hinaus plant die CNCF regelmäßig Kubernetes Community Days (KCDs), und über Meetup.com sind allein in Deutschland Tausende Mitglieder in Kubernetes-bezogenen Gruppen organisiert.

Fahlandts Fazit bringt die Philosophie der Community auf den Punkt: „Der Einstieg ist nicht immer leicht und das ist verständlicherweise frustrierend. Aber wenn man dranbleibt, lohnt es sich enorm. Wir würden euch gerne dabei helfen, dranzubleiben!“

Über den Speaker

Mario Fahlandt ist Customer Delivery Architect bei Kubermatic. Darüber hinaus engagiert er sich aktiv im Kubernetes-Projekt der CNCF – unter anderem als TAG Co Chair Operational Resilience, SIG Co Chair Contributor Experience, SIG K8s Infra und Comms Subproject Tech Lead.

(map)