dotnet-local-tools

Manage local .NET CLI tools via a dotnet-tools.json manifest.

Updated Dec 4, 2022
One-click install
npx skills add https://github.com/devingoble/CloudOStat --skill dotnet-local-tools-devingoble
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-local-tools
Source: https://github.com/devingoble/CloudOStat/tree/main/.github/skills/local-tools
Command: npx skills add https://github.com/devingoble/CloudOStat --skill dotnet-local-tools-devingoble

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill ensures consistent versions of .NET CLI tools across development environments and CI/CD pipelines, preventing version conflicts and setup headaches.

Core Features & Use Cases

  • Centralized Tool Management: Define and manage project-specific .NET tools in a dotnet-tools.json manifest.
  • Reproducible Builds: Guarantees that the same tool versions are used locally and in automated builds.
  • Use Case: When setting up a new project, use this skill to install and manage tools like DocFX for documentation, EF Core for migrations, and CSharpier for code formatting, ensuring all team members and the CI server use the exact same versions.

Quick Start

Run dotnet tool restore to install all defined local .NET tools for the current project.

Frequently Asked Questions about dotnet-local-tools

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage .NET CLI tool versions consistently across local dev and CI/CD pipelines?

Managing .NET CLI tool versions consistently across local dev and CI/CD requires a `dotnet-tools.json` manifest. This manifest centralizes tool definitions, allowing environments to restore exact versions using `dotnet tool restore` for reproducible builds.

What is the best way to prevent .NET CLI tool version conflicts in a development team?

The best way to prevent .NET CLI tool version conflicts is committing a `dotnet-tools.json` manifest to source control. This ensures all team members and automated pipelines install and use the identical tool versions via `dotnet tool restore`.

How do I install project-specific .NET tools like DocFX and EF Core using a manifest?

To install project-specific .NET tools like DocFX and EF Core using a manifest, define them in the `dotnet-tools.json` file. Then execute `dotnet tool restore` to automatically install the declared tools for the current project.

Can I use a dotnet-tools.json manifest to update and remove local .NET tools?

Yes, you can use a `dotnet-tools.json` manifest to update and remove local .NET tools. The manifest supports installation, update, and removal operations, ensuring tools like CSharpier remain synchronized across your development environments.

Why does my CI/CD pipeline fail due to mismatched .NET tool versions?

Your CI/CD pipeline fails due to mismatched .NET tool versions because local and automated environments lack a shared tool manifest. Using a `dotnet-tools.json` file solves this by explicitly defining and restoring the exact required versions.

Do I need a dotnet-tools.json file for every .NET project to ensure reproducible tooling?

You need a `dotnet-tools.json` file for each .NET project requiring isolated, reproducible tooling. This local manifest guarantees specific tool versions like EF Core are restored accurately for that project's dev and CI needs.