Kiota.MSBuild 1.1.0

Kiota.MSBuild

MSBuild targets that generate and refresh a Kiota API client as part of your build. Drop in a PackageReference, point it at an OpenAPI spec, and the client is generated on first build and regenerated on demand — no per-project MSBuild copy/paste.

Usage

<PackageReference Include="Kiota.MSBuild" Version="1.0.0" PrivateAssets="all" />

<PropertyGroup>
  <SpecFile>https://example.com/openapi.yaml</SpecFile>
  <GeneratedClientClassName>MyApiClient</GeneratedClientClassName>
  <GeneratedClientNamespace>$(RootNamespace).Generated</GeneratedClientNamespace>
</PropertyGroup>


<ItemGroup>
  <PackageReference Include="Microsoft.Kiota.Abstractions" Version="1.22.0" />
  <PackageReference Include="Microsoft.Kiota.Http.HttpClientLibrary" Version="1.22.0" />
  <PackageReference Include="Microsoft.Kiota.Serialization.Json" Version="1.22.0" />
</ItemGroup>

On build, if no client exists yet (Generated/kiota-lock.json is absent), the client is generated and added to the compilation. Commit the Generated/ folder.

Generate vs. update vs. regenerate

These are three distinct actions:

• Generate — the one-time initial creation, when no client exists yet. Happens automatically on the first build.
• Update — implicit. On build, if the spec recorded in kiota-lock.json has changed, the client is refreshed automatically (kiota update). For a local spec file this is incremental (it only runs when the file is newer than the lock, so unchanged builds stay cheap) and on by default. For a remote spec (a URL) refreshing means a network fetch on every build, so it is off by default there — opt in with <UpdateClientOnBuild>true</UpdateClientOnBuild> (and rely on RegenerateClient or CI to refresh otherwise). Force either way with UpdateClientOnBuild.
• Regenerate — explicit. A full wipe and fresh generation, on demand: dotnet build -t:RegenerateClient.

Targets

Properties

The kiota tool

The targets invoke kiota via a local tool manifest, resolved the same way dotnet tool restore resolves one: the nearest .config/dotnet-tools.json at or above the project. So a repository that keeps a single manifest at its root keeps working — the package will not add a second one inside the project that shadows it.

Only when there is no manifest anywhere above the project does this package copy in a default one (pinning a known-good kiota version) and run dotnet tool restore for you; it says so in the build log when it does.

If a manifest is found but does not list kiota, the build warns with KIOTA004 — add it yourself (dotnet tool install microsoft.openapi.kiota) so the version stays under your control.

Releasing

Pushing a v* tag publishes the package. The NuGet Publish workflow derives the package version from the tag (v1.2.3 → 1.2.3), runs the tests, packs, pushes to NuGet.org, and cuts a GitHub release:

git tag v1.2.3
git push origin v1.2.3

Publishing uses NuGet.org Trusted Publishing (OIDC) instead of a long-lived API key — the workflow exchanges a GitHub OIDC token for a one-hour key at push time. One-time setup:

1. On nuget.org, go to your username → Trusted Publishing and add a policy with Repository Owner ricardoboss, Repository Kiota.MSBuild, Workflow File publish.yml, and Environment nuget.org (to match environment: nuget.org in the workflow).
2. Add a NUGET_USER secret containing your nuget.org username (profile name, not email).

The workflow needs id-token: write permission (already set) for the OIDC exchange.