Detailed Description

Modern C# development requires a well-configured, efficient development environment that enables developers to write clean, maintainable code while leveraging the latest language features and tools. Setting up a professional C# development environment goes far beyond simply installing an IDE; it involves understanding the ecosystem, configuring tools for optimal productivity, establishing coding standards, and creating a workflow that supports both individual development and team collaboration. This lesson provides a comprehensive guide to establishing a robust, production-ready C# development environment that aligns with industry best practices and modern software development methodologies.

The importance of a properly configured development environment cannot be overstated. In today's fast-paced software development landscape, developers spend significant time writing, debugging, and maintaining code. A well-optimized environment can dramatically improve productivity, reduce errors, and enhance code quality. Professional organizations invest considerable resources in standardizing their development environments to ensure consistency across teams, facilitate onboarding of new developers, and maintain high code quality standards. Whether you're building enterprise applications, cloud-native microservices, desktop applications, or mobile backends, your development environment serves as the foundation for all your coding activities.

Key concepts in modern C# development environment setup include understanding the difference between the .NET SDK and runtime, comprehending the role of integrated development environments (IDEs) versus lightweight code editors, mastering version control integration, and implementing code quality tools. The .NET SDK contains all the tools necessary to build, test, and publish .NET applications, while the runtime is required only to run applications. Visual Studio 2022 represents Microsoft's flagship IDE with comprehensive features for enterprise development, while Visual Studio Code offers a lightweight, extensible alternative. Understanding when to use each tool, how to configure them for maximum efficiency, and how to integrate supporting tools like Git, NuGet, and various extensions creates a development workflow that maximizes both individual and team productivity.

Real-world applications of proper environment setup manifest across various scenarios. In enterprise environments, standardized development environments ensure that code written by one developer can be seamlessly built and debugged by another, regardless of their local machine configuration. In open-source projects, clear environment setup documentation enables contributors worldwide to quickly get started and make meaningful contributions. For continuous integration and continuous deployment (CI/CD) pipelines, understanding environment configuration translates directly to creating reliable build processes. DevOps teams leverage environment configuration knowledge to create containerized development environments using Docker, ensuring perfect consistency between development, testing, and production environments.

Throughout this lesson, you'll master several critical competencies. First, you'll learn to install and configure Visual Studio 2022 with the optimal workloads and extensions for modern C# development. You'll understand how to install and manage multiple .NET SDK versions side-by-side, crucial for maintaining legacy applications while building new ones. You'll establish coding standards using EditorConfig files that ensure consistent formatting across your team. You'll integrate Git for version control and learn to leverage its features directly within your IDE. You'll configure debugging tools, understand how to use performance profiling tools, and set up unit testing frameworks. Additionally, you'll learn to create solution structures that scale from small projects to large enterprise applications, implement dependency management using NuGet, and configure build and deployment scripts.

By the end of this lesson, you won't just have a working C# development environment—you'll have a professional-grade setup that reflects industry best practices. You'll understand not only what to install, but why each component matters and how it contributes to your overall development workflow. This foundational knowledge will serve you throughout your C# development career, whether you're building your first console application or architecting complex distributed systems.

Core Installation Components

Understanding the .NET Ecosystem

The .NET ecosystem has evolved significantly, and understanding its components is crucial for proper environment setup. Modern .NET (formerly .NET Core) is cross-platform, open-source, and represents the future of .NET development. When setting up your environment, you need to understand the distinction between the SDK and the Runtime, and how versioning works.

.NET SDK Installation and Management

The .NET SDK includes everything you need to build, test, and publish .NET applications. It includes the compiler, language servers, CLI tools, and the runtime. Here's how to verify and manage your .NET installation:

# Check installed .NET SDK versions
dotnet --list-sdks

# Check installed .NET Runtime versions
dotnet --list-runtimes

# Check the current .NET version being used
dotnet --version

# Create a global.json to pin SDK version for a project
dotnet new globaljson --sdk-version 8.0.100

# Display information about installed .NET
dotnet --info

Visual Studio 2022 Installation and Configuration

Visual Studio 2022 is a powerful IDE that provides comprehensive tools for C# development. Proper installation involves selecting the right workloads and understanding component options.

Essential Workloads to Install

ASP.NET and web development - For building web applications and APIs
.NET desktop development - For Windows desktop applications (WPF, WinForms)
Azure development - For cloud-native application development
Data storage and processing - For database integration and data-driven applications
.NET Core cross-platform development - For building cross-platform applications

Git Configuration

Git is essential for version control in modern software development. Proper Git configuration ensures smooth collaboration and version tracking.

# Configure your identity
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# Set default branch name
git config --global init.defaultBranch main

# Configure line endings (Windows)
git config --global core.autocrlf true

# Configure line endings (Mac/Linux)
git config --global core.autocrlf input

# Set default editor
git config --global core.editor "code --wait"

# Enable credential caching
git config --global credential.helper cache

# Configure pull behavior
git config --global pull.rebase false

# View all configurations
git config --list

Practical Examples

Example 1: Creating a Multi-Project Solution with Proper Structure

This example demonstrates how to create a well-structured solution from the command line, establishing best practices for project organization. This structure scales from small to enterprise applications.

# Navigate to your projects directory
cd ~/projects

# Create solution directory
mkdir TaskManagementSystem
cd TaskManagementSystem

# Create a new solution file
dotnet new sln -n TaskManagementSystem

# Create source directory structure
mkdir src
mkdir tests
mkdir docs

# Create core domain project (business logic)
cd src
dotnet new classlib -n TaskManagementSystem.Core -f net8.0
dotnet sln ../TaskManagementSystem.sln add TaskManagementSystem.Core/TaskManagementSystem.Core.csproj

# Create infrastructure project (data access, external services)
dotnet new classlib -n TaskManagementSystem.Infrastructure -f net8.0
dotnet sln ../TaskManagementSystem.sln add TaskManagementSystem.Infrastructure/TaskManagementSystem.Infrastructure.csproj

# Add reference from Infrastructure to Core
cd TaskManagementSystem.Infrastructure
dotnet add reference ../TaskManagementSystem.Core/TaskManagementSystem.Core.csproj
cd ..

# Create API project
dotnet new webapi -n TaskManagementSystem.Api -f net8.0
dotnet sln ../TaskManagementSystem.sln add TaskManagementSystem.Api/TaskManagementSystem.Api.csproj

# Add references from API to Core and Infrastructure
cd TaskManagementSystem.Api
dotnet add reference ../TaskManagementSystem.Core/TaskManagementSystem.Core.csproj
dotnet add reference ../TaskManagementSystem.Infrastructure/TaskManagementSystem.Infrastructure.csproj
cd ../..

# Create unit test project
cd tests
dotnet new xunit -n TaskManagementSystem.UnitTests -f net8.0
dotnet sln ../TaskManagementSystem.sln add TaskManagementSystem.UnitTests/TaskManagementSystem.UnitTests.csproj

# Add reference from tests to Core
cd TaskManagementSystem.UnitTests
dotnet add reference ../../src/TaskManagementSystem.Core/TaskManagementSystem.Core.csproj
cd ../..

# Build the entire solution to verify structure
dotnet build

# Output structure verification
tree -L 3  # On Unix-based systems
# or use: dir /s /b  # On Windows

Explanation: This example creates a clean architecture solution structure. The Core project contains domain models and business logic with no external dependencies. Infrastructure handles data access and external service integrations. The API project serves as the application entry point. The test project contains unit tests. This separation of concerns makes the codebase maintainable and testable.

Expected Output: You'll have a solution with four projects properly referenced. Running dotnet build should succeed with no errors, confirming all projects compile and references are correct.

Best Practice: Always separate concerns into distinct projects. Keep your Core project free of infrastructure dependencies to maintain testability and flexibility.

Common Mistake: Avoid creating circular dependencies between projects. Core should never reference Infrastructure or API projects.

Example 2: Configuring EditorConfig for Code Consistency

EditorConfig files ensure consistent coding styles across different editors and team members. This example creates a comprehensive .editorconfig file for C# projects.

# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

# All files
[*]
charset = utf-8
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true
end_of_line = lf

# XML project files
[*.{csproj,vbproj,vcxproj,vcxproj.filters,proj,projitems,shproj}]
indent_size = 2

# XML config files
[*.{props,targets,ruleset,config,nuspec,resx,vsixmanifest,vsct}]
indent_size = 2

# JSON files
[*.json]
indent_size = 2

# YAML files
[*.{yml,yaml}]
indent_size = 2

# Markdown files
[*.md]
trim_trailing_whitespace = false

# C# files
[*.cs]

#### Core EditorConfig Options ####

# Indentation and spacing
indent_size = 4
tab_width = 4

# New line preferences
csharp_new_line_before_open_brace = all
csharp_new_line_before_else = true
csharp_new_line_before_catch = true
csharp_new_line_before_finally = true
csharp_new_line_before_members_in_object_initializers = true
csharp_new_line_before_members_in_anonymous_types = true
csharp_new_line_between_query_expression_clauses = true

# Organize usings
dotnet_sort_system_directives_first = true
dotnet_separate_import_directive_groups = false

# this. preferences
dotnet_style_qualification_for_field = false:warning
dotnet_style_qualification_for_property = false:warning
dotnet_style_qualification_for_method = false:warning
dotnet_style_qualification_for_event = false:warning

# Language keywords vs BCL types preferences
dotnet_style_predefined_type_for_locals_parameters_members = true:warning
dotnet_style_predefined_type_for_member_access = true:warning

# Parentheses preferences
dotnet_style_parentheses_in_arithmetic_binary_operators = always_for_clarity:suggestion
dotnet_style_parentheses_in_relational_binary_operators = always_for_clarity:suggestion
dotnet_style_parentheses_in_other_binary_operators = always_for_clarity:suggestion
dotnet_style_parentheses_in_other_operators = never_if_unnecessary:suggestion

# Modifier preferences
dotnet_style_require_accessibility_modifiers = always:warning
csharp_preferred_modifier_order = public,private,protected,internal,static,extern,new,virtual,abstract,sealed,override,readonly,unsafe,volatile,async:suggestion

# Expression-level preferences
dotnet_style_object_initializer = true:suggestion
dotnet_style_collection_initializer = true:suggestion
dotnet_style_explicit_tuple_names = true:warning
dotnet_style_prefer_inferred_tuple_names = true:suggestion
dotnet_style_prefer_inferred_anonymous_type_member_names = true:suggestion
dotnet_style_prefer_auto_properties = true:suggestion
dotnet_style_prefer_conditional_expression_over_assignment = true:suggestion
dotnet_style_prefer_conditional_expression_over_return = true:suggestion
dotnet_style_prefer_compound_assignment = true:suggestion

# Null-checking preferences
dotnet_style_coalesce_expression = true:warning
dotnet_style_null_propagation = true:warning
dotnet_style_prefer_is_null_check_over_reference_equality_method = true:warning

# C# Code Style Rules

# var preferences
csharp_style_var_for_built_in_types = true:suggestion
csharp_style_var_when_type_is_apparent = true:suggestion
csharp_style_var_elsewhere = true:suggestion

# Expression-bodied members
csharp_style_expression_bodied_methods = when_on_single_line:suggestion
csharp_style_expression_bodied_constructors = false:suggestion
csharp_style_expression_bodied_operators = when_on_single_line:suggestion
csharp_style_expression_bodied_properties = true:suggestion
csharp_style_expression_bodied_indexers = true:suggestion
csharp_style_expression_bodied_accessors = true:suggestion
csharp_style_expression_bodied_lambdas = true:suggestion
csharp_style_expression_bodied_local_functions = when_on_single_line:suggestion

# Pattern matching preferences
csharp_style_pattern_matching_over_is_with_cast_check = true:warning
csharp_style_pattern_matching_over_as_with_null_check = true:warning
csharp_style_prefer_switch_expression = true:suggestion
csharp_style_prefer_pattern_matching = true:suggestion
csharp_style_prefer_not_pattern = true:suggestion

# Null-checking preferences
csharp_style_throw_expression = true:suggestion
csharp_style_prefer_null_check_over_type_check = true:suggestion

# Code block preferences
csharp_prefer_braces = true:warning
csharp_prefer_simple_using_statement = true:suggestion

# 'using' directive preferences
csharp_using_directive_placement = outside_namespace:warning

# Naming Conventions
dotnet_naming_rule.interfaces_should_be_prefixed_with_i.severity = warning
dotnet_naming_rule.interfaces_should_be_prefixed_with_i.symbols = interface
dotnet_naming_rule.interfaces_should_be_prefixed_with_i.style = begins_with_i

dotnet_naming_rule.types_should_be_pascal_case.severity = warning
dotnet_naming_rule.types_should_be_pascal_case.symbols = types
dotnet_naming_rule.types_should_be_pascal_case.style = pascal_case

dotnet_naming_rule.non_field_members_should_be_pascal_case.severity = warning
dotnet_naming_rule.non_field_members_should_be_pascal_case.symbols = non_field_members
dotnet_naming_rule.non_field_members_should_be_pascal_case.style = pascal_case

# Symbol specifications
dotnet_naming_symbols.interface.applicable_kinds = interface
dotnet_naming_symbols.interface.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected

dotnet_naming_symbols.types.applicable_kinds = class, struct, interface, enum
dotnet_naming_symbols.types.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected

dotnet_naming_symbols.non_field_members.applicable_kinds = property, event, method
dotnet_naming_symbols.non_field_members.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected

# Naming styles
dotnet_naming_style.pascal_case.capitalization = pascal_case

dotnet_naming_style.begins_with_i.required_prefix = I
dotnet_naming_style.begins_with_i.capitalization = pascal_case

Explanation: This comprehensive EditorConfig file enforces consistent coding standards across your team. It covers indentation, spacing, naming conventions, and modern C# style preferences. The severity levels (warning, suggestion, error) control how violations are reported in your IDE.

Usage: Place this file at the root of your solution. Visual Studio and Visual Studio Code will automatically detect and apply these settings. When you save files or run code cleanup, the rules will be enforced.

Best Practice: Commit the .editorconfig file to version control so all team members use identical coding standards.

Customization Tip: Adjust severity levels based on your team's preferences. Use "error" for critical violations, "warning" for important conventions, and "suggestion" for stylistic preferences.

Example 3: Setting Up a Development Container Configuration

Modern development increasingly uses containers for consistent environments. This example creates a Dev Container configuration for VS Code that includes all necessary tools for C# development.

// .devcontainer/devcontainer.json
{
    "name": "C# Development Environment",
    "image": "mcr.microsoft.com/devcontainers/dotnet:8.0",
    
    // Configure tool-specific properties
    "customizations": {
        "vscode": {
            // Extensions to install in the container
            "extensions": [
                "ms-dotnettools.csharp",
                "ms-dotnettools.csdevkit",
                "kreativ-software.csharpextensions",
                "jongrant.csharpsortusings",
                "patcx.vscode-nuget-gallery",
                "formulahendry.dotnet-test-explorer",
                "editorconfig.editorconfig",
                "github.copilot",
                "eamodio.gitlens",
                "ms-azuretools.vscode-docker",
                "humao.rest-client"
            ],
            
            // VS Code settings for the container
            "settings": {
                "terminal.integrated.defaultProfile.linux": "bash",
                "dotnet.enableXamarinForms": false,
                "omnisharp.useModernNet": true,
                "csharp.suppressDotnetRestoreNotification": true,
                "editor.formatOnSave": true,
                "editor.formatOnPaste": true,
                "editor.codeActionsOnSave": {
                    "source.organizeImports": true,
                    "source.fixAll": true
                },
                "files.exclude": {
                    "**/bin": true,
                    "**/obj": true
                }
            }
        }
    },
    
    // Features to add to the dev container
    "features": {
        "ghcr.io/devcontainers/features/git:1": {
            "version": "latest"
        },
        "ghcr.io/devcontainers/features/github-cli:1": {
            "version": "latest"
        },
        "ghcr.io/devcontainers/features/azure-cli:1": {
            "version": "latest"
        },
        "ghcr.io/devcontainers/features/docker-in-docker:2": {
            "version": "latest",
            "moby": true
        },
        "ghcr.io/devcontainers/features/node:1": {
            "version": "lts"
        }
    },
    
    // Ports to forward from the container to the local machine
    "forwardPorts": [5000, 5001, 5432, 6379],
    
    // Port attributes
    "portsAttributes": {
        "5000": {
            "label": "Application HTTP",
            "onAutoForward": "notify"
        },
        "5001": {
            "label": "Application HTTPS",
            "onAutoForward": "notify"
        },
        "5432": {
            "label": "PostgreSQL",
            "onAutoForward": "silent"
        },
        "6379": {
            "label": "Redis",
            "onAutoForward": "silent"
        }
    },
    
    // Commands to run after the container is created
    "postCreateCommand": "dotnet restore && dotnet build",
    
    // Commands to run after starting the container
    "postStartCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}",
    
    // Set the user for all operations
    "remoteUser": "vscode",
    
    // Mounts for preserving data
    "mounts": [
        "source=${localEnv:HOME}${localEnv:USERPROFILE}/.nuget/packages,target=/home/vscode/.nuget/packages,type=bind,consistency=cached",
        "source=${localEnv:HOME}${localEnv:USERPROFILE}/.azure,target=/home/vscode/.azure,type=bind,consistency=cached"
    ],
    
    // Environment variables
    "remoteEnv": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "DOTNET_USE_POLLING_FILE_WATCHER": "true",
        "NUGET_XMLDOC_MODE": "skip"
    }
}

// .devcontainer/docker-compose.yml (Optional: for multi-service development)
version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity
    network_mode: service:db
    depends_on:
      - db
      - redis

  db:
    image: postgres:15
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: devpassword
      POSTGRES_DB: taskmanagement

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis-data:/data

volumes:
  postgres-data:
  redis-data:

Explanation: This Dev Container configuration creates a fully-configured C# development environment inside a Docker container. It includes the .NET 8.0 SDK, essential VS Code extensions, and development services like PostgreSQL and Redis. The configuration ensures every developer has an identical environment, eliminating "works on my machine" issues.

Usage: Place the devcontainer.json file in a .devcontainer directory at your solution root. When you open the folder in VS Code, it will prompt you to reopen in the container. All development happens inside the container, with your source code mounted from your host machine.

Benefits: New team members can start development immediately without installing tools locally. The environment is reproducible and can be version-controlled. Different projects can have different environments without conflicts.

Best Practice: Mount .nuget packages and .azure credentials from your host to avoid re-downloading packages and re-authenticating on container restarts.

Example 4: Creating a Comprehensive Build and CI Script

Automated build scripts ensure consistent builds across different environments. This example demonstrates a PowerShell script for building, testing, and packaging a C# solution.

# build.ps1 - Comprehensive build script for C# projects

param(
    [string]$Configuration = "Release",
    [string]$Version = "1.0.0",
    [switch]$Clean,
    [switch]$SkipTests,
    [switch]$Pack,
    [string]$OutputPath = "./artifacts"
)

# Script configuration
$ErrorActionPreference = "Stop"
$solutionPath = "TaskManagementSystem.sln"
$testResultsPath = "$OutputPath/test-results"

# Color output functions
function Write-Header {
    param([string]$Message)
    Write-Host "`n========================================" -ForegroundColor Cyan
    Write-Host $Message -ForegroundColor Cyan
    Write-Host "========================================`n" -ForegroundColor Cyan
}

function Write-Success {
    param([string]$Message)
    Write-Host "✓ $Message" -ForegroundColor Green
}

function Write-Error-Message {
    param([string]$Message)
    Write-Host "✗ $Message" -ForegroundColor Red
}

function Write-Info {
    param([string]$Message)
    Write-Host "ℹ $Message" -ForegroundColor Yellow
}

# Clean output directories
if ($Clean) {
    Write-Header "Cleaning solution..."
    
    if (Test-Path $OutputPath) {
        Remove-Item -Path $OutputPath -Recurse -Force
        Write-Success "Removed artifacts directory"
    }
    
    dotnet clean $solutionPath --configuration $Configuration
    Write-Success "Solution cleaned"
    
    # Remove bin and obj folders
    Get-ChildItem -Include bin,obj -Recurse -Directory | Remove-Item -Recurse -Force
    Write-Success "Removed bin/obj directories"
}

# Restore dependencies
Write-Header "Restoring NuGet packages..."
dotnet restore $solutionPath
if ($LASTEXITCODE -ne 0) {
    Write-Error-Message "Package restore failed"
    exit $LASTEXITCODE
}
Write-Success "Packages restored successfully"

# Build solution
Write-Header "Building solution..."
Write-Info "Configuration: $Configuration"
Write-Info "Version: $Version"

dotnet build $solutionPath `
    --configuration $Configuration `
    --no-restore `
    /p:Version=$Version `
    /p:TreatWarningsAsErrors=true `
    /p:WarningLevel=4

if ($LASTEXITCODE -ne 0) {
    Write-Error-Message "Build failed"
    exit $LASTEXITCODE
}
Write-Success "Build completed successfully"

# Run tests
if (-not $SkipTests) {
    Write-Header "Running tests..."
    
    # Create test results directory
    New-Item -ItemType Directory -Force -Path $testResultsPath | Out-Null
    
    # Run tests with coverage
    dotnet test $solutionPath `
        --configuration $Configuration `
        --no-build `
        --logger "trx;LogFileName=test-results.trx" `
        --results-directory $testResultsPath `
        --collect:"XPlat Code Coverage" `
        -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=opencover
    
    if ($LASTEXITCODE -ne 0) {
        Write-Error-Message "Tests failed"
        exit $LASTEXITCODE
    }
    
    Write-Success "All tests passed"
    
    # Display test results summary
    $testResultFile = Get-ChildItem -Path $testResultsPath -Filter "*.trx" | Select-Object -First 1
    if ($testResultFile) {
        [xml]$testResults = Get-Content $testResultFile.FullName
        $summary = $testResults.TestRun.ResultSummary
        Write-Info "Total: $($summary.Counters.total), Passed: $($summary.Counters.passed), Failed: $($summary.Counters.failed)"
    }
}

# Package projects
if ($Pack) {
    Write-Header "Creating NuGet packages..."
    
    $packOutput = "$OutputPath/packages"
    New-Item -ItemType Directory -Force -Path $packOutput | Out-Null
    
    dotnet pack $solutionPath `
        --configuration $Configuration `
        --no-build `
        --output $packOutput `
        /p:Version=$Version `
        /p:PackageVersion=$Version
    
    if ($LASTEXITCODE -ne 0) {
        Write-Error-Message "Package creation failed"
        exit $LASTEXITCODE
    }
    
    Write-Success "Packages created successfully"
    Get-ChildItem -Path $packOutput -Filter "*.nupkg" | ForEach-Object {
        Write-Info "Created: $($_.Name) ($([math]::Round($_.Length / 1KB, 2)) KB)"
    }
}

# Publish applications
Write-Header "Publishing applications..."

$publishProjects = @(
    "src/TaskManagementSystem.Api/TaskManagementSystem.Api.csproj"
)

foreach ($project in $publishProjects) {
    if (Test-Path $project) {
        $projectName = [System.IO.Path]::GetFileNameWithoutExtension($project)
        $publishOutput = "$OutputPath/publish/$projectName"
        
        Write-Info "Publishing $projectName..."
        
        dotnet publish $project `
            --configuration $Configuration `
            --no-build `
            --output $publishOutput `
            /p:Version=$Version
        
        if ($LASTEXITCODE -eq 0) {
            Write-Success "$projectName published to $publishOutput"
        } else {
            Write-Error-Message "Failed to publish $projectName"
            exit $LASTEXITCODE
        }
    }
}

# Generate build report
Write-Header "Build Summary"
Write-Success "Configuration: $Configuration"
Write-Success "Version: $Version"
Write-Success "Output: $OutputPath"

if (Test-Path $OutputPath) {
    $totalSize = (Get-ChildItem -Path $OutputPath -Recurse -File | Measure-Object -Property Length -Sum).Sum
    Write-Info "Total artifacts size: $([math]::Round($totalSize / 1MB, 2)) MB"
}

Write-Host "`n✓ Build completed successfully!" -ForegroundColor Green

Explanation: This PowerShell build script automates the entire build process, including cleaning, restoring packages, building, testing, and packaging. It provides colored console output for better readability and includes error handling to stop on failures. The script is parameterized, allowing different build configurations and optional steps.

Usage: Run from PowerShell with various options:

./build.ps1 - Default release build with tests
./build.ps1 -Configuration Debug -Clean - Clean debug build
./build.ps1 -Version 2.0.0 -Pack - Build and create NuGet packages
./build.ps1 -SkipTests - Build without running tests (useful for quick iterations)

CI/CD Integration: This script can be called from any CI/CD system (Azure DevOps, GitHub Actions, Jenkins) ensuring consistent builds across local and server environments.

Best Practice: Keep build scripts in version control and document all parameters. This script serves as executable documentation of your build process.

Example 5: Setting Up Global Tools and Useful CLI Extensions

The .NET CLI can be extended with global tools that enhance development productivity. This example shows how to install and configure useful global tools.

#!/bin/bash
# setup-dotnet-tools.sh - Install useful .NET global tools

echo "Installing .NET Global Tools..."
echo "================================"

# Tool manifest for project-local tools
echo "Creating tool manifest for local tools..."
dotnet new tool-manifest

# Install Entity Framework Core tools (global)
echo "Installing Entity Framework Core tools..."
dotnet tool install --global dotnet-ef
# Project-local version
dotnet tool install dotnet-ef

# Install Coverlet for code coverage
echo "Installing Coverlet