msbuild-antipatterns
Detect and fix MSBuild anti-patterns in project and build files. USE WHEN asked to review, audit, lint, clean up, or code-review a .csproj/.vbproj/.fsproj/.props/.targets/.proj (or Directory.Build.props/.targets) file, when asked 'is this project file correct?' or 'what's wrong with my build file?', or when hunting subtle build bugs caused by how a project is authored. Each anti-pattern has a symptom and a concrete BAD→GOOD fix. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), or migrating a project to SDK-style (use msbuild-modernization).
npx skills add dotnet/skills --skill msbuild-antipatterns --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Guides the agent to identify common MSBuild anti-patterns in project and build files and to apply explicit, concrete fixes. It catalogs patterns with a Symptom, Why it's bad, and a Fix that transforms the code to a better form. The catalog covers issues such as using Exec for built-in tasks, unquoted conditions, hardcoded absolute paths, restating SDK defaults, manual file listings in SDK-style projects, legacy Reference with HintPath, missing PrivateAssets on analyzers/tools, cross-file property duplication, scattered package versions, monolithic targets, missing Inputs/Outputs, setting defaults in .targets instead of .props, unguarded optional imports, and path handling concerns. Each entry demonstrates BAD and GOOD examples and prescribes precise edits to adopt the GOOD pattern.
How it works
- The skill presents a catalog of MSBuild anti-patterns, each with: Smell, Why it's bad, and Fix.
- For each anti-pattern, it instructs the agent to locate the bad construct in project/build files and apply the concrete transformation shown under Fix.
- It includes references to best practices like replacing Exec with MSBuild tasks, quoting conditions, using Central Package Management, wiring up Directory.Build.props for shared defaults, and guarding optional imports.
- It enumerates recommended replacements and the exact shape of the GOOD pattern in the corresponding XML snippets.
When to use it
- Use when asked to review, audit, lint, clean up, or code-review a .csproj/.vbproj/.fsproj/.props/.targets/.proj file (or Directory.Build.props/.targets).
- Use when asked 'is this project file correct?' or 'what's wrong with my build file?', or when hunting subtle build bugs caused by how a project is authored.
What it can touch
- The skill references changes to MSBuild XML files and suggests concrete edits such as replacing <Exec> with <MakeDir>/<Copy>/<Delete>, quoting conditions, converting absolute paths to MSBuild properties, removing redundant default property values, and adopting Central Package Management. It implies editing standard MSBuild elements, PropertyGroup blocks, ItemGroup blocks, and Target definitions as shown in the FIX examples.
Caveats
- The catalog explicitly states when patterns are BAD or GOOD and provides concrete fixes; it does not speculate beyond the provided examples.
- It cautions against applying fixes to non-MSBuild systems or migrations to SDK-style (for which another skill is intended).
- License is MIT as declared.
# MSBuild Anti-Pattern Catalog A numbered catalog of common MSBuild anti-patterns. Each entry follows the format: - **Smell**: What to look for - **Why it's bad**: Impact on builds, maintainability, or correctness - **Fix**: Concrete transformation Use this catalog when scanning project files for improvements. --- ## AP-01: `<Exec>` for Operations That Have Built-in Tasks **Smell**: `<Exec Command="mkdir ..." />`, `<Exec Command="copy ..." />`, `<Exec Command="del ..." />` **Why it's bad**: Built-in tasks are cross-platform, support incremental build, emit structured logging, and handle errors consistently. `<Exec>` is opaque to MSBuild. ```xml <!-- BAD --> <Target Name="PrepareOutput"> <Exec Command="mkdir $(OutputPath)logs" /> <Exec Command="copy config.json $(OutputPath)" /> <Exec Command="del $(IntermediateOutputPath)*.tmp" /> </Target> <!-- GOOD --> <Target Name="PrepareOutput"> <MakeDir Directories="$(OutputPath)logs" /> <Copy SourceFiles="config.json" DestinationFolder="$(OutputPath)" /> <Delete Files="@(TempFiles)" /> </Target> ``` **Built-in task alternatives:** | Shell Command | MSBuild Task | |--------------|--------------| | `mkdir` | `<MakeDir>` | | `copy` / `cp` | `<C
- AP-01: <Exec> for Operations That Have Built-in Tasks
- AP-02: Unquoted Condition Expressions
- AP-03: Hardcoded Absolute Paths
- AP-04: Restating SDK Defaults
- AP-05: Manual File Listing in SDK-Style Projects
- AP-06: Using <Reference> with HintPath for NuGet Packages
- AP-07: Missing PrivateAssets="all" on Analyzer/Tool Packages
- AP-08: Copy-Pasted Properties Across Multiple .csproj Files
- AP-09: Scattered Package Versions Without Central Package Management
- AP-10: Monolithic Targets (Too Much in One Target)
- AP-11: Custom Targets Missing Inputs and Outputs
- AP-12: Setting Defaults in .targets Instead of .props
- AP-13: Import Without Exists() Guard
- AP-14: Backslashes in Paths — Where It Matters
What does the msbuild-antipatterns skill do?
Detect and fix MSBuild anti-patterns in project and build files. USE WHEN asked to review, audit, lint, clean up, or code-review a .csproj/.vbproj/.fsproj/.props/.targets/.proj (or Directory.Build.props/.targets) file, when asked 'is this project file correct?' or 'what's wrong with my build file?', or when hunting subtle build bugs caused by how a project is authored. Each anti-pattern has a symptom and a concrete BAD→GOOD fix. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), or migrating a project to SDK-style (use msbuild-modernization).
How do I install it?
Run `npx skills add dotnet/skills --skill msbuild-antipatterns --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dotnet/skills, a repository with 4,927 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.