DEV Community: Vu Le

Tutorial: Running Your C# Code Without a Project File

Vu Le — Mon, 26 May 2025 07:44:00 +0000

Important Note: The ability to run C# files directly using dotnet run file.cs as described here is a feature currently available in the .NET 10 Preview SDK. Ensure you have the .NET 10 Preview SDK installed to follow this tutorial. This feature provides a streamlined way to execute simple C# programs without the traditional .csproj project file setup.

Welcome! This tutorial is designed to guide you through the experience of running a simple C# application directly from a source file using the .NET 10 Preview SDK. This approach, often referred to as running "file-based programs", can be particularly useful for quick tests, learning exercises, or simple scripts where the overhead of a full project structure feels unnecessary. Our goal today is not just to execute some code, but to understand how the .NET Command Line Interface (CLI) in .NET 10 Preview enables this workflow, including how to incorporate external libraries (NuGet packages) and control the underlying SDK used.

Throughout this session, think of me as your guide. We'll take small, manageable steps together. You'll write a basic C# program, and then we'll use the dotnet run command to compile and run it directly. You'll see the output immediately, connecting your action with its result. This immediate feedback is crucial for learning. Don't worry about memorizing every detail right now; the focus is on the doing and observing the outcome. By the end, you'll have successfully run C# code without the usual project setup and gained familiarity with this powerful new feature of the .NET 10 Preview SDK.

Setting the Stage: Your First C# File

Let's begin by creating our C# source file. Open your favorite text editor or integrated development environment (IDE). Create a new file and name it app.cs. The .cs extension is important.

Inside app.cs, let's write a very basic C# program using top-level statements:

// app.cs
using System;

Console.WriteLine("Hello from a project-less world in .NET 10 Preview!");

This code simply prints a message to the console. Save this file.

Running the Basic Code

Now, let's run the simple code we just wrote. Open your terminal or command prompt, navigate to the directory where you saved app.cs, and execute the following command:

dotnet run app.cs

Assuming you have the .NET 10 Preview SDK correctly installed and configured in your PATH, the .NET CLI will compile your app.cs file in memory and run it. You should see the output:

Hello from a project-less world in .NET 10 Preview!

This demonstrates the basic capability. The CLI implicitly creates a minimal project definition based on the default dotnet new console template for the installed SDK version to compile and run your single file.

Adding NuGet Packages with Directives

A key enhancement in the .NET 10 Preview for file-based programs is the ability to reference NuGet packages directly within the source file using special comments called app directives. Let's modify our app.cs to use the popular Humanizer package.

First, add the directive at the top of your app.cs file:

#:package Humanizer@2.*

Now, modify the code to use the package:

// app.cs
#:package Humanizer@2.*

using Humanizer;

// Example: Pluralize a word
string singular = "hobby";
string plural = singular.Pluralize();
Console.WriteLine("Plural of '{0}' is '{1}'", singular, plural);

Save the changes. Now, run the file again using the same command:

dotnet run app.cs

This time, the .NET CLI will detect the #:package directive. It will resolve and download the Humanizer package (if not already cached) and include it during the implicit compilation. The output should now pluralize the word "hobby":

Plural of 'hobby' is 'hobbies'

This demonstrates how easily you can incorporate external libraries into your single-file programs using directives, making this feature much more powerful for scripting and small utilities.

Specifying SDK and Properties (Advanced)

The #:sdk directive allows specifying the project SDK (e.g., #:sdk Microsoft.NET.Sdk.Web for a web context, though single-file execution primarily targets console apps). The #:property directive allows setting MSBuild properties (e.g., #:property LangVersion=preview).

// Example showing potential directives (syntax based on proposal)
#:sdk Microsoft.NET.Sdk
#:property LangVersion=preview
#:package System.CommandLine

// ... rest of your code

These directives further configure the implicit project file generated behind the scenes. While the default (Microsoft.NET.Sdk for console) often suffices, these provide finer control when needed.

Direct Execution with Shebang (Unix-like Systems)

On Unix-like operating systems (Linux, macOS), you can make your C# file directly executable like a shell script by adding a shebang line at the very beginning of the file and setting the execute permission.

Modify your app.cs file to include the shebang line pointing to dotnet run:

#!/usr/bin/env dotnet run

#:package Humanizer@2.*

using Humanizer;

// Example: Pluralize a word
string singular = "hobby";
string plural = singular.Pluralize();
Console.WriteLine("Plural of '{0}' is '{1}'", singular, plural);

Important: The shebang line (#!/usr/bin/env dotnet run) must be the very first line in the file.

Next, you need to make the file executable. Open your terminal in the directory containing app.cs and run:

chmod +x app.cs

Now, you can execute the C# file directly:

./app.cs

The operating system will use the shebang line to invoke /usr/bin/env dotnet run, which in turn will execute your C# code, including processing any directives like #:package. You should see the same output as before, but without explicitly typing dotnet run.

This makes C# files feel even more like native scripts on these platforms, further lowering the barrier for simple tasks and automation.

Understanding the Context and Limitations

Remember, this file-based execution model in .NET 10 Preview is designed for simplicity and quick tasks. The implicit project created is minimal. If your application involves multiple source files interacting in complex ways, requires intricate build configurations, targets multiple frameworks, or has extensive dependencies, transitioning to a standard project structure using a .csproj file is the recommended approach. This feature provides a fantastic low-friction entry point, not a replacement for the full project system in complex scenarios.

The Grow-Up Path

Should your single-file program evolve and require the structure of a full project, .NET 10 Preview provides a command to facilitate this transition. Running dotnet project convert app.cs (syntax based on the proposal) would materialize the implicit project file (.csproj) on disk, allowing you to manage it explicitly.

This concludes our revised tutorial on running C# without a project file using the .NET 10 Preview SDK. You've seen how to run basic files and incorporate NuGet packages using directives, providing a powerful yet simple way to execute C# code.

References

How CSS-in-JS Works and Why It Matters

Vu Le — Mon, 26 May 2025 01:15:39 +0000

🧐 What Is CSS-in-JS?

CSS-in-JS is a styling approach where CSS is written within JavaScript files—often directly inside React components—using libraries like styled-components or Emotion.

Instead of maintaining separate .css files, CSS-in-JS lets you co-locate styles with the components they affect. This improves maintainability, enables powerful tooling (like theming and dynamic styles), and avoids common problems like global namespace collisions.

⚙️ How CSS-in-JS Works Under the Hood

Libraries like styled-components and @emotion/styled turn your style definitions into actual CSS rules injected into the document's <head> at runtime.

Here's what happens:

You Define a Styled Component


import styled from 'styled-components';

const Button = styled.button`
  background: blue;
  color: white;
  padding: 10px;
`;

The Library Generates a Unique Class Name

At build or runtime, the library:

Parses your template literal

Hashes the content to generate a unique class name (e.g., .sc-a1234)

Injects a CSS rule like:

.sc-a1234 {
  background: blue;
  color: white;
  padding: 10px;
}

The Component Renders with That Class

Click me

You never have to manage the class name yourself—the library abstracts that for you.

⚡ Dynamic Styles

You can create styles that react to props or themes:

const Button = styled.button`
  background: ${(props) => props.primary ? 'blue' : 'gray'};
`;

On render, the library evaluates the JavaScript expression, injects a new rule with a unique hash, and updates the DOM.

📚 Theming Support

Libraries like styled-components and emotion support theming out of the box. You define a theme object and wrap your app in a provider:

<ThemeProvider theme={{ primaryColor: 'tomato' }}>
  <App />
</ThemeProvider>

Then access theme values in styles:

const Title = styled.h1`
  color: ${(props) => props.theme.primaryColor};
`;

This enables centralized design tokens (e.g., colors, spacing, breakpoints) across your app.

✅ Benefits

Scoped styles by default (no global leakage)
Dynamic styling using JS expressions
Code co-location (styles + logic together)
Theme-aware styling
Removes need for class naming conventions (e.g., BEM)

🚫 Trade-Offs

Adds runtime overhead (unless extracted at build time)
Debugging can be harder (though devtools have improved)
Requires tooling/bundler support (e.g., Babel plugin for styled-components)

🧪 Popular CSS-in-JS Libraries

Library	Notes
styled-components	Most popular; good developer experience
@emotion/styled	Similar API, faster runtime
vanilla-extract	Type-safe, zero-runtime CSS-in-JS
Stitches	Modern alternative with build-time extraction

🧵 When to Use It

CSS-in-JS shines in:

Component-based architectures (e.g., React)
Design systems with theme support
Projects where dynamic styles or runtime customization are key

It may be overkill for:

Static websites
Projects where global styles or traditional CSS files are sufficient

💡 Summary

CSS-in-JS moves styles into JavaScript for better modularity, dynamic capabilities, and maintainability in modern web apps. Tools like styled-components and emotion streamline the process of defining, scoping, and applying styles while unlocking features like theming and prop-based styling.

It's a powerful paradigm—but like all tools, it's best used where its benefits align with your project's needs.

Handling Input Streams in .NET Applications for Command Pipelines

Vu Le — Tue, 13 May 2025 05:25:18 +0000

When building .NET applications intended for use in console environments, it's essential to design your program to be flexible. One common requirement is to detect whether input is being provided via a command pipeline (i.e., from stdin) and, if not, to perform a default action. This article explores how you can inspect the input stream in your .NET application and adjust behavior accordingly.

Command Pipelines in Linux

In Linux, the pipe operator (|) connects the output of one command to the input of another. For example:

echo "Hello, World!" | dotnet run

In this command, the output of echo is sent to your .NET application via standard input. Your application must determine whether such piped input is present in order to correctly process data or use fallback logic.

Checking for Input in a .NET Application

There are several methods to detect if there's data available on the input stream. Below, we discuss three common approaches.

Detecting Input Redirection

A good workaround is to determine whether the standard input is redirected. .NET provides the Console.IsInputRedirected property, which returns:

true when the input is coming from a pipe or a file.
false when the input is from an interactive terminal session.

Example: Conditional Input Handling

Below is an example that demonstrates how to check for input redirection before attempting to read data. This approach avoids the blocking behavior when no piped data is provided:

if (Console.IsInputRedirected)
{
    string input = Console.In.ReadToEnd();
    Console.WriteLine("Received Input: " + input);
}
else
{
    Console.WriteLine("No input detected; proceeding with default action.");
}

Integrating with Command Pipelines

By combining these methods with Linux command pipelines, your .NET application can operate intelligently based on the source of its input. For instance, consider the pipeline:

cat sample.txt | dotnet run

When data is piped into your application from sample.txt, one of the methods above detects the input and processes it. If no data is piped, your application can execute alternative logic. This flexibility makes your application robust and adaptable to various runtime conditions.

Conclusion

Detecting whether an input stream contains data is crucial when designing .NET applications that interact with command pipelines.

Fast Static Website Deployment using Pulumi for C#

Vu Le — Sat, 05 Apr 2025 04:55:12 +0000

This is a submission for the Pulumi Deploy and Document Challenge: Fast Static Website Deployment

What I Built

A sample Pulumi project that demonstrates how to deploy a Blazor WebAssembly using Azure Static Web Apps. The project is designed to be simple and easy to understand, making it a great starting point for anyone looking to learn about deploying static web apps with Pulumi.

Live Demo Link

Link to Azure Static Web App

It may not be available in the future, so I uploaded a recording here

https://raw.githubusercontent.com/levu74/my-blazor-pulumi-swa/refs/heads/main/docs/images/project-demo.gif

Project Repo

levu74 / my-blazor-pulumi-swa

Fast Static Web App deployment using Pulumi

This repository contains a sample Pulumi project that demonstrates how to deploy a static web app using Azure Static Web Apps. The project is designed to be simple and easy to understand, making it a great starting point for anyone looking to learn about deploying static web apps with Pulumi.

Architecture Overview

The diagram shows a complete deployment pipeline with the following components:

GitHub Repository: Source code is stored in GitHub for version control
Azure Pipelines: Handles CI/CD processes
Azure Identity/Service Principal: Manages access to Azure resources and assigned to Azure Pipelines
Azure Static Web App: Hosting platform for the Blazor application
Azure Key Vault: Securely stores secrets including the Static Web App deployment token
Pulumi: Infrastructure as Code (IaC) tool used to manage the deployment of the Azure resources

Worklow

Developers write code and push it to GitHub
GitHub triggers Azure Pipelines…

View on GitHub

My Journey

As a .NET developer, I recently began using Pulumi to provision infrastructure. Although I'm new to Pulumi, I didn’t face many significant challenges thanks to my development background. The Pulumi SDK for C# made the transition easier, as it allows developers to use familiar language features while performing tasks typically handled by DevOps or platform engineers.

Setting up the stack
I successfully set up a Pulumi stack and ran it locally without issues. The execution logs are clear and informative, which made it easy to understand what was happening during deployments. When I encountered issues, I was able to debug my Pulumi project using the launch.json configuration in Visual Studio Code—this was a big help in quickly identifying and fixing problems.

"configurations": [
      {
        "type": "pulumi",
        "request": "launch",
        "name": "pulumi preview",
        "command": "preview",
        "workDir": "${workspaceFolder}/infra/pulumi/Blazor.Infra.Pulumi"
      }
    ]

CI/CD Pipeline Integration
One challenge I faced was integrating Pulumi into the CI/CD pipeline. The Pulumi CLI did not work properly with Azure Workload Identity, which caused deployment failures. I resolved this by switching to the Pulumi task available in the Azure DevOps Marketplace, which worked seamlessly.

- task: Pulumi@1
  inputs:
    azureSubscription: $(ado.azureServiceConnection)
    command: up
    cwd: infra/pulumi/Blazor.Infra.Pulumi
    stack: $(environment)
    args: "--yes"

Managing State
Pulumi’s approach to storing infrastructure state is helpful for visualizing changes over time. It allows me to track the history of deployed resources and view their outputs in a centralized and structured manner.

Using Pulumi

In this project, I leveraged Pulumi with C# to create and manage Azure infrastructure as code (IaC) for my Blazor application. As a .NET developer, Pulumi's C# SDK offered a familiar programming model while allowing me to define cloud resources with strongly-typed constructs.

Stack Architecture

My StaticWebAppStack.cs creates several Azure resources:

Resource Group - Container for all project resources
Static Web App - Hosting platform for my Blazor application
Key Vault - Secure storage for deployment tokens
Key Vault Secret - Storing the Static Web App deployment token

Benefits of Using Pulumi

1. Native Language Experience:

Using C# meant I could apply my existing .NET skills:

   var staticWebApp = new Az.Web.StaticSite(staticWebAppName, new()
   {
       ResourceGroupName = resourceGroup.Name,
       Location = resourceGroup.Location,
       Sku = new Az.Web.Inputs.SkuDescriptionArgs
       {
           Tier = "Free",
           Name = "Free"
       },
       // ...
   });

2. Secret Management:

I could programmatically retrieve and securely store tokens:

   var deploymentToken = staticWebAppSecrets.Apply(secrets =>
   {
       return secrets.Properties.Where(x => x.Key == "apiKey").FirstOrDefault().Value;
   });

   var staticWebAppTokenSecret = new Az.KeyVault.Secret("staticWebAppTokenSecret", new()
   {
       ResourceGroupName = resourceGroup.Name,
       VaultName = keyVault.Name,
       SecretName = "swaDeploymentToken",
       Properties = new Az.KeyVault.Inputs.SecretPropertiesArgs
       {
           Value = deploymentToken,
           ContentType = "text/plain",
       }
   });

3. Using Stack Outputs for CI/CD integration:

I defined outputs to expose important information for CI/CD:

   [Output("keyVaultName")]
   public Output<string> KeyVaultName { get; private set; }

Using Pulumi's outputs for next deployment stage

  - script: |
      pulumi stack select $(environment)
      KEYVAULT_NAME=$(pulumi stack output keyVaultName)
      echo "##vso[task.setvariable variable=keyVaultName;isOutput=true]$KEYVAULT_NAME"
    displayName: "Set stack outputs as variables"
    workingDirectory: infra/pulumi/Blazor.Infra.Pulumi
    name: "setOutputs"

4. Stack for Environment-based configuration:

Using stack references for environment-specific configurations:

   var stackName = Deployment.Instance.StackName;
   var projectName = Deployment.Instance.ProjectName;
   var fullStackName = $"{projectName}-{stackName}";

5. Integration with CI/CD:

Easily integrating with Azure Pipelines using the Pulumi task:

   - task: Pulumi@1
     inputs:
       azureSubscription: $(ado.azureServiceConnection)
       command: up
       cwd: infra/pulumi/Blazor.Infra.Pulumi
       stack: $(environment)
       args: "--yes"

Conclusion

Pulumi's approach to IaC using familiar programming languages significantly improved my development workflow. Instead of treating infrastructure as a separate concern with its own syntax and tools, I could apply the same software engineering principles I use in application development to my infrastructure code.