What do you check before pushing code to main or releasing a production application? A successful build is a good start, but stale solution references, inconsistent NuGet versions, missing ignore rules, and expiring certificates can still cause trouble.
The dotNetTips.com Spargine Global Dev Tool helps you spot these issues through commands that examine your solution, repositories, packages, and development environment. Saving the results gives you something concrete to review before the next push or deployment.
To make these checks easier to repeat, I put nine Spargine commands into a single PowerShell script. It generates seven Markdown reports and a Mermaid dependency diagram, merges missing .gitignore rules, and consolidates inconsistent NuGet package versions. It also cleans up the local NuGet caches.
The goal is simple: make project maintenance a routine part of your workflow so your code is ready to rock before it reaches main or production.
Nine Spargine Commands to Check Your Solution
The script runs the following commands in order. Here is what each command does with the options used in this script.
1. audit — Check Solution and Repository Hygiene
Finds solution references to missing project files, project folders absent from discovered solutions, and large files typically excluded from source control, such as .suo, .user, and files under bin or obj.
Report: audit-report.md
2. disk — Review Development Disk Usage
Reports development-related disk usage, including the NuGet package cache, global .NET tools, bin and obj folders, and Docker storage when Docker is available. Use this report to identify development artifacts consuming the most space.
Report: disk-report.md
3. git-status — Check Repository Status
Scans for Git repositories and reports uncommitted changes, unpushed commits, commits behind the upstream branch, and branches other than main or master. It fetches remote updates before comparing commit counts.
Report: git-status-report.md
4. gitignore — Merge Missing Ignore Rules
Compares the existing .gitignore with GitHub’s Visual Studio template. The –merge option appends missing rules while preserving the file’s existing content.
This command updates .gitignore directly; the script does not save a separate report file for it.
5. graph — Map Project Dependencies
Maps project-to-project dependencies into a Mermaid diagram, helping you understand how your solution’s projects connect. It uses the first discovered solution, or the discovered project files when no solution is found.
Diagram: dependency-graph.mmd
6. health — Check Frameworks and Project Settings
Checks target frameworks against the default net8.0 minimum and identifies missing settings for nullable reference types and implicit usings.
The command also supports vulnerable and outdated NuGet package checks, but those require additional flags that this script does not supply. The metrics command performs those package checks in this workflow.
Report: health-report.md
7. metrics — Track Build and Package Health
Builds discovered solutions, records warning and error counts, checks for vulnerable and outdated NuGet packages, and saves historical snapshots. These snapshots help you see whether project quality is improving or declining over time.
Report: metrics-report.md
The tool also maintains a rolling JSON history for tracking trends between runs.
8. nuget — Consolidate Package Versions and Clear Caches
Finds NuGet package-version mismatches across projects. The –consolidate option updates affected project references to the highest version already found across the scanned projects.
The –clear-cache option clears local NuGet caches before scanning. Cache clearing is skipped automatically when Visual Studio is running.
Report: nuget-report.md
This command can also modify project files. Consolidation aligns versions already present in your projects; it does not automatically select the latest version available on NuGet.
9. secrets — Review Certificates and Sensitive Files
Checks the developer HTTPS certificate and certificate files for expiration issues. It also flags potentially sensitive files, such as .env files and secrets.json, for source-control review.
Report: secrets-report.md
Review the .gitignore and project-file changes before committing them.
Automate the Checks with PowerShell
Run the following script on Windows with PowerShell 5.1 or later and Spargine available on your PATH. Start from the root folder of the solution you want to check. The gitignore command expects an existing .gitignore in that folder.
The script uses the current PowerShell working directory, regardless of where the script itself is stored. It creates a docs\Reports folder under that directory if the folder does not exist, then saves the seven Markdown reports and Mermaid diagram there. You can change the destination through the $reportsDirectory assignment.
Each command runs in sequence. If an individual command fails, the script records the failure and continues with the remaining commands. After all commands have been attempted, it reports any collected failures.
#Requires -Version 5.1
<#
.SYNOPSIS
Runs Spargine maintenance commands and generates reports for the current directory.
.DESCRIPTION
Uses the PowerShell working directory when the script is invoked, regardless of
where the script itself is stored. Creates docs\reports if it does not exist.
Runs every command in order and reports any failures after all commands finish.
.EXAMPLE
Set-Location 'C:\Source\MyProject'
& 'C:\Scripts\Invoke-SpargineReports.ps1'
\#>
[CmdletBinding()]
param()
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
$workingDirectory = Get-Location
if ($workingDirectory.Provider.Name -ne 'FileSystem') {
throw 'Run this script from a filesystem directory.'
}
$spargineCommand = Get-Command -Name 'spargine' -CommandType Application -ErrorAction Stop
$reportsDirectory = Join-Path -Path (Join-Path -Path $workingDirectory.Path -ChildPath 'Docs') -ChildPath 'Reports'
New-Item -Path $reportsDirectory -ItemType Directory -Force | Out-Null
$commands = @(
@{ Name = 'audit'; Arguments = @('audit', '--output', (Join-Path $reportsDirectory 'audit-report.md')) }
@{ Name = 'disk'; Arguments = @('disk', '--output', (Join-Path $reportsDirectory 'disk-report.md')) }
@{ Name = 'git-status'; Arguments = @('git-status', '--output', (Join-Path $reportsDirectory 'git-status-report.md')) }
@{ Name = 'gitignore'; Arguments = @('gitignore', '--merge') }
@{ Name = 'graph'; Arguments = @('graph', '--output', (Join-Path $reportsDirectory 'dependency-graph.mmd')) }
@{ Name = 'health'; Arguments = @('health', '--output', (Join-Path $reportsDirectory 'health-report.md')) }
@{ Name = 'metrics'; Arguments = @('metrics', '--output', (Join-Path $reportsDirectory 'metrics-report.md')) }
@{ Name = 'nuget'; Arguments = @('nuget', '--clear-cache', '--consolidate', '--output', (Join-Path $reportsDirectory 'nuget-report.md')) }
@{ Name = 'secrets'; Arguments = @('secrets', '--output', (Join-Path $reportsDirectory 'secrets-report.md')) }
)
$failures = [System.Collections.Generic.List[string]]::new()
Write-Host "Working directory: $($workingDirectory.Path)"
Write-Host "Report directory: $reportsDirectory"
foreach ($command in $commands) {
Write-Host "\`nRunning spargine $($command.Name)..."
$commandArguments = $command.Arguments
try {
# Array splatting preserves output paths that contain spaces.
& $spargineCommand.Source @commandArguments
if ($LASTEXITCODE -ne 0) {
$failure = "$($command.Name) (exit code $LASTEXITCODE)"
$failures.Add($failure)
Write-Warning "Spargine failed: $failure"
}
}
catch {
$failure = "$($command.Name): $($\_.Exception.Message)"
$failures.Add($failure)
Write-Warning "Spargine failed: $failure"
}
}
if ($failures.Count -gt 0) {
throw "Spargine finished with $($failures.Count) failed command(s): $($failures -join '; ')"
}
Write-Host "\`nAll Spargine commands completed successfully. Reports: $reportsDirectory"
Review the Results Before You Push or Deploy
I recommend making this script part of your regular development workflow: run it before pushing code to main and before deploying to production. Read the reports, investigate failed commands, and address findings that affect your release.
Pay particular attention to build errors, vulnerable packages, broken project references, sensitive files, and the changes made by .gitignore merging and NuGet consolidation. Because metrics runs before nuget changes package references, rebuild and rerun your tests after consolidation to validate the resulting dependency versions. These checks complement your code reviews, automated tests, and deployment validation. The value comes from acting on the results. Give your solution a regular checkup, fix what needs attention, and keep your releases rockin’!
Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks
Make a one-time donation
Make a monthly donation
Make a yearly donation
Choose an amount
Or enter a custom amount
Your contribution is appreciated.
Your contribution is appreciated.
Your contribution is appreciated.
If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave
© The information in this article is copywritten and cannot be reproduced in any way without express permission from David McCarter.
Discover more from dotNetTips.com
Subscribe to get the latest posts sent to your email.
