msbuild-antipatterns

Scan the project file against the anti-pattern catalog: check for unquoted conditions, hardcoded absolute paths, manual Compile listings in SDK-style projects, Reference with HintPath instead of PackageReference, and copy-pasted PropertyGroups that belong in Directory.Build.props. Each finding maps to a concrete BAD-to-GOOD fix.

The custom target is missing Inputs and Outputs attributes, so MSBuild cannot determine it is up-to-date. Add Inputs including $(MSBuildProjectFile) and Outputs pointing to files under $(IntermediateOutputPath), and register generated files in FileWrites so dotnet clean removes them.

This is typically a forked project instance: an <MSBuild> task call or SetTargetFramework metadata passes a path-neutral global property, creating a second instance of the same project that shares the same bin/obj output path. Both instances write the same files concurrently, causing file-lock failures.

No for Import paths—MSBuild's evaluator normalizes backslashes to forward slashes on Unix, so it is only a style issue. Backslashes are a real error only in raw shell strings passed to <Exec> or other non-MSBuild consumers, where bash treats them as escape characters.

Do not use it for non-MSBuild build systems like npm, Maven, or CMake, and do not use it for migrating legacy projects to SDK-style format—that scenario belongs to a dedicated modernization skill. It also does not apply to F# file ordering, which legitimately requires explicit Compile listings.