[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699ETYD346AVVPN0KF7A1M8":3,"skill-same:01M699ETYD346AVVPN0KF7A1M8":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M699ETYD346AVVPN0KF7A1M8","msbuild-antipatterns",null,"Review\u002Faudit MSBuild XML correctness and maintainability, including F# order and Import safety; not SDK-style migration. Do not edit unless fixes are requested.","microsoft\u002Ftestfx","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699C71CJ91B5WZ3AXG3GG2M",1059,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmsbuild-antipatterns\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"msbuild antipatterns","msbuild","antipatterns","review","sdk","xml","audit","Safety","edit","migration","do","maintainability","style","import","correctness","fixes","2026-11-10 10:12:30",false,"---\nname: msbuild-antipatterns\ndescription: \"Review\u002Faudit MSBuild XML correctness and maintainability, including F# order and Import safety; not SDK-style migration. Do not edit unless fixes are requested.\"\nlicense: MIT\n---\n\n# MSBuild Anti-Pattern Catalog\n\n## Scope and routing\n\nDO NOT INVOKE when the primary request explicitly asks to convert, migrate, modernize, or rewrite a legacy\u002Fold-style project to SDK style; use msbuild-modernization. Migration prompts often mention ToolsVersion, explicit Compile\u002FReference entries, packages.config, or Microsoft.CSharp.targets, but merely reviewing or auditing a file that contains those patterns remains in scope here. USE FOR broad review, audit, lint, or maintainability\u002Fcorrectness checks of project\u002Fbuild files, including custom targets; prioritized cross-cutting findings; discrete anti-patterns; F# ordering\u002FFS0039; cross-platform paths; and focused Import safety verdicts. Review\u002Faudit is analysis-only unless fixes are requested. For concrete property\u002Fitem defects use property-patterns\u002Fitem-management; use target-authoring for implementation and extension-points for NuGet auto-import\u002Flayout discovery. Exclude non-MSBuild systems.\n\nA numbered catalog of common MSBuild anti-patterns. Each entry follows the format:\n\n- **Smell**: What to look for\n- **Why it's bad**: Impact on builds, maintainability, or correctness\n- **Fix**: Concrete transformation\n\nUse this catalog when scanning project files for improvements.\n\n## Review output contract\n\nFor review, audit, maintainability, or correctness-risk requests:\n\n1. Do not edit files unless the user explicitly asks for fixes.\n2. Return prioritized findings grounded in the supplied file, with impact and a targeted recommendation.\n3. Separate confirmed defects from conditional risks and already-correct patterns.\n4. Keep the final answer as the review; do not replace it with a terse summary of changes.\n\n---\n\n## AP-01: `\u003CExec>` for Operations That Have Built-in Tasks\n\n**Smell**: `\u003CExec Command=\"mkdir ...\" \u002F>`, `\u003CExec Command=\"copy ...\" \u002F>`, `\u003CExec Command=\"del ...\" \u002F>`\n\n**Why it's bad**: Built-in tasks are cross-platform, support incremental build, emit structured logging, and handle errors consistently. `\u003CExec>` is opaque to MSBuild.\n\n```xml\n\u003C!-- BAD -->\n\u003CTarget Name=\"PrepareOutput\">\n  \u003CExec Command=\"mkdir $(OutputPath)logs\" \u002F>\n  \u003CExec Command=\"copy config.json $(OutputPath)\" \u002F>\n  \u003CExec Command=\"del $(IntermediateOutputPath)*.tmp\" \u002F>\n\u003C\u002FTarget>\n\n\u003C!-- GOOD -->\n\u003CTarget Name=\"PrepareOutput\">\n  \u003CMakeDir Directories=\"$(OutputPath)logs\" \u002F>\n  \u003CCopy SourceFiles=\"config.json\" DestinationFolder=\"$(OutputPath)\" \u002F>\n  \u003CDelete Files=\"@(TempFiles)\" \u002F>\n\u003C\u002FTarget>\n```\n\n**Built-in task alternatives:**\n\n| Shell Command | MSBuild Task |\n|--------------|--------------|\n| `mkdir` | `\u003CMakeDir>` |\n| `copy` \u002F `cp` | `\u003CCopy>` |\n| `del` \u002F `rm` | `\u003CDelete>` |\n| `move` \u002F `mv` | `\u003CMove>` |\n| `echo text > file` | `\u003CWriteLinesToFile>` |\n| `touch` | `\u003CTouch>` |\n| `xcopy \u002Fs` | `\u003CCopy>` with item globs |\n\n---\n\n## AP-02: Unquoted Condition Expressions\n\n**Smell**: `Condition=\"$(Foo) == Bar\"` — either side of a comparison is unquoted.\n\n**Why it's bad**: If the property is empty or contains spaces\u002Fspecial characters, the condition evaluates incorrectly or throws a parse error. MSBuild requires single-quoted strings for reliable comparisons.\n\n```xml\n\u003C!-- BAD -->\n\u003CPropertyGroup Condition=\"$(Configuration) == Release\">\n  \u003COptimize>true\u003C\u002FOptimize>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD -->\n\u003CPropertyGroup Condition=\"'$(Configuration)' == 'Release'\">\n  \u003COptimize>true\u003C\u002FOptimize>\n\u003C\u002FPropertyGroup>\n```\n\n**Rule**: Always quote **both** sides of `==` and `!=` comparisons with single quotes.\n\n---\n\n## AP-03: Hardcoded Absolute Paths\n\n**Smell**: Paths like `C:\\tools\\`, `D:\\packages\\`, `\u002Fusr\u002Flocal\u002Fbin\u002F` in project files.\n\n**Why it's bad**: Breaks on other machines, CI environments, and other operating systems. Not relocatable.\n\n```xml\n\u003C!-- BAD -->\n\u003CPropertyGroup>\n  \u003CToolPath>C:\\tools\\mytool\\mytool.exe\u003C\u002FToolPath>\n\u003C\u002FPropertyGroup>\n\u003CImport Project=\"C:\\repos\\shared\\common.props\" \u002F>\n\n\u003C!-- GOOD -->\n\u003CPropertyGroup>\n  \u003CToolPath>$(MSBuildThisFileDirectory)tools\\mytool\\mytool.exe\u003C\u002FToolPath>\n\u003C\u002FPropertyGroup>\n\u003CImport Project=\"$(RepoRoot)eng\\common.props\" \u002F>\n```\n\n**Preferred path properties:**\n\n| Property | Meaning |\n|----------|---------|\n| `$(MSBuildThisFileDirectory)` | Directory of the current .props\u002F.targets file |\n| `$(MSBuildProjectDirectory)` | Directory of the .csproj |\n| `$([MSBuild]::GetDirectoryNameOfFileAbove(...))` | Walk up to find a marker file |\n| `$([MSBuild]::NormalizePath(...))` | Combine and normalize path segments |\n\n---\n\n## AP-04: Restating SDK Defaults\n\n**Smell**: Properties set to values that the .NET SDK already provides by default.\n\n**Why it's bad**: Adds noise, hides intentional overrides, and makes it harder to identify what's actually customized. When defaults change in newer SDKs, the redundant properties may silently pin old behavior.\n\n```xml\n\u003C!-- BAD: All of these are already the default -->\n\u003CPropertyGroup>\n  \u003COutputType>Library\u003C\u002FOutputType>\n  \u003CEnableDefaultItems>true\u003C\u002FEnableDefaultItems>\n  \u003CEnableDefaultCompileItems>true\u003C\u002FEnableDefaultCompileItems>\n  \u003CRootNamespace>MyLib\u003C\u002FRootNamespace>       \u003C!-- matches project name -->\n  \u003CAssemblyName>MyLib\u003C\u002FAssemblyName>         \u003C!-- matches project name -->\n  \u003CAppendTargetFrameworkToOutputPath>true\u003C\u002FAppendTargetFrameworkToOutputPath>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Only non-default values -->\n\u003CPropertyGroup>\n  \u003CTargetFramework>net8.0\u003C\u002FTargetFramework>\n\u003C\u002FPropertyGroup>\n```\n\n---\n\n## AP-05: Manual File Listing in SDK-Style Projects\n\n**Smell**: `\u003CCompile Include=\"File1.cs\" \u002F>`, `\u003CCompile Include=\"File2.cs\" \u002F>` in SDK-style projects.\n\n**Why it's bad**: SDK-style projects automatically glob `**\u002F*.cs` (and other file types). Explicit listing is redundant, creates merge conflicts, and new files may be accidentally missed if not added to the list.\n\n```xml\n\u003C!-- BAD -->\n\u003CItemGroup>\n  \u003CCompile Include=\"Program.cs\" \u002F>\n  \u003CCompile Include=\"Services\\MyService.cs\" \u002F>\n  \u003CCompile Include=\"Models\\User.cs\" \u002F>\n\u003C\u002FItemGroup>\n\n\u003C!-- GOOD: Remove entirely — SDK includes all .cs files by default.\n     Only use Remove\u002FExclude when you need to opt out: -->\n\u003CItemGroup>\n  \u003CCompile Remove=\"LegacyCode\\**\" \u002F>\n\u003C\u002FItemGroup>\n```\n\n**Exception**: Non-SDK-style (legacy) projects require explicit file includes. If migrating, see `msbuild-modernization` skill.\n\n**Exception (F# \u002F `.fsproj`)**: F# compilation is order-dependent — the compiler processes `\u003CCompile Include>` items sequentially and a file can only reference types\u002Fmodules declared in files listed above it. `.fsproj` files must therefore list every source file explicitly, in dependency order (utility\u002Fleaf modules at the top, the entry point such as `Program.fs` at the bottom). If a `.fsi` signature file is used, it must appear **immediately before** its companion `.fs` implementation file.\n\n---\n\n## AP-06: Using `\u003CReference>` with HintPath for NuGet Packages\n\n**Smell**: `\u003CReference Include=\"...\" HintPath=\"..\\packages\\SomePackage\\lib\\...\" \u002F>`\n\n**Why it's bad**: This is the legacy `packages.config` pattern. It doesn't support transitive dependencies, version conflict resolution, or automatic restore. The `packages\u002F` folder must be committed or restored separately.\n\n```xml\n\u003C!-- BAD -->\n\u003CItemGroup>\n  \u003CReference Include=\"Newtonsoft.Json\">\n    \u003CHintPath>..\\packages\\Newtonsoft.Json.13.0.3\\lib\\netstandard2.0\\Newtonsoft.Json.dll\u003C\u002FHintPath>\n  \u003C\u002FReference>\n\u003C\u002FItemGroup>\n\n\u003C!-- GOOD -->\n\u003CItemGroup>\n  \u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n\u003C\u002FItemGroup>\n```\n\n**Note**: `\u003CReference>` without HintPath is still valid for .NET Framework GAC assemblies like `WindowsBase`, `PresentationCore`, etc.\n\n---\n\n## AP-07: Missing `PrivateAssets=\"all\"` on Analyzer\u002FTool Packages\n\n**Smell**: `\u003CPackageReference Include=\"StyleCop.Analyzers\" Version=\"...\" \u002F>` without `PrivateAssets=\"all\"`.\n\n**Why it's bad**: Without `PrivateAssets=\"all\"`, analyzer and build-tool packages flow as transitive dependencies to consumers of your library. Consumers get unwanted analyzers or build-time tools they didn't ask for.\n\nSee [`references\u002Fprivate-assets.md`](references\u002Fprivate-assets.md) for BAD\u002FGOOD examples and the full list of packages that need this.\n\n---\n\n## AP-08: Copy-Pasted Properties Across Multiple .csproj Files\n\n**Smell**: The same `\u003CPropertyGroup>` block appears in 3+ project files.\n\n**Why it's bad**: Maintenance burden — a change must be made in every file. Inconsistencies creep in over time.\n\n```xml\n\u003C!-- BAD: Repeated in every .csproj -->\n\u003C!-- ProjectA.csproj, ProjectB.csproj, ProjectC.csproj all have: -->\n\u003CPropertyGroup>\n  \u003CNullable>enable\u003C\u002FNullable>\n  \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n  \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Define once in Directory.Build.props at the repo\u002Fsrc root -->\n\u003C!-- Directory.Build.props -->\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CNullable>enable\u003C\u002FNullable>\n    \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n    \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\nSee `directory-build-organization` skill for full guidance on structuring `Directory.Build.props` \u002F `Directory.Build.targets`.\n\n---\n\n## AP-09: Scattered Package Versions Without Central Package Management\n\n**Smell**: `\u003CPackageReference Include=\"X\" Version=\"1.2.3\" \u002F>` with different versions of the same package across projects.\n\n**Why it's bad**: Version drift — different projects use different versions of the same package, leading to runtime mismatches, unexpected behavior, or diamond dependency conflicts.\n\n```xml\n\u003C!-- BAD: Version specified in each project, can drift -->\n\u003C!-- ProjectA.csproj -->\n\u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.1\" \u002F>\n\u003C!-- ProjectB.csproj -->\n\u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n```\n\n**Fix:** Use Central Package Management. See [https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fconsume-packages\u002Fcentral-package-management](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fconsume-packages\u002Fcentral-package-management) for details.\n\n---\n\n## AP-10: Monolithic Targets (Too Much in One Target)\n\n**Smell**: A single `\u003CTarget>` with 50+ lines doing multiple unrelated things.\n\n**Why it's bad**: Can't skip individual steps via incremental build, hard to debug, hard to extend, and the target name becomes meaningless.\n\n```xml\n\u003C!-- BAD -->\n\u003CTarget Name=\"PrepareRelease\" BeforeTargets=\"Build\">\n  \u003CWriteLinesToFile File=\"version.txt\" Lines=\"$(Version)\" Overwrite=\"true\" \u002F>\n  \u003CCopy SourceFiles=\"LICENSE\" DestinationFolder=\"$(OutputPath)\" \u002F>\n  \u003CExec Command=\"signtool sign \u002Ff cert.pfx $(OutputPath)*.dll\" \u002F>\n  \u003CMakeDir Directories=\"$(OutputPath)docs\" \u002F>\n  \u003CCopy SourceFiles=\"@(DocFiles)\" DestinationFolder=\"$(OutputPath)docs\" \u002F>\n  \u003C!-- ... 30 more lines ... -->\n\u003C\u002FTarget>\n\n\u003C!-- GOOD: Single-responsibility targets -->\n\u003CTarget Name=\"WriteVersionFile\" BeforeTargets=\"CoreCompile\"\n        Inputs=\"$(MSBuildProjectFile)\" Outputs=\"$(IntermediateOutputPath)version.txt\">\n  \u003CWriteLinesToFile File=\"$(IntermediateOutputPath)version.txt\" Lines=\"$(Version)\" Overwrite=\"true\" \u002F>\n\u003C\u002FTarget>\n\n\u003CTarget Name=\"CopyLicense\" AfterTargets=\"Build\">\n  \u003CCopy SourceFiles=\"LICENSE\" DestinationFolder=\"$(OutputPath)\" SkipUnchangedFiles=\"true\" \u002F>\n\u003C\u002FTarget>\n\n\u003CTarget Name=\"SignAssemblies\" AfterTargets=\"Build\" DependsOnTargets=\"CopyLicense\"\n        Condition=\"'$(SignAssemblies)' == 'true'\">\n  \u003CExec Command=\"signtool sign \u002Ff cert.pfx %(AssemblyFiles.Identity)\" \u002F>\n\u003C\u002FTarget>\n```\n\n---\n\n## AP-11: Custom Targets Missing `Inputs` and `Outputs`\n\n**Smell**: `\u003CTarget Name=\"MyTarget\" BeforeTargets=\"Build\">` with no `Inputs` \u002F `Outputs` attributes.\n\n**Why it's bad**: The target runs on every build, even when nothing changed. This defeats incremental build and slows down no-op builds.\n\nSee [`references\u002Fincremental-build-inputs-outputs.md`](references\u002Fincremental-build-inputs-outputs.md) for BAD\u002FGOOD examples and the full pattern including FileWrites registration.\n\nSee `incremental-build` skill for deep guidance on Inputs\u002FOutputs, FileWrites, and up-to-date checks.\n\n---\n\n## AP-12: Setting Defaults in .targets Instead of .props\n\n**Smell**: `\u003CPropertyGroup>` with default values inside a `.targets` file.\n\n**Why it's bad**: `.targets` files are imported late (after project files). By the time they set defaults, other `.targets` files may have already used the empty\u002Fundefined value. `.props` files are imported early and are the correct place for defaults.\n\n```xml\n\u003C!-- BAD: custom.targets -->\n\u003CPropertyGroup>\n  \u003CMyToolVersion>2.0\u003C\u002FMyToolVersion>\n\u003C\u002FPropertyGroup>\n\u003CTarget Name=\"RunMyTool\">\n  \u003CExec Command=\"mytool --version $(MyToolVersion)\" \u002F>\n\u003C\u002FTarget>\n\n\u003C!-- GOOD: Split into .props (defaults) + .targets (logic) -->\n\u003C!-- custom.props (imported early) -->\n\u003CPropertyGroup>\n  \u003CMyToolVersion Condition=\"'$(MyToolVersion)' == ''\">2.0\u003C\u002FMyToolVersion>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- custom.targets (imported late) -->\n\u003CTarget Name=\"RunMyTool\">\n  \u003CExec Command=\"mytool --version $(MyToolVersion)\" \u002F>\n\u003C\u002FTarget>\n```\n\n**Rule**: `.props` = defaults and settings (evaluated early). `.targets` = build logic and targets (evaluated late).\n\n---\n\n## AP-13: Import Without `Exists()` Guard\n\n**Smell**: `\u003CImport Project=\"some-file.props\" \u002F>` without a `Condition=\"Exists('...')\"` check.\n\n**Why it's bad**: If the file doesn't exist (not yet created, wrong path, deleted), the build fails with a confusing error. Optional imports should always be guarded.\n\n```xml\n\u003C!-- BAD -->\n\u003CImport Project=\"$(RepoRoot)eng\\custom.props\" \u002F>\n\n\u003C!-- GOOD: Guard optional imports -->\n\u003CImport Project=\"$(RepoRoot)eng\\custom.props\" Condition=\"Exists('$(RepoRoot)eng\\custom.props')\" \u002F>\n\n\u003C!-- ALSO GOOD: Sdk attribute imports don't need guards (they're required by design) -->\n\u003CProject Sdk=\"Microsoft.NET.Sdk\">\n```\n\n**Exception — required imports**: Imports that are *required* for the build to work correctly should fail fast — don't guard those. Guard imports that are optional or environment-specific (e.g., local developer overrides, CI-specific settings).\n\n**Exception — NuGet package forwarders**: `.props`\u002F`.targets` files inside a NuGet package's per-TFM `build\u002F` or `buildTransitive\u002F` folder routinely import a sibling file under `buildTransitive\u002F\u003Ctfm>\u002F…` without an `Exists()` guard. These are a **package contract**: the target file is guaranteed to be present in the restored package, even if it doesn't appear in the source tree at that relative path. The package layout is typically produced by:\n\n- A custom `.nuspec` with per-TFM `\u003Cfile>` entries — e.g. `\u003Cfile src=\"buildTransitive\\common\\MyAdapter.props\" target=\"buildTransitive\\net8.0\\MyAdapter.props\" \u002F>` — that copy files from a single source folder (such as `buildTransitive\u002Fcommon\u002F`) into per-TFM subfolders at pack time, or\n- `\u003CNone Update=\"...\">` \u002F `\u003CContent Include=\"...\">` items in the `.csproj` with a per-TFM `\u003CPackagePath>` (e.g. `\u003CPackagePath>buildTransitive\u002Fnet8.0\u002F\u003C\u002FPackagePath>`), declared once per target TFM, or\n- SDK conventions (e.g. `IncludeBuildOutput`, `BuildOutputTargetFolder`) that place built outputs under `build\u002F\u003Ctfm>\u002F`.\n\nBefore flagging an unguarded `\u003CImport>` inside a `build\u002F` or `buildTransitive\u002F` folder, **resolve it against the packed layout** — read every `*.nuspec` in the project directory **and its immediate parent directory** (shared nuspecs are common in mono-repos; do not walk further up), and any `\u003CPackagePath>` metadata on `\u003CNone>`\u002F`\u003CContent>` items in the `.csproj`. Only flag if the target path is missing from **both** the source tree *and* the projected package layout. The `dotnet-msbuild\u002Fextension-points` skill — *Source tree vs packed layout* — documents the full cross-check procedure.\n\n**Forwarding `buildTransitive\u002F` → `build\u002F`:** forward through the sibling `build\u002F*.props` \u002F `build\u002F*.targets` file (not directly to `buildMultiTargeting\u002F`); when `build\u002F` is per-TFM (`build\u002F\u003Ctfm>\u002F`), include the TFM segment derived from the file's own folder (not `$(TargetFramework)`), or transitive consumers hit `MSB4019`. See the `extension-points` skill — *Forwarding chain* — for the rule and derivation expression.\n\n---\n\n## AP-14: Backslashes in Paths — Where It Matters\n\n**Smell**: Backslash path separators in `.props`\u002F`.targets` files meant to run cross-platform.\n\n**Where this is a real bug (? Error)** — paths that MSBuild does **not** route through its path normalizer:\n\n- Raw shell strings inside `\u003CExec Command=\"...\\tools\\foo.exe ...\" \u002F>` — passed verbatim to `bash`\u002F`sh` on Unix, which treats `\\` as an escape.\n- Backslash-delimited paths inside CDATA blocks, embedded in source files written by `\u003CWriteLinesToFile>`, or constructed for non-MSBuild consumers (custom scripts, response files, environment variables).\n- Paths handed to custom tasks that call OS file APIs directly without going through MSBuild path utilities.\n\n**Where this is only a style preference (? Style)** — paths that go through MSBuild's evaluator (`\u003CImport Project=\"...\">`, file-path properties consumed by built-in tasks like `\u003CCopy>`\u002F`\u003CMakeDir>`\u002F`\u003CDelete>`, item `Include=`\u002F`Exclude=` globs):\n\nMSBuild's evaluator normalizes `\\` → `\u002F` on Unix-like systems before resolving the path. See `FileUtilities.MaybeAdjustFilePath` and `ConvertToUnixSlashes` in [`microsoft\u002Fmsbuild` `src\u002FFramework\u002FFileUtilities.cs`](https:\u002F\u002Fgithub.com\u002Fdotnet\u002Fmsbuild\u002Fblob\u002Fmain\u002Fsrc\u002FFramework\u002FFileUtilities.cs). So `\u003CImport Project=\"$(MSBuildThisFileDirectory)..\\..\\build\\common.props\" \u002F>` resolves correctly on Linux\u002FmacOS today. Forward slashes are still **preferred for consistency**, but the import will not break and existing backslash-style imports should not be flagged as ? **Error**.\n\n```xml\n\u003C!-- ? Error: \\ in raw shell string breaks on Linux\u002FmacOS -->\n\u003CExec Command=\"$(MSBuildThisFileDirectory)tools\\release\\sign.exe $(OutputPath)\" \u002F>\n\n\u003C!-- ? Style: \\ in Import is normalized on Unix, but \u002F is nicer -->\n\u003CImport Project=\"$(MSBuildThisFileDirectory)..\\..\\build\\common.props\" \u002F>\n\n\u003C!-- ✅ Recommended in new code -->\n\u003CImport Project=\"$(MSBuildThisFileDirectory)..\u002F..\u002Fbuild\u002Fcommon.props\" \u002F>\n```\n\n**Verification rule**: Before flagging a backslash path as ? **Error**, ask *\"does this string flow through MSBuild's evaluator, or is it handed verbatim to a non-MSBuild consumer?\"* Only the second case is a correctness defect.\n\n**Note**: `$(MSBuildThisFileDirectory)` already ends with a platform-appropriate separator, so `$(MSBuildThisFileDirectory)tools\u002Fmytool` works on both platforms.\n\n---\n\n## AP-15: Unconditional Property Override in Multiple Scopes\n\n**Smell**: A property set unconditionally in both `Directory.Build.props` and a `.csproj` — last write wins silently.\n\n**Why it's bad**: Hard to trace which value is actually used. Makes the build fragile and confusing for anyone reading the project files.\n\n```xml\n\u003C!-- BAD: Directory.Build.props sets it, csproj silently overrides -->\n\u003C!-- Directory.Build.props -->\n\u003CPropertyGroup>\n  \u003COutputPath>bin\\custom\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\u003C!-- MyProject.csproj -->\n\u003CPropertyGroup>\n  \u003COutputPath>bin\\other\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Use a condition so overrides are intentional -->\n\u003C!-- Directory.Build.props -->\n\u003CPropertyGroup>\n  \u003COutputPath Condition=\"'$(OutputPath)' == ''\">bin\\custom\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\u003C!-- MyProject.csproj can now intentionally override or leave the default -->\n```\n\n---\n\nFor additional anti-patterns (AP-16 through AP-23) and a quick-reference checklist, see [additional-antipatterns.md](references\u002Fadditional-antipatterns.md).\n","# MSBuild Anti-Pattern Catalog\n\n## Scope and routing\n\nDO NOT INVOKE when the primary request explicitly asks to convert, migrate, modernize, or rewrite a legacy\u002Fold-style project to SDK style; use msbuild-modernization. Migration prompts often mention ToolsVersion, explicit Compile\u002FReference entries, packages.config, or Microsoft.CSharp.targets, but merely reviewing or auditing a file that contains those patterns remains in scope here. USE FOR broad review, audit, lint, or maintainability\u002Fcorrectness checks of project\u002Fbuild files, including custom targets; prioritized cross-cutting findings; discrete anti-patterns; F# ordering\u002FFS0039; cross-platform paths; and focused Import safety verdicts. Review\u002Faudit is analysis-only unless fixes are requested. For concrete property\u002Fitem defects use property-patterns\u002Fitem-management; use target-authoring for implementation and extension-points for NuGet auto-import\u002Flayout discovery. Exclude non-MSBuild systems.\n\nA numbered catalog of common MSBuild anti-patterns. Each entry follows the format:\n\n- **Smell**: What to look for\n- **Why it's bad**: Impact on builds, maintainability, or correctness\n- **Fix**: Concrete transformation\n\nUse this catalog when scanning project files for improvements.\n\n## Review output contract\n\nFor review, audit, maintainability, or correctness-risk requests:\n\n1. Do not edit files unless the user explicitly asks for fixes.\n2. Return prioritized findings grounded in the supplied file, with impact and a targeted recommendation.\n3. Separate confirmed defects from conditional risks and already-correct patterns.\n4. Keep the final answer as the review; do not replace it with a terse summary of changes.\n\n---\n\n## AP-01: `\u003CExec>` for Operations That Have Built-in Tasks\n\n**Smell**: `\u003CExec Command=\"mkdir ...\" \u002F>`, `\u003CExec Command=\"copy ...\" \u002F>`, `\u003CExec Command=\"del ...\" \u002F>`\n\n**Why it's bad**: Built-in tasks are cross-platform, support incremental build, emit structured logging, and handle errors consistently. `\u003CExec>` is opaque to MSBuild.\n\n```xml\n\u003C!-- BAD -->\n\u003CTarget Name=\"PrepareOutput\">\n  \u003CExec Command=\"mkdir $(OutputPath)logs\" \u002F>\n  \u003CExec Command=\"copy config.json $(OutputPath)\" \u002F>\n  \u003CExec Command=\"del $(IntermediateOutputPath)*.tmp\" \u002F>\n\u003C\u002FTarget>\n\n\u003C!-- GOOD -->\n\u003CTarget Name=\"PrepareOutput\">\n  \u003CMakeDir Directories=\"$(OutputPath)logs\" \u002F>\n  \u003CCopy SourceFiles=\"config.json\" DestinationFolder=\"$(OutputPath)\" \u002F>\n  \u003CDelete Files=\"@(TempFiles)\" \u002F>\n\u003C\u002FTarget>\n```\n\n**Built-in task alternatives:**\n\n| Shell Command | MSBuild Task |\n|--------------|--------------|\n| `mkdir` | `\u003CMakeDir>` |\n| `copy` \u002F `cp` | `\u003CCopy>` |\n| `del` \u002F `rm` | `\u003CDelete>` |\n| `move` \u002F `mv` | `\u003CMove>` |\n| `echo text > file` | `\u003CWriteLinesToFile>` |\n| `touch` | `\u003CTouch>` |\n| `xcopy \u002Fs` | `\u003CCopy>` with item globs |\n\n---\n\n## AP-02: Unquoted Condition Expressions\n\n**Smell**: `Condition=\"$(Foo) == Bar\"` — either side of a comparison is unquoted.\n\n**Why it's bad**: If the property is empty or contains spaces\u002Fspecial characters, the condition evaluates incorrectly or throws a parse error. MSBuild requires single-quoted strings for reliable comparisons.\n\n```xml\n\u003C!-- BAD -->\n\u003CPropertyGroup Condition=\"$(Configuration) == Release\">\n  \u003COptimize>true\u003C\u002FOptimize>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD -->\n\u003CPropertyGroup Condition=\"'$(Configuration)' == 'Release'\">\n  \u003COptimize>true\u003C\u002FOptimize>\n\u003C\u002FPropertyGroup>\n```\n\n**Rule**: Always quote **both** sides of `==` and `!=` comparisons with single quotes.\n\n---\n\n## AP-03: Hardcoded Absolute Paths\n\n**Smell**: Paths like `C:\\tools\\`, `D:\\packages\\`, `\u002Fusr\u002Flocal\u002Fbin\u002F` in project files.\n\n**Why it's bad**: Breaks on other machines, CI environments, and other operating systems. Not relocatable.\n\n```xml\n\u003C!-- BAD -->\n\u003CPropertyGroup>\n  \u003CToolPath>C:\\tools\\mytool\\mytool.exe\u003C\u002FToolPath>\n\u003C\u002FPropertyGroup>\n\u003CImport Project=\"C:\\repos\\shared\\common.props\" \u002F>\n\n\u003C!-- GOOD -->\n\u003CPropertyGroup>\n  \u003CToolPath>$(MSBuildThisFileDirectory)tools\\mytool\\mytool.exe\u003C\u002FToolPath>\n\u003C\u002FPropertyGroup>\n\u003CImport Project=\"$(RepoRoot)eng\\common.props\" \u002F>\n```\n\n**Preferred path properties:**\n\n| Property | Meaning |\n|----------|---------|\n| `$(MSBuildThisFileDirectory)` | Directory of the current .props\u002F.targets file |\n| `$(MSBuildProjectDirectory)` | Directory of the .csproj |\n| `$([MSBuild]::GetDirectoryNameOfFileAbove(...))` | Walk up to find a marker file |\n| `$([MSBuild]::NormalizePath(...))` | Combine and normalize path segments |\n\n---\n\n## AP-04: Restating SDK Defaults\n\n**Smell**: Properties set to values that the .NET SDK already provides by default.\n\n**Why it's bad**: Adds noise, hides intentional overrides, and makes it harder to identify what's actually customized. When defaults change in newer SDKs, the redundant properties may silently pin old behavior.\n\n```xml\n\u003C!-- BAD: All of these are already the default -->\n\u003CPropertyGroup>\n  \u003COutputType>Library\u003C\u002FOutputType>\n  \u003CEnableDefaultItems>true\u003C\u002FEnableDefaultItems>\n  \u003CEnableDefaultCompileItems>true\u003C\u002FEnableDefaultCompileItems>\n  \u003CRootNamespace>MyLib\u003C\u002FRootNamespace>       \u003C!-- matches project name -->\n  \u003CAssemblyName>MyLib\u003C\u002FAssemblyName>         \u003C!-- matches project name -->\n  \u003CAppendTargetFrameworkToOutputPath>true\u003C\u002FAppendTargetFrameworkToOutputPath>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Only non-default values -->\n\u003CPropertyGroup>\n  \u003CTargetFramework>net8.0\u003C\u002FTargetFramework>\n\u003C\u002FPropertyGroup>\n```\n\n---\n\n## AP-05: Manual File Listing in SDK-Style Projects\n\n**Smell**: `\u003CCompile Include=\"File1.cs\" \u002F>`, `\u003CCompile Include=\"File2.cs\" \u002F>` in SDK-style projects.\n\n**Why it's bad**: SDK-style projects automatically glob `**\u002F*.cs` (and other file types). Explicit listing is redundant, creates merge conflicts, and new files may be accidentally missed if not added to the list.\n\n```xml\n\u003C!-- BAD -->\n\u003CItemGroup>\n  \u003CCompile Include=\"Program.cs\" \u002F>\n  \u003CCompile Include=\"Services\\MyService.cs\" \u002F>\n  \u003CCompile Include=\"Models\\User.cs\" \u002F>\n\u003C\u002FItemGroup>\n\n\u003C!-- GOOD: Remove entirely — SDK includes all .cs files by default.\n     Only use Remove\u002FExclude when you need to opt out: -->\n\u003CItemGroup>\n  \u003CCompile Remove=\"LegacyCode\\**\" \u002F>\n\u003C\u002FItemGroup>\n```\n\n**Exception**: Non-SDK-style (legacy) projects require explicit file includes. If migrating, see `msbuild-modernization` skill.\n\n**Exception (F# \u002F `.fsproj`)**: F# compilation is order-dependent — the compiler processes `\u003CCompile Include>` items sequentially and a file can only reference types\u002Fmodules declared in files listed above it. `.fsproj` files must therefore list every source file explicitly, in dependency order (utility\u002Fleaf modules at the top, the entry point such as `Program.fs` at the bottom). If a `.fsi` signature file is used, it must appear **immediately before** its companion `.fs` implementation file.\n\n---\n\n## AP-06: Using `\u003CReference>` with HintPath for NuGet Packages\n\n**Smell**: `\u003CReference Include=\"...\" HintPath=\"..\\packages\\SomePackage\\lib\\...\" \u002F>`\n\n**Why it's bad**: This is the legacy `packages.config` pattern. It doesn't support transitive dependencies, version conflict resolution, or automatic restore. The `packages\u002F` folder must be committed or restored separately.\n\n```xml\n\u003C!-- BAD -->\n\u003CItemGroup>\n  \u003CReference Include=\"Newtonsoft.Json\">\n    \u003CHintPath>..\\packages\\Newtonsoft.Json.13.0.3\\lib\\netstandard2.0\\Newtonsoft.Json.dll\u003C\u002FHintPath>\n  \u003C\u002FReference>\n\u003C\u002FItemGroup>\n\n\u003C!-- GOOD -->\n\u003CItemGroup>\n  \u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n\u003C\u002FItemGroup>\n```\n\n**Note**: `\u003CReference>` without HintPath is still valid for .NET Framework GAC assemblies like `WindowsBase`, `PresentationCore`, etc.\n\n---\n\n## AP-07: Missing `PrivateAssets=\"all\"` on Analyzer\u002FTool Packages\n\n**Smell**: `\u003CPackageReference Include=\"StyleCop.Analyzers\" Version=\"...\" \u002F>` without `PrivateAssets=\"all\"`.\n\n**Why it's bad**: Without `PrivateAssets=\"all\"`, analyzer and build-tool packages flow as transitive dependencies to consumers of your library. Consumers get unwanted analyzers or build-time tools they didn't ask for.\n\nSee [`references\u002Fprivate-assets.md`](references\u002Fprivate-assets.md) for BAD\u002FGOOD examples and the full list of packages that need this.\n\n---\n\n## AP-08: Copy-Pasted Properties Across Multiple .csproj Files\n\n**Smell**: The same `\u003CPropertyGroup>` block appears in 3+ project files.\n\n**Why it's bad**: Maintenance burden — a change must be made in every file. Inconsistencies creep in over time.\n\n```xml\n\u003C!-- BAD: Repeated in every .csproj -->\n\u003C!-- ProjectA.csproj, ProjectB.csproj, ProjectC.csproj all have: -->\n\u003CPropertyGroup>\n  \u003CNullable>enable\u003C\u002FNullable>\n  \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n  \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Define once in Directory.Build.props at the repo\u002Fsrc root -->\n\u003C!-- Directory.Build.props -->\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CNullable>enable\u003C\u002FNullable>\n    \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n    \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\nSee `directory-build-organization` skill for full guidance on structuring `Directory.Build.props` \u002F `Directory.Build.targets`.\n\n---\n\n## AP-09: Scattered Package Versions Without Central Package Management\n\n**Smell**: `\u003CPackageReference Include=\"X\" Version=\"1.2.3\" \u002F>` with different versions of the same package across projects.\n\n**Why it's bad**: Version drift — different projects use different versions of the same package, leading to runtime mismatches, unexpected behavior, or diamond dependency conflicts.\n\n```xml\n\u003C!-- BAD: Version specified in each project, can drift -->\n\u003C!-- ProjectA.csproj -->\n\u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.1\" \u002F>\n\u003C!-- ProjectB.csproj -->\n\u003CPackageReference Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n```\n\n**Fix:** Use Central Package Management. See [https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fconsume-packages\u002Fcentral-package-management](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fconsume-packages\u002Fcentral-package-management) for details.\n\n---\n\n## AP-10: Monolithic Targets (Too Much in One Target)\n\n**Smell**: A single `\u003CTarget>` with 50+ lines doing multiple unrelated things.\n\n**Why it's bad**: Can't skip individual steps via incremental build, hard to debug, hard to extend, and the target name becomes meaningless.\n\n```xml\n\u003C!-- BAD -->\n\u003CTarget Name=\"PrepareRelease\" BeforeTargets=\"Build\">\n  \u003CWriteLinesToFile File=\"version.txt\" Lines=\"$(Version)\" Overwrite=\"true\" \u002F>\n  \u003CCopy SourceFiles=\"LICENSE\" DestinationFolder=\"$(OutputPath)\" \u002F>\n  \u003CExec Command=\"signtool sign \u002Ff cert.pfx $(OutputPath)*.dll\" \u002F>\n  \u003CMakeDir Directories=\"$(OutputPath)docs\" \u002F>\n  \u003CCopy SourceFiles=\"@(DocFiles)\" DestinationFolder=\"$(OutputPath)docs\" \u002F>\n  \u003C!-- ... 30 more lines ... -->\n\u003C\u002FTarget>\n\n\u003C!-- GOOD: Single-responsibility targets -->\n\u003CTarget Name=\"WriteVersionFile\" BeforeTargets=\"CoreCompile\"\n        Inputs=\"$(MSBuildProjectFile)\" Outputs=\"$(IntermediateOutputPath)version.txt\">\n  \u003CWriteLinesToFile File=\"$(IntermediateOutputPath)version.txt\" Lines=\"$(Version)\" Overwrite=\"true\" \u002F>\n\u003C\u002FTarget>\n\n\u003CTarget Name=\"CopyLicense\" AfterTargets=\"Build\">\n  \u003CCopy SourceFiles=\"LICENSE\" DestinationFolder=\"$(OutputPath)\" SkipUnchangedFiles=\"true\" \u002F>\n\u003C\u002FTarget>\n\n\u003CTarget Name=\"SignAssemblies\" AfterTargets=\"Build\" DependsOnTargets=\"CopyLicense\"\n        Condition=\"'$(SignAssemblies)' == 'true'\">\n  \u003CExec Command=\"signtool sign \u002Ff cert.pfx %(AssemblyFiles.Identity)\" \u002F>\n\u003C\u002FTarget>\n```\n\n---\n\n## AP-11: Custom Targets Missing `Inputs` and `Outputs`\n\n**Smell**: `\u003CTarget Name=\"MyTarget\" BeforeTargets=\"Build\">` with no `Inputs` \u002F `Outputs` attributes.\n\n**Why it's bad**: The target runs on every build, even when nothing changed. This defeats incremental build and slows down no-op builds.\n\nSee [`references\u002Fincremental-build-inputs-outputs.md`](references\u002Fincremental-build-inputs-outputs.md) for BAD\u002FGOOD examples and the full pattern including FileWrites registration.\n\nSee `incremental-build` skill for deep guidance on Inputs\u002FOutputs, FileWrites, and up-to-date checks.\n\n---\n\n## AP-12: Setting Defaults in .targets Instead of .props\n\n**Smell**: `\u003CPropertyGroup>` with default values inside a `.targets` file.\n\n**Why it's bad**: `.targets` files are imported late (after project files). By the time they set defaults, other `.targets` files may have already used the empty\u002Fundefined value. `.props` files are imported early and are the correct place for defaults.\n\n```xml\n\u003C!-- BAD: custom.targets -->\n\u003CPropertyGroup>\n  \u003CMyToolVersion>2.0\u003C\u002FMyToolVersion>\n\u003C\u002FPropertyGroup>\n\u003CTarget Name=\"RunMyTool\">\n  \u003CExec Command=\"mytool --version $(MyToolVersion)\" \u002F>\n\u003C\u002FTarget>\n\n\u003C!-- GOOD: Split into .props (defaults) + .targets (logic) -->\n\u003C!-- custom.props (imported early) -->\n\u003CPropertyGroup>\n  \u003CMyToolVersion Condition=\"'$(MyToolVersion)' == ''\">2.0\u003C\u002FMyToolVersion>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- custom.targets (imported late) -->\n\u003CTarget Name=\"RunMyTool\">\n  \u003CExec Command=\"mytool --version $(MyToolVersion)\" \u002F>\n\u003C\u002FTarget>\n```\n\n**Rule**: `.props` = defaults and settings (evaluated early). `.targets` = build logic and targets (evaluated late).\n\n---\n\n## AP-13: Import Without `Exists()` Guard\n\n**Smell**: `\u003CImport Project=\"some-file.props\" \u002F>` without a `Condition=\"Exists('...')\"` check.\n\n**Why it's bad**: If the file doesn't exist (not yet created, wrong path, deleted), the build fails with a confusing error. Optional imports should always be guarded.\n\n```xml\n\u003C!-- BAD -->\n\u003CImport Project=\"$(RepoRoot)eng\\custom.props\" \u002F>\n\n\u003C!-- GOOD: Guard optional imports -->\n\u003CImport Project=\"$(RepoRoot)eng\\custom.props\" Condition=\"Exists('$(RepoRoot)eng\\custom.props')\" \u002F>\n\n\u003C!-- ALSO GOOD: Sdk attribute imports don't need guards (they're required by design) -->\n\u003CProject Sdk=\"Microsoft.NET.Sdk\">\n```\n\n**Exception — required imports**: Imports that are *required* for the build to work correctly should fail fast — don't guard those. Guard imports that are optional or environment-specific (e.g., local developer overrides, CI-specific settings).\n\n**Exception — NuGet package forwarders**: `.props`\u002F`.targets` files inside a NuGet package's per-TFM `build\u002F` or `buildTransitive\u002F` folder routinely import a sibling file under `buildTransitive\u002F\u003Ctfm>\u002F…` without an `Exists()` guard. These are a **package contract**: the target file is guaranteed to be present in the restored package, even if it doesn't appear in the source tree at that relative path. The package layout is typically produced by:\n\n- A custom `.nuspec` with per-TFM `\u003Cfile>` entries — e.g. `\u003Cfile src=\"buildTransitive\\common\\MyAdapter.props\" target=\"buildTransitive\\net8.0\\MyAdapter.props\" \u002F>` — that copy files from a single source folder (such as `buildTransitive\u002Fcommon\u002F`) into per-TFM subfolders at pack time, or\n- `\u003CNone Update=\"...\">` \u002F `\u003CContent Include=\"...\">` items in the `.csproj` with a per-TFM `\u003CPackagePath>` (e.g. `\u003CPackagePath>buildTransitive\u002Fnet8.0\u002F\u003C\u002FPackagePath>`), declared once per target TFM, or\n- SDK conventions (e.g. `IncludeBuildOutput`, `BuildOutputTargetFolder`) that place built outputs under `build\u002F\u003Ctfm>\u002F`.\n\nBefore flagging an unguarded `\u003CImport>` inside a `build\u002F` or `buildTransitive\u002F` folder, **resolve it against the packed layout** — read every `*.nuspec` in the project directory **and its immediate parent directory** (shared nuspecs are common in mono-repos; do not walk further up), and any `\u003CPackagePath>` metadata on `\u003CNone>`\u002F`\u003CContent>` items in the `.csproj`. Only flag if the target path is missing from **both** the source tree *and* the projected package layout. The `dotnet-msbuild\u002Fextension-points` skill — *Source tree vs packed layout* — documents the full cross-check procedure.\n\n**Forwarding `buildTransitive\u002F` → `build\u002F`:** forward through the sibling `build\u002F*.props` \u002F `build\u002F*.targets` file (not directly to `buildMultiTargeting\u002F`); when `build\u002F` is per-TFM (`build\u002F\u003Ctfm>\u002F`), include the TFM segment derived from the file's own folder (not `$(TargetFramework)`), or transitive consumers hit `MSB4019`. See the `extension-points` skill — *Forwarding chain* — for the rule and derivation expression.\n\n---\n\n## AP-14: Backslashes in Paths — Where It Matters\n\n**Smell**: Backslash path separators in `.props`\u002F`.targets` files meant to run cross-platform.\n\n**Where this is a real bug (? Error)** — paths that MSBuild does **not** route through its path normalizer:\n\n- Raw shell strings inside `\u003CExec Command=\"...\\tools\\foo.exe ...\" \u002F>` — passed verbatim to `bash`\u002F`sh` on Unix, which treats `\\` as an escape.\n- Backslash-delimited paths inside CDATA blocks, embedded in source files written by `\u003CWriteLinesToFile>`, or constructed for non-MSBuild consumers (custom scripts, response files, environment variables).\n- Paths handed to custom tasks that call OS file APIs directly without going through MSBuild path utilities.\n\n**Where this is only a style preference (? Style)** — paths that go through MSBuild's evaluator (`\u003CImport Project=\"...\">`, file-path properties consumed by built-in tasks like `\u003CCopy>`\u002F`\u003CMakeDir>`\u002F`\u003CDelete>`, item `Include=`\u002F`Exclude=` globs):\n\nMSBuild's evaluator normalizes `\\` → `\u002F` on Unix-like systems before resolving the path. See `FileUtilities.MaybeAdjustFilePath` and `ConvertToUnixSlashes` in [`microsoft\u002Fmsbuild` `src\u002FFramework\u002FFileUtilities.cs`](https:\u002F\u002Fgithub.com\u002Fdotnet\u002Fmsbuild\u002Fblob\u002Fmain\u002Fsrc\u002FFramework\u002FFileUtilities.cs). So `\u003CImport Project=\"$(MSBuildThisFileDirectory)..\\..\\build\\common.props\" \u002F>` resolves correctly on Linux\u002FmacOS today. Forward slashes are still **preferred for consistency**, but the import will not break and existing backslash-style imports should not be flagged as ? **Error**.\n\n```xml\n\u003C!-- ? Error: \\ in raw shell string breaks on Linux\u002FmacOS -->\n\u003CExec Command=\"$(MSBuildThisFileDirectory)tools\\release\\sign.exe $(OutputPath)\" \u002F>\n\n\u003C!-- ? Style: \\ in Import is normalized on Unix, but \u002F is nicer -->\n\u003CImport Project=\"$(MSBuildThisFileDirectory)..\\..\\build\\common.props\" \u002F>\n\n\u003C!-- ✅ Recommended in new code -->\n\u003CImport Project=\"$(MSBuildThisFileDirectory)..\u002F..\u002Fbuild\u002Fcommon.props\" \u002F>\n```\n\n**Verification rule**: Before flagging a backslash path as ? **Error**, ask *\"does this string flow through MSBuild's evaluator, or is it handed verbatim to a non-MSBuild consumer?\"* Only the second case is a correctness defect.\n\n**Note**: `$(MSBuildThisFileDirectory)` already ends with a platform-appropriate separator, so `$(MSBuildThisFileDirectory)tools\u002Fmytool` works on both platforms.\n\n---\n\n## AP-15: Unconditional Property Override in Multiple Scopes\n\n**Smell**: A property set unconditionally in both `Directory.Build.props` and a `.csproj` — last write wins silently.\n\n**Why it's bad**: Hard to trace which value is actually used. Makes the build fragile and confusing for anyone reading the project files.\n\n```xml\n\u003C!-- BAD: Directory.Build.props sets it, csproj silently overrides -->\n\u003C!-- Directory.Build.props -->\n\u003CPropertyGroup>\n  \u003COutputPath>bin\\custom\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\u003C!-- MyProject.csproj -->\n\u003CPropertyGroup>\n  \u003COutputPath>bin\\other\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\n\u003C!-- GOOD: Use a condition so overrides are intentional -->\n\u003C!-- Directory.Build.props -->\n\u003CPropertyGroup>\n  \u003COutputPath Condition=\"'$(OutputPath)' == ''\">bin\\custom\\\u003C\u002FOutputPath>\n\u003C\u002FPropertyGroup>\n\u003C!-- MyProject.csproj can now intentionally override or leave the default -->\n```\n\n---\n\nFor additional anti-patterns (AP-16 through AP-23) and a quick-reference checklist, see [additional-antipatterns.md](references\u002Fadditional-antipatterns.md).\n",{"name":5,"license":15,"description":7},"main","f8f2bfd77819bb789d4736ce7db4a567a37fcf7e",".agents\u002Fskills\u002Fmsbuild-antipatterns",315,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 14:01:43",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add microsoft\u002Ftestfx --skill msbuild-antipatterns",{"tool":55,"command":56},"bunx","bunx skills add microsoft\u002Ftestfx --skill msbuild-antipatterns",{"tool":58,"command":59},"pnpm","pnpm dlx skills add microsoft\u002Ftestfx --skill msbuild-antipatterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmsbuild-antipatterns\u002FSKILL.md",true,[63,69,73],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fadditional-antipatterns.md","REFERENCE","参考文档",19271,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmsbuild-antipatterns\u002Freferences\u002Fadditional-antipatterns.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fincremental-build-inputs-outputs.md",1561,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmsbuild-antipatterns\u002Freferences\u002Fincremental-build-inputs-outputs.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fprivate-assets.md",1041,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmsbuild-antipatterns\u002Freferences\u002Fprivate-assets.md",[78,105,134,155,175,199],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":35},"01M70GYY0AV0JGMTHE2CN6TNYK","dotnet-breaking-changes","Use before changing .NET\u002FC# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped\u002FUnshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: \"without breaking existing callers\"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016\u002FRS0017 or ApiCompat errors; \"is this PR breaking?\". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework\u002FSDK\u002FNuGet upgrades (use dotnet-upgrade).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdotnet-breaking-changes\u002FSKILL.md",[],[85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104],"dotnet","dotnet breaking changes","changes","green","project","default","local","errors","interface","generated","upgrade","invoke","you","code","refactoring","merge","rename","library","live","assembly",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":116,"publishedAt":35},"01M699HHE9DTZWAMPB1ZR7ZKSW","testfx-test-value-evidence","Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-test-value-evidence\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[117,118,119,120,121,22,122,123,124,125,126,127,128,129,130,131,87,132,26,133],"test","testfx test value evidence","test value evidence","evidence","value","parallel","toolchain","commits","implementing","prs","only","use","when","apply","with","behavior","conventions",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":35},"01M699HEYWH1B9XGNBFY8J2FZS","testfx-parallel-safety-preflight","Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-parallel-safety-preflight\u002FSKILL.md",[],[141,26,142,122,143,144,125,145,98,146,99,147,148,149,150,151,152,153,128,154],"testfx parallel safety preflight","preflight","shared","asynchronous","exercise","concurrency","paths","isolation","helpers","diff","parallelization","lifecycle","tests","workers",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":35},"01M699HC61ZV9GJ2C8JV03951G","testfx-localization-validation","Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX\u002FXLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-localization-validation\u002FSKILL.md",[],[162,163,164,165,166,167,168,169,170,126,94,128,171,172,87,173,174],"testfx localization validation","validation","localization","validate","translation","ids","for","tokens","entries","units","duplicate","targets","build",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":35},"01M699H9J2NWQXE4BDT6R0FH7S","testfx-acceptance-validation","Validate TestFx shipping paths and capable CI execution using packed consumers, package\u002Fcache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package\u002FMSBuild\u002Flauncher\u002Fprotocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-acceptance-validation\u002FSKILL.md",[181],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[183,184,163,117,20,120,185,186,187,127,188,128,189,190,191,192,193,194,195,196,197,198,147,168],"testfx acceptance validation","acceptance","launcher","ci","execution","package","cache","artifacts","provenance","documentation","unrelated","shipping","results","protocol","unit","ci results",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":35},"01M699H70BB999BT4F627T1PHE","session-delivery-hygiene","Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package\u002Foutput mismatches, or handing off implementation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsession-delivery-hygiene\u002FSKILL.md",[],[206,207,208,209,210,125,91,211,212,103,213,188,128,191,214,215,87,216,217,218],"session delivery hygiene","delivery","session","hygiene","scope","cleanup","work","pr","output","state","integration","guidance","gate"]