### Summary The attachment examples in `dotnet/README.md` reference C# types that are not in the SDK, so they do not compile. This file is packed as the package README (`<PackageReadmeFile>README.md</PackageReadmeFile>`), so it is also what renders on the [`GitHub.Copilot.SDK`](https://www.nuget.org/packages/GitHub.Copilot.SDK) NuGet page. A developer who installs the package as the README instructs and copies an attachment example gets `CS0246`/`CS0103`. Three examples are affected, in two sections: - `## Image Support` - the file attachment example and the blob attachment example - `### File Attachments` They use `UserMessageDataAttachmentsItem`, `UserMessageDataAttachmentsItemFile`, `UserMessageDataAttachmentsItemBlob` and `UserMessageDataAttachmentsItemType`. None of those exist in the current SDK. ### Reproduction ```bash dotnet new classlib -o AttachmentRepro cd AttachmentRepro dotnet add package GitHub.Copilot.SDK --version 1.0.8 ``` Put the README's `## Image Support` file attachment example into `Class1.cs`, wrapped so only the attachment types can fail: ```csharp using GitHub.Copilot; public static class Repro { public static async Task Run(CopilotSession session) { await session.SendAsync(new MessageOptions { Prompt = "What's in this image?", Attachments = new List<UserMessageDataAttachmentsItem> { new UserMessageDataAttachmentsItemFile { Path = "/path/to/image.jpg", DisplayName = "image.jpg", } } }); } } ``` ```bash dotnet build ``` ### Expected The documented examples compile against the package the README tells you to install. ### Actual ``` error CS0246: The type or namespace name 'UserMessageDataAttachmentsItem' could not be found (are you missing a using directive or an assembly reference?) error CS0246: The type or namespace name 'UserMessageDataAttachmentsItemFile' could not be found (are you missing a using directive or an assembly reference?) ``` The blob example fails the same way on `UserMessageDataAttachmentsItemBlob`, and the `### File Attachments` example additionally fails with `error CS0103: The name 'UserMessageDataAttachmentsItemType' does not exist in the current context`. Taken together the three examples produce 6 x `CS0246` + 1 x `CS0103`. This reproduces on `1.0.8` (current latest stable), on `1.0.9-preview.2`, and on a build of current `main`. It is .NET-only: the Node.js, Python, Go and Java READMEs do not use these names, and the Go README already documents the current form. ### Correct form The working public API is `MessageOptions.Attachments`, typed `IList<Attachment>?`, with the concrete subclasses `AttachmentFile` (required `Path`, required `DisplayName`) and `AttachmentBlob` (required `MimeType`, optional `Data`, optional `DisplayName`): ```csharp Attachments = new List<Attachment> { new AttachmentFile { Path = "/path/to/image.jpg", DisplayName = "image.jpg", } } ``` `docs/features/image-input.md` already documents exactly this shape, and its C# blocks are compiled by documentation validation, so the feature itself works - only the README is stale. ### Why this was missed Attachments moved to a polymorphic model and the types were later renamed to `Attachment*`. The feature guide under `docs/` was updated; the packaged README was not. Documentation validation cannot catch it, because extraction is scoped to the `docs/` directory - `scripts/docs-validation/extract.ts` resolves `DOCS_DIR` to `docs` and globs `**/*.md` relative to it, so per-binding READMEs are never enumerated. The C# fence language is recognised, so the only reason these blocks are not compiled is that the file is out of scope. Separately, the path filter on `.github/workflows/docs-validation.yml` lists source locations - `docs/**`, `nodejs/src/**`, `python/copilot/**`, `go/**/*.go`, `dotnet/src/**`, `java/src/**`, `java/pom.xml` and the validation scripts - none of which match markdown under `dotnet/`. ### Related `dotnet/src/Session.cs` has a similar but distinct problem in the XML `<example>` on `SendAsync`: it builds `new()` inside a `List<Attachment>` initializer, which target-types to the base `Attachment` and so has no `Path` (`CS0117`), and it omits `AttachmentFile`'s required `DisplayName`. It uses current type names, so it is a separate defect from the stale names above.