[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZH10J86J0ADE18GJQ29AT":3,"skill-same:01M6DZH10J86J0ADE18GJQ29AT":106},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6DZH10J86J0ADE18GJQ29AT","directory-build-organization",null,"USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props\u002Ftargets\u002Frsp hierarchy with an import, placement, or layering defect. A one-project repo without an existing Directory.Build file is outside scope; do not load this skill. Covers centralizing shared policy and targets, Directory.Packages.props across projects, parent hierarchy\u002Fimport structure, props-versus-targets placement, and folder\u002Fproject exceptions. An existing hierarchy defect remains in scope when only one project is affected. For property value or condition semantics use property-patterns. Exclude legacy-to-SDK migration and non-MSBuild systems.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",515,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"directory build organization","build","directory","organization","patterns","when","defect","hierarchy","affected","condition","import","scope","project","shared","across","structure","do","Legacy","only","use","repo","projects","file","package","packages","policy","2026-11-10 10:12:30",false,"---\nname: directory-build-organization\ndescription: \"USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props\u002Ftargets\u002Frsp hierarchy with an import, placement, or layering defect. A one-project repo without an existing Directory.Build file is outside scope; do not load this skill. Covers centralizing shared policy and targets, Directory.Packages.props across projects, parent hierarchy\u002Fimport structure, props-versus-targets placement, and folder\u002Fproject exceptions. An existing hierarchy defect remains in scope when only one project is affected. For property value or condition semantics use property-patterns. Exclude legacy-to-SDK migration and non-MSBuild systems.\"\nlicense: MIT\n---\n\n# Organizing Build Infrastructure with Directory.Build Files\n\n## Intent control\n\n- For \"should we\", \"how should we organize\", \"recommend\", \"advise\", or review\n  requests, inspect the actual project files and return a proposed layout only.\n  Do not create or edit files unless the user explicitly asks to apply, move,\n  centralize, or clean up the configuration.\n- Before summarizing, verify which project retains each project-specific\n  property, item, or target. Name the actual file; do not infer it from sibling\n  names.\n- Recommend a verification command only after discovering a real `.sln`,\n  `.slnx`, `.proj`, or project file at that path. If no repo-root entry point\n  exists, give commands for the discovered projects or state that the entry\n  point was not found.\n- Every advice response must explain that `Microsoft.Common.props` searches\n  upward from each project and automatically imports the nearest\n  `Directory.Build.props` early; project values can then override shared\n  defaults. Explain the equivalent late `Microsoft.Common.targets` import when\n  recommending `Directory.Build.targets`.\n\n## Directory.Build.props vs Directory.Build.targets\n\nUnderstanding which file to use is critical. They differ in **when** they are imported during evaluation:\n\n**Evaluation order:**\n\n```\nMicrosoft.Common.props imports Directory.Build.props early\n→ project body and package\u002Fproject imports evaluate\n→ Microsoft.Common.targets imports Directory.Build.targets late\n```\n\n| Use `.props` for | Use `.targets` for |\n|---|---|\n| Setting property defaults | Custom build targets |\n| Common item definitions | Late-bound property overrides |\n| Properties projects can override | Post-build steps |\n| Assembly\u002Fpackage metadata | Conditional logic on final values |\n| Analyzer PackageReferences | Targets that depend on SDK-defined properties |\n\n**Rule of thumb:** Properties and items go in `.props`. Custom targets and late-bound logic go in `.targets`.\n\nBecause `.props` is imported before the project file, the project can override any value set there. Because `.targets` is imported after everything, it gets the final say—but projects cannot override `.targets` values.\n\n### ⚠️ Critical: TargetFramework Availability in .props vs .targets\n\n**Property conditions on `$(TargetFramework)` in `.props` files silently fail for single-targeting projects** — the property is empty during `.props` evaluation. Move TFM-conditional properties to `.targets` instead. ItemGroup and Target conditions are not affected.\n\nSee [targetframework-props-pitfall.md](references\u002Ftargetframework-props-pitfall.md) for the full explanation.\n\n## Directory.Build.props\n\nGood candidates: language settings, assembly\u002Fpackage metadata, build warnings, code analysis, common analyzers.\n\n```xml\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CNullable>enable\u003C\u002FNullable>\n    \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n    \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n    \u003CEnforceCodeStyleInBuild>true\u003C\u002FEnforceCodeStyleInBuild>\n    \u003CCompany>Contoso\u003C\u002FCompany>\n    \u003CAuthors>Contoso Engineering\u003C\u002FAuthors>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\n**Do NOT put here:** project-specific TFMs, project-specific PackageReferences, targets\u002Fbuild logic, or properties depending on SDK-defined values (not available during `.props` evaluation).\n\n## Directory.Build.targets\n\nGood candidates: custom build targets, late-bound property overrides (values depending on SDK properties), post-build validation.\n\n```xml\n\u003CProject>\n  \u003CTarget Name=\"ValidateProjectSettings\" BeforeTargets=\"Build\">\n    \u003CError Text=\"All libraries must target netstandard2.0 or higher\"\n           Condition=\"'$(OutputType)' == 'Library' AND '$(TargetFramework)' == 'net472'\" \u002F>\n  \u003C\u002FTarget>\n\n  \u003CPropertyGroup>\n    \u003C!-- DocumentationFile depends on OutputPath, which is set by the SDK -->\n    \u003CDocumentationFile Condition=\"'$(IsPackable)' == 'true'\">$(OutputPath)$(AssemblyName).xml\u003C\u002FDocumentationFile>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\n## Directory.Packages.props (Central Package Management)\n\nCentral Package Management (CPM) provides a single source of truth for all NuGet package versions. 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**Enable CPM in `Directory.Packages.props` at the repo root:**\n\n```xml\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CManagePackageVersionsCentrally>true\u003C\u002FManagePackageVersionsCentrally>\n  \u003C\u002FPropertyGroup>\n\n  \u003CItemGroup>\n    \u003CPackageVersion Include=\"Microsoft.Extensions.Logging\" Version=\"8.0.0\" \u002F>\n    \u003CPackageVersion Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n    \u003CPackageVersion Include=\"xunit\" Version=\"2.9.0\" \u002F>\n    \u003CPackageVersion Include=\"xunit.runner.visualstudio\" Version=\"2.8.2\" \u002F>\n  \u003C\u002FItemGroup>\n\n  \u003CItemGroup>\n    \u003C!-- GlobalPackageReference applies to ALL projects — great for analyzers -->\n    \u003CGlobalPackageReference Include=\"StyleCop.Analyzers\" Version=\"1.2.0-beta.556\" \u002F>\n    \u003CGlobalPackageReference Include=\"Microsoft.CodeAnalysis.NetAnalyzers\" Version=\"8.0.0\" \u002F>\n  \u003C\u002FItemGroup>\n\u003C\u002FProject>\n```\n\n## Directory.Build.rsp\n\nContains default MSBuild CLI arguments applied to all builds under the directory tree.\n\n**Example `Directory.Build.rsp`:**\n\n```\n\u002Fmaxcpucount\n\u002FnodeReuse:false\n\u002FconsoleLoggerParameters:Summary;ForceNoAlign\n\u002FwarnAsMessage:MSB3277\n```\n\n- Works with both `msbuild` and `dotnet` CLI in modern .NET versions\n- Great for enforcing consistent CI and local build flags\n- Each argument goes on its own line\n\n## Multi-level Directory.Build Files\n\nMSBuild only auto-imports the **first** `Directory.Build.props` (or `.targets`) it finds walking up from the project directory. To chain multiple levels, explicitly import the parent at the **top** of the inner file. See [multi-level-examples](references\u002Fmulti-level-examples.md) for full file examples.\n\n```xml\n\u003CProject>\n  \u003CImport Project=\"$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)..\u002F'))\"\n         Condition=\"Exists('$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)..\u002F'))')\" \u002F>\n\n  \u003C!-- Inner-level overrides go here -->\n\u003C\u002FProject>\n```\n\n**Example layout:**\n\n```\nrepo\u002F\n  Directory.Build.props          ← repo-wide (lang version, company info, analyzers)\n  Directory.Build.targets        ← repo-wide targets\n  Directory.Packages.props       ← central package versions\n  src\u002F\n    Directory.Build.props        ← src-specific (imports repo-level, sets IsPackable=true)\n  test\u002F\n    Directory.Build.props        ← test-specific (imports repo-level, sets IsPackable=false, adds test packages)\n```\n\n## Artifact Output Layout (.NET 8+)\n\nSet `\u003CArtifactsPath>$(MSBuildThisFileDirectory)artifacts\u003C\u002FArtifactsPath>` in `Directory.Build.props` to automatically produce project-name-separated `bin\u002F`, `obj\u002F`, and `publish\u002F` directories under a single `artifacts\u002F` folder, avoiding bin\u002Fobj clashes by default. See [common-patterns](references\u002Fcommon-patterns.md) for the directory layout and additional patterns (conditional settings by project type, post-pack validation).\n\n## Workflow: Organizing Build Infrastructure\n\n1. **Audit all `.csproj` files** — Catalog every `\u003CPropertyGroup>`, `\u003CItemGroup>`, and custom `\u003CTarget>` across the solution. Note which settings repeat and which are project-specific.\n2. **Create root `Directory.Build.props`** — Move shared property defaults (LangVersion, Nullable, TreatWarningsAsErrors, metadata) here. These are imported before the project file so projects can override them.\n3. **Create root `Directory.Build.targets`** — Move custom build targets, post-build validation, and any properties that depend on SDK-defined values (e.g., `OutputPath`, `TargetFramework` for single-targeting projects) here. These are imported after the SDK so all properties are available.\n4. **Create `Directory.Packages.props`** — Enable Central Package Management (`ManagePackageVersionsCentrally`), list all `PackageVersion` entries, and remove `Version=` from `PackageReference` items in `.csproj` files.\n5. **Set up multi-level hierarchy** — Create inner `Directory.Build.props` files for `src\u002F` and `test\u002F` folders with distinct settings. Use `GetPathOfFileAbove` to chain to the parent.\n6. **Simplify `.csproj` files** — Remove all centralized properties, version attributes, and duplicated targets. Each project should only contain what is unique to it.\n7. **Validate** — Run restore\u002Fbuild against the discovered `.sln`, `.slnx`,\n   `.proj`, or project path, for example\n   `dotnet restore \u003Centrypoint> && dotnet build \u003Centrypoint>`. If no root\n   entrypoint exists, validate each discovered project explicitly instead of\n   claiming a repo-root build. Use\n   `dotnet msbuild \u003Cproject> -pp:output.xml` to inspect the final merged view.\n\n## Troubleshooting\n\n| Problem | Cause | Fix |\n|---|---|---|\n| `Directory.Build.props` isn't picked up | File name casing wrong (exact match required on Linux\u002FmacOS) | Verify exact casing: `Directory.Build.props` (capital D, B) |\n| Properties from `.props` are ignored by projects | Project sets the same property after the import | Move the property to `Directory.Build.targets` to set it after the project |\n| Multi-level import doesn't work | Missing `GetPathOfFileAbove` import in inner file | Add the `\u003CImport>` element at the top of the inner file (see Multi-level section) |\n| Properties using SDK values are empty in `.props` | SDK properties aren't defined yet during `.props` evaluation | Move to `.targets` which is imported after the SDK |\n| `Directory.Packages.props` not found | File not at repo root or not named exactly | Must be named `Directory.Packages.props` and at or above the project directory |\n| Property condition on `$(TargetFramework)` doesn't match in `.props` | `TargetFramework` isn't set yet for single-targeting projects during `.props` evaluation | Move property to `.targets`, or use ItemGroup\u002FTarget conditions instead (which evaluate late) |\n\n**Diagnosis:** Use the preprocessed project output to see all imports and final property values:\n\n```bash\ndotnet msbuild -pp:output.xml MyProject.csproj\n```\n\nThis expands all imports inline so you can see exactly where each property is set and what the final evaluated value is.\n","# Organizing Build Infrastructure with Directory.Build Files\n\n## Intent control\n\n- For \"should we\", \"how should we organize\", \"recommend\", \"advise\", or review\n  requests, inspect the actual project files and return a proposed layout only.\n  Do not create or edit files unless the user explicitly asks to apply, move,\n  centralize, or clean up the configuration.\n- Before summarizing, verify which project retains each project-specific\n  property, item, or target. Name the actual file; do not infer it from sibling\n  names.\n- Recommend a verification command only after discovering a real `.sln`,\n  `.slnx`, `.proj`, or project file at that path. If no repo-root entry point\n  exists, give commands for the discovered projects or state that the entry\n  point was not found.\n- Every advice response must explain that `Microsoft.Common.props` searches\n  upward from each project and automatically imports the nearest\n  `Directory.Build.props` early; project values can then override shared\n  defaults. Explain the equivalent late `Microsoft.Common.targets` import when\n  recommending `Directory.Build.targets`.\n\n## Directory.Build.props vs Directory.Build.targets\n\nUnderstanding which file to use is critical. They differ in **when** they are imported during evaluation:\n\n**Evaluation order:**\n\n```\nMicrosoft.Common.props imports Directory.Build.props early\n→ project body and package\u002Fproject imports evaluate\n→ Microsoft.Common.targets imports Directory.Build.targets late\n```\n\n| Use `.props` for | Use `.targets` for |\n|---|---|\n| Setting property defaults | Custom build targets |\n| Common item definitions | Late-bound property overrides |\n| Properties projects can override | Post-build steps |\n| Assembly\u002Fpackage metadata | Conditional logic on final values |\n| Analyzer PackageReferences | Targets that depend on SDK-defined properties |\n\n**Rule of thumb:** Properties and items go in `.props`. Custom targets and late-bound logic go in `.targets`.\n\nBecause `.props` is imported before the project file, the project can override any value set there. Because `.targets` is imported after everything, it gets the final say—but projects cannot override `.targets` values.\n\n### ⚠️ Critical: TargetFramework Availability in .props vs .targets\n\n**Property conditions on `$(TargetFramework)` in `.props` files silently fail for single-targeting projects** — the property is empty during `.props` evaluation. Move TFM-conditional properties to `.targets` instead. ItemGroup and Target conditions are not affected.\n\nSee [targetframework-props-pitfall.md](references\u002Ftargetframework-props-pitfall.md) for the full explanation.\n\n## Directory.Build.props\n\nGood candidates: language settings, assembly\u002Fpackage metadata, build warnings, code analysis, common analyzers.\n\n```xml\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CNullable>enable\u003C\u002FNullable>\n    \u003CImplicitUsings>enable\u003C\u002FImplicitUsings>\n    \u003CTreatWarningsAsErrors>true\u003C\u002FTreatWarningsAsErrors>\n    \u003CEnforceCodeStyleInBuild>true\u003C\u002FEnforceCodeStyleInBuild>\n    \u003CCompany>Contoso\u003C\u002FCompany>\n    \u003CAuthors>Contoso Engineering\u003C\u002FAuthors>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\n**Do NOT put here:** project-specific TFMs, project-specific PackageReferences, targets\u002Fbuild logic, or properties depending on SDK-defined values (not available during `.props` evaluation).\n\n## Directory.Build.targets\n\nGood candidates: custom build targets, late-bound property overrides (values depending on SDK properties), post-build validation.\n\n```xml\n\u003CProject>\n  \u003CTarget Name=\"ValidateProjectSettings\" BeforeTargets=\"Build\">\n    \u003CError Text=\"All libraries must target netstandard2.0 or higher\"\n           Condition=\"'$(OutputType)' == 'Library' AND '$(TargetFramework)' == 'net472'\" \u002F>\n  \u003C\u002FTarget>\n\n  \u003CPropertyGroup>\n    \u003C!-- DocumentationFile depends on OutputPath, which is set by the SDK -->\n    \u003CDocumentationFile Condition=\"'$(IsPackable)' == 'true'\">$(OutputPath)$(AssemblyName).xml\u003C\u002FDocumentationFile>\n  \u003C\u002FPropertyGroup>\n\u003C\u002FProject>\n```\n\n## Directory.Packages.props (Central Package Management)\n\nCentral Package Management (CPM) provides a single source of truth for all NuGet package versions. 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**Enable CPM in `Directory.Packages.props` at the repo root:**\n\n```xml\n\u003CProject>\n  \u003CPropertyGroup>\n    \u003CManagePackageVersionsCentrally>true\u003C\u002FManagePackageVersionsCentrally>\n  \u003C\u002FPropertyGroup>\n\n  \u003CItemGroup>\n    \u003CPackageVersion Include=\"Microsoft.Extensions.Logging\" Version=\"8.0.0\" \u002F>\n    \u003CPackageVersion Include=\"Newtonsoft.Json\" Version=\"13.0.3\" \u002F>\n    \u003CPackageVersion Include=\"xunit\" Version=\"2.9.0\" \u002F>\n    \u003CPackageVersion Include=\"xunit.runner.visualstudio\" Version=\"2.8.2\" \u002F>\n  \u003C\u002FItemGroup>\n\n  \u003CItemGroup>\n    \u003C!-- GlobalPackageReference applies to ALL projects — great for analyzers -->\n    \u003CGlobalPackageReference Include=\"StyleCop.Analyzers\" Version=\"1.2.0-beta.556\" \u002F>\n    \u003CGlobalPackageReference Include=\"Microsoft.CodeAnalysis.NetAnalyzers\" Version=\"8.0.0\" \u002F>\n  \u003C\u002FItemGroup>\n\u003C\u002FProject>\n```\n\n## Directory.Build.rsp\n\nContains default MSBuild CLI arguments applied to all builds under the directory tree.\n\n**Example `Directory.Build.rsp`:**\n\n```\n\u002Fmaxcpucount\n\u002FnodeReuse:false\n\u002FconsoleLoggerParameters:Summary;ForceNoAlign\n\u002FwarnAsMessage:MSB3277\n```\n\n- Works with both `msbuild` and `dotnet` CLI in modern .NET versions\n- Great for enforcing consistent CI and local build flags\n- Each argument goes on its own line\n\n## Multi-level Directory.Build Files\n\nMSBuild only auto-imports the **first** `Directory.Build.props` (or `.targets`) it finds walking up from the project directory. To chain multiple levels, explicitly import the parent at the **top** of the inner file. See [multi-level-examples](references\u002Fmulti-level-examples.md) for full file examples.\n\n```xml\n\u003CProject>\n  \u003CImport Project=\"$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)..\u002F'))\"\n         Condition=\"Exists('$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)..\u002F'))')\" \u002F>\n\n  \u003C!-- Inner-level overrides go here -->\n\u003C\u002FProject>\n```\n\n**Example layout:**\n\n```\nrepo\u002F\n  Directory.Build.props          ← repo-wide (lang version, company info, analyzers)\n  Directory.Build.targets        ← repo-wide targets\n  Directory.Packages.props       ← central package versions\n  src\u002F\n    Directory.Build.props        ← src-specific (imports repo-level, sets IsPackable=true)\n  test\u002F\n    Directory.Build.props        ← test-specific (imports repo-level, sets IsPackable=false, adds test packages)\n```\n\n## Artifact Output Layout (.NET 8+)\n\nSet `\u003CArtifactsPath>$(MSBuildThisFileDirectory)artifacts\u003C\u002FArtifactsPath>` in `Directory.Build.props` to automatically produce project-name-separated `bin\u002F`, `obj\u002F`, and `publish\u002F` directories under a single `artifacts\u002F` folder, avoiding bin\u002Fobj clashes by default. See [common-patterns](references\u002Fcommon-patterns.md) for the directory layout and additional patterns (conditional settings by project type, post-pack validation).\n\n## Workflow: Organizing Build Infrastructure\n\n1. **Audit all `.csproj` files** — Catalog every `\u003CPropertyGroup>`, `\u003CItemGroup>`, and custom `\u003CTarget>` across the solution. Note which settings repeat and which are project-specific.\n2. **Create root `Directory.Build.props`** — Move shared property defaults (LangVersion, Nullable, TreatWarningsAsErrors, metadata) here. These are imported before the project file so projects can override them.\n3. **Create root `Directory.Build.targets`** — Move custom build targets, post-build validation, and any properties that depend on SDK-defined values (e.g., `OutputPath`, `TargetFramework` for single-targeting projects) here. These are imported after the SDK so all properties are available.\n4. **Create `Directory.Packages.props`** — Enable Central Package Management (`ManagePackageVersionsCentrally`), list all `PackageVersion` entries, and remove `Version=` from `PackageReference` items in `.csproj` files.\n5. **Set up multi-level hierarchy** — Create inner `Directory.Build.props` files for `src\u002F` and `test\u002F` folders with distinct settings. Use `GetPathOfFileAbove` to chain to the parent.\n6. **Simplify `.csproj` files** — Remove all centralized properties, version attributes, and duplicated targets. Each project should only contain what is unique to it.\n7. **Validate** — Run restore\u002Fbuild against the discovered `.sln`, `.slnx`,\n   `.proj`, or project path, for example\n   `dotnet restore \u003Centrypoint> && dotnet build \u003Centrypoint>`. If no root\n   entrypoint exists, validate each discovered project explicitly instead of\n   claiming a repo-root build. Use\n   `dotnet msbuild \u003Cproject> -pp:output.xml` to inspect the final merged view.\n\n## Troubleshooting\n\n| Problem | Cause | Fix |\n|---|---|---|\n| `Directory.Build.props` isn't picked up | File name casing wrong (exact match required on Linux\u002FmacOS) | Verify exact casing: `Directory.Build.props` (capital D, B) |\n| Properties from `.props` are ignored by projects | Project sets the same property after the import | Move the property to `Directory.Build.targets` to set it after the project |\n| Multi-level import doesn't work | Missing `GetPathOfFileAbove` import in inner file | Add the `\u003CImport>` element at the top of the inner file (see Multi-level section) |\n| Properties using SDK values are empty in `.props` | SDK properties aren't defined yet during `.props` evaluation | Move to `.targets` which is imported after the SDK |\n| `Directory.Packages.props` not found | File not at repo root or not named exactly | Must be named `Directory.Packages.props` and at or above the project directory |\n| Property condition on `$(TargetFramework)` doesn't match in `.props` | `TargetFramework` isn't set yet for single-targeting projects during `.props` evaluation | Move property to `.targets`, or use ItemGroup\u002FTarget conditions instead (which evaluate late) |\n\n**Diagnosis:** Use the preprocessed project output to see all imports and final property values:\n\n```bash\ndotnet msbuild -pp:output.xml MyProject.csproj\n```\n\nThis expands all imports inline so you can see exactly where each property is set and what the final evaluated value is.\n",{"name":5,"license":15,"description":7},"main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-14 19:05:44",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add managedcode\u002Fdotnet-skills --skill directory-build-organization",{"tool":66,"command":67},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill directory-build-organization",{"tool":69,"command":70},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill directory-build-organization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization\u002FSKILL.md",true,[74,80,86,90,94,98,102],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"init-cursor-dir.sh","SCRIPT","脚本",1104,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Farchive\u002Flegacy_pillars\u002F10_engineering_devops\u002F01_software_engineering\u002Fdeveloping\u002Fscripts\u002Fide_setup\u002Finit-cursor-dir.sh",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"init-cursor-dir.sh.meta.json","REFERENCE","参考文档",620,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Farchive\u002Flegacy_pillars\u002F10_engineering_devops\u002F01_software_engineering\u002Fdeveloping\u002Fscripts\u002Fide_setup\u002Finit-cursor-dir.sh.meta.json",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fcommon-patterns.md",1411,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization\u002Freferences\u002Fcommon-patterns.md",{"path":91,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fmulti-level-examples.md",4001,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization\u002Freferences\u002Fmulti-level-examples.md",{"path":95,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Ftargetframework-props-pitfall.md",3427,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-msbuild\u002Fskills\u002Fdirectory-build-organization\u002Freferences\u002Ftargetframework-props-pitfall.md",{"path":99,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":100,"sourceHtmlUrl":101},"symlink-agent-transcripts-to-workspace.sh",2185,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Farchive\u002Flegacy_pillars\u002F10_engineering_devops\u002F01_software_engineering\u002Fdeveloping\u002Fscripts\u002Fide_setup\u002Fsymlink-agent-transcripts-to-workspace.sh",{"path":103,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":104,"sourceHtmlUrl":105},"symlink-agent-transcripts-to-workspace.sh.meta.json",666,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Farchive\u002Flegacy_pillars\u002F10_engineering_devops\u002F01_software_engineering\u002Fdeveloping\u002Fscripts\u002Fide_setup\u002Fsymlink-agent-transcripts-to-workspace.sh.meta.json",[107,144,167,197,207,232],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":123,"publishedAt":45},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[113,118],{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":119,"categoryName":120,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":156,"publishedAt":45},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":154,"categoryName":155,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000036","内容创作者",[146,157,158,126,159,127,131,160,161,162,136,163,137,139,35,164,165,31,141,166],"writing","performance","tasks","data","parsing","parser","context","writer","options","high-performance",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":45},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[174,175,176,177,178,179,180,181,182,183,184,185,38,186,187,188,189,190,191,192,193,194,195,196,24],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":45},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[199,38,139,204,205,193,206],"semantic","razor","inspection",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":45},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[214,215,216,217,157,44,218,219,220,221,222,38,37,223,224,225,35,226,227,228,229,193,230,231,24],"system","json","text","system text json net11","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":240,"publishedAt":45},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[238,239],{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},{"categoryNo":119,"categoryName":120,"taxonomyType":121,"taxonomyTypeDesc":122},[132,241,242,243,127,244,181,214,38,224,225,35,245,246,247,248,229,193,249],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]