es

Inicio rápido

De cero a un proyecto restaurado, en tres comandos.

Este recorrido te lleva de un checkout limpio de un proyecto .NET a un workspace totalmente restaurado que PCPM puede gestionar, en tres comandos.

0. Suposiciones

  • Tienes un proyecto o solución .NET en el directorio actual.
  • PCPM está en tu PATH (ver Instalación).
  • Estás en Windows, macOS o Linux con el SDK de .NET 10.

1. Inicializa o migra el workspace

Si ya tienes una solución:

pcpm convert

PCPM recorre cada .csproj, sube cada Version= por proyecto a un <PackageVersion />, adopta tu Directory.Packages.props existente si lo tienes y escribe pcpm.json + pcpm.lock. pcpm install se ejecuta al final del convert. --dry-run previsualiza el diff; --revert deshace un convert anterior.

Si partes de cero:

pcpm init

PCPM busca un .sln o .csproj en el directorio actual (o un nivel arriba) y crea tres ficheros si no existen:

  • pcpm.json — el manifiesto propio de PCPM. Registra la ruta del store, las preferencias de comprobación de actualizaciones y los flags de funcionalidad. Rara vez lo editarás a mano.
  • Directory.Packages.props — el fichero CPM de Microsoft. PCPM escribe aquí las entradas <PackageVersion /> cuando ejecutas pcpm add.
  • pcpm-workspace.yaml (solo para monorepos) — la configuración de descubrimiento de proyectos. No se crea para workspaces de un solo proyecto.

Si ya tienes Directory.Packages.props (es decir, ya usabas CPM), PCPM lo adopta en lugar de sobrescribirlo.

Tip: pcpm init --help lista todas las opciones. Las más útiles son --no-cpm (no tocar Directory.Packages.props) y --force (sobrescribir ficheros existentes).

2. Añade tus dependencias

pcpm add Microsoft.Extensions.Hosting
pcpm add Serilog
pcpm add Serilog.Sinks.Console

pcpm add hace cuatro cosas:

  1. Consulta el feed por la última versión estable.
  2. Escribe la versión en Directory.Packages.props como un <PackageVersion />.
  3. Añade un <PackageReference Include="…" /> a cada .csproj que referencie al proyecto desde el que ejecutas.
  4. Ejecuta pcpm install (a menos que pases --no-install).

El install implícito es una funcionalidad, no un bug — para cuando vuelves a tener el prompt, la nueva dependencia está en disco y lista para usar.

3. Restaurar

Si te saltaste el install implícito en el paso 2, o si alguien acaba de meter un cambio en pcpm.lock:

pcpm install

Este es el comando bestia. Hace lo siguiente:

  1. Resuelve el grafo transitivo completo.
  2. Descarga cada paquete faltante en el store global (o lo enlaza con hardlink desde el store si ya está).
  3. Hace hardlink de cada paquete desde el store a ~/.nuget/packages.
  4. Ejecuta dotnet restore contra el layout materializado.

La primera ejecución descarga todo. Las siguientes son prácticamente instantáneas — la mayoría de paquetes vienen del store y dotnet restore solo re-comprueba el lockfile.

4. Comprobación e inspección

pcpm list                  # imprime pcpm.lock formateado
pcpm why Serilog           # quién trajo a Serilog
pcpm doctor                # CPM, lockfile, CVEs, huérfanos
pcpm audit                 # vulnerabilidades + licencias + SBOM
  • pcpm list imprime el lockfile como tabla. Deberías ver tus dependencias directas, más su grafo transitivo, con las versiones resueltas.
  • pcpm why Serilog muestra la cadena de dependientes que trajo Serilog al lockfile. Útil cuando un bump transitivo te sorprende.
  • pcpm doctor ejecuta la batería completa de comprobaciones de CPM (ver Introducción). Conéctalo a tu CI.
  • pcpm audit produce un informe de vulnerabilidades, un informe de licencias y un SBOM en una sola pasada.

5. CI

Sustituye dotnet restore en tu build server por:

pcpm ci

pcpm ci valida que pcpm.lock esté sincronizado con el workspace, que el sha256 de cada entrada esté presente en el store, y luego ejecuta dotnet restore. Sale con código distinto de cero a la primera inconsistencia — un run limpio de CI que resuelva un transitivo nuevo se convierte en fallo de build, no en regresión silenciosa.

¿Qué sigue?

Editar esta página en GitHub