SShortSingh.
Back to feed

NET 10 Lets Developers Run C# Files Directly as Shell Scripts

0
·5 views

Microsoft's .NET 10 introduces a feature that allows developers to execute a single C# source file as a script without creating a project file or build directory. A developer tested this capability on a Linux container using SDK 10.0.302, finding that after an initial 10.5-second cold start to restore packages and compile, subsequent runs take roughly 0.3 seconds. The feature supports NuGet package references via inline directives and Unix shebang lines, making C# scripts executable directly from the terminal. Build artifacts are stored in a hidden cache folder, keeping the working directory clean like a standard shell script. The developer concluded that for tasks more complex than a simple one-liner, this workflow is now a practical alternative to bash or Python scripting.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Log in to join the discussion and vote.

Log in

Related stories

0
ProgrammingDEV Community ·

WordPress Plugin Theme Demo Import Has Critical File Upload Flaw Enabling Remote Code Execution

A critical authenticated arbitrary file upload vulnerability, tracked as CVE-2026-13157, has been discovered in the Theme Demo Import WordPress plugin by security researcher Huynh Kien Minh. The flaw affects all versions up to and including 1.1.3 of the plugin. It stems from the plugin's AJAX demo import function deliberately disabling WordPress's built-in file-type verification, allowing authenticated users with import privileges to upload executable PHP files. These malicious files are stored in the publicly accessible wp-content/uploads/ directory, enabling full Remote Code Execution and potential server compromise. Site administrators using the affected plugin are advised to review their installations and apply remediation measures promptly.

0
ProgrammingDEV Community ·

Three-Prompt Routine to Verify AI Output Accuracy Before Shipping Code or Docs

A developer has shared a structured three-step verification routine designed to catch errors in AI-generated content before it reaches production systems. The workflow consists of a hallucination sweep that labels all factual claims, an adversarial stress-test that builds the case against a single load-bearing claim, and a stakes-based checklist that prioritizes the most damaging potential errors first. The author argues that most verification failures occur in steps two and three, which people typically skip after an instinctive first pass. In a test case, the checklist prompt correctly flagged a false claim about PostgreSQL extension upgrades being automatic as HIGH stakes, identifying it as the claim that could invalidate an entire database migration plan. The prompts are designed to be copy-pasted directly into an AI tool, making the process take minutes rather than a lengthy manual review.

0
ProgrammingDEV Community ·

Go Newcomer Fixes Kubernetes 1.31 Permission Bug in k9s After 48-Hour Debug Sprint

A developer with just three weeks of Go experience successfully merged a fix into k9s, the widely used Kubernetes terminal UI with over 58,000 GitHub stars. The bug stemmed from Kubernetes 1.31 introducing a WebSocket-based port-forwarding path that requires only the 'get' verb, while k9s was still checking for the 'create' verb used by the older SPDY protocol. This mismatch caused k9s to silently disable the port-forward option for users who had valid 'get'-only RBAC permissions, even though kubectl worked correctly for them. The contributor traced the issue through client-go source code, worked through a failed first attempt, and ultimately delivered a targeted two-line fix. The case highlights how protocol-level changes in Kubernetes can surface subtle authorization mismatches in tools that wrap the core API.

0
ProgrammingDEV Community ·

How a Database-Level Idempotency Key Prevents Duplicate Records

Duplicate database records can arise from network retries, browser timeouts, proxy retries, and frontend bugs — not just accidental double-clicks. Application-level checks like 'check-then-act' logic are vulnerable to race conditions under concurrency, allowing two requests to pass validation before either has inserted a row. The reliable fix is to enforce uniqueness at the database level by adding a unique constraint on an idempotency key field, since PostgreSQL treats the check and insert as a single atomic operation. On the frontend, a UUID idempotency key should be generated once per operation and reused across all retry attempts, rather than regenerated per request. This pattern applies broadly to any data-creation endpoint, including invoices, orders, payments, and registrations.