---
id: SAIFTRBL0009
moved_from:
  - guides/troubleshooting/kiota-generated-client-status-does-not-exist.md
title: Kiota-generated client fails with CS0103 for Status
description: Fix Kiota-generated C# clients that fail because the Status property does not exist.
tags:
  - troubleshooting
  - build
  - typespec
---

# Kiota-generated client fails with CS0103 for Status

**One-sentence summary:** update the API provider's `@saif/platform-typespec` to 3.8.0 or later to resolve this `Status`/CS0103 error, republish its OpenAPI document, and regenerate the consuming client; 3.8.0 through 3.9.2 still carry a related `Type` defect (see note below), so prefer 3.9.3 or later if you want both fixed.

---

## 🚨 Symptom

Generating a C# client with Kiota 1.32.0 or later succeeds, but the generated client fails to compile:

```text
error CS0103: The name 'Status' does not exist in the current context
```

This can appear after `saif doctor fix` updates the globally installed Kiota CLI, or during a build that regenerates a `<KiotaReference>` from an affected API's published OpenAPI document. Updating packages in the consuming .NET project does not correct an already-published OpenAPI document.

---

## 📌 Applies to

| Aspect | Value |
| ------ | ----- |
| **Component** | APIs publishing OpenAPI from TypeSpec and C# clients generated with Kiota |
| **Forge versions** | API provider's TypeSpec project uses `@saif/platform-typespec` earlier than 3.8.0; 3.8.0 resolves this `Status` defect but 3.8.0 through 3.9.2 still carry the related `Type` defect described below, so prefer 3.9.3 or later |
| **Related versions** | Kiota 1.32.0 or later; check the [version compatibility matrix](../reference/version-compatibility.md) |

---

## 🧠 Cause

Kiota 1.32.0 began initializing numeric and Boolean properties from their OpenAPI default values. OpenAPI documents generated with earlier versions of `@saif/platform-typespec` declare `status` on both the shared `ProblemDetails` schema and each concrete error schema. Kiota removes the duplicate child property but still generates its constructor initializer, leaving an assignment to a `Status` property that does not exist.

The incompatible model comes from the API provider's published OpenAPI document, not from the consuming API's Forge or .NET package versions.

!!! note "A related defect affects `type`"
    3.8.0 fixed `status` by moving it off the base and anchoring the base body with `type` instead, which left `type` declared in both places. With Kiota 1.35.0, documents generated with 3.8.0 through 3.9.2 produce C# platform error models without a `Type` property. This missing property does not itself cause a build error. Those package releases do not include the separate `type` fix; upgrading only to 3.8.0 resolves `Status`, not `Type`. See [Duplicate properties are dropped from generated clients](../build/apis/calling-apis.md#duplicate-properties-are-dropped-from-generated-clients) for the required schema correction and server compatibility impact.

---

## ✅ Fix

1. Find the API provider whose OpenAPI document is referenced by the failing `<KiotaReference>`.

2. In that API provider's TypeSpec project, update `@saif/platform-typespec` to a version that includes both fixes:

    ```powershell
    npm install @saif/platform-typespec@^3.9.3
    ```

    If you are only chasing the `Status`/CS0103 symptom in this article and don't need the `Type` fix, `@saif/platform-typespec@^3.8.0` is also sufficient, but that range can resolve to 3.8.0-3.9.2, which still carries the `Type` defect described above.

3. Rebuild the TypeSpec project and publish the regenerated OpenAPI document through the API provider's normal delivery pipeline:

    ```powershell
    npm run build
    ```

4. After the referenced OpenAPI URL serves the updated document, clean and rebuild the consuming .NET project so Kiota regenerates the client:

    ```powershell
    dotnet clean
    dotnet build
    ```

---

## 🔬 Verify

Confirm both regressions are resolved in the published OpenAPI document:

- `status` is declared only on each concrete error schema (e.g. `BadRequest`), not on the shared `ProblemDetails` schema.
- `type` is declared only on the shared `ProblemDetails` schema, and each concrete error schema references it through `allOf` inheritance rather than redeclaring it locally.

The regenerated client then builds without `CS0103`, and each concrete error model exposes both its own `Status` property and a `Type` property:

```text
Build succeeded.
    0 Error(s)
```

---

## 📚 Related

- [Downstream API Calls](../build/apis/calling-apis.md)
- [saif-corp/forge#904](https://github.com/saif-corp/forge/pull/904) — fix shipped in `@saif/platform-typespec` 3.8.0
- [saif-corp/forge#1181](https://github.com/saif-corp/forge/issues/1181) — tracks the remaining Kiota generator/runtime version-alignment gap
- [microsoft/kiota#7404](https://github.com/microsoft/kiota/pull/7404) — introduced initialization from OpenAPI default values
- [Microsoft Teams support thread](https://teams.microsoft.com/l/message/19%3Acb611810fb0b42b080cfff5590bdd51c%40thread.tacv2/1789419855704?tenantId=a86cb8ed-369b-4df5-ace5-43811f6e08cf&groupId=514d2dac-2d62-48ce-bf99-0fa0ce39469c&parentMessageId=1789419855704)