Factor Responses into its own assembly by christothes · Pull Request #889 · openai/openai-dotnet

christothes · 2026-01-08T23:02:55Z

No description provided.

jsquire

I've got a PR out to move the repository configuration and package management to a centralized version, which would remove a lot of the redundancies that you needed in the project files and such.

joseharriaga · 2026-03-02T20:17:19Z

@@ -84,11 +85,30 @@ if ($LASTEXITCODE -ne 0) {
    exit $LASTEXITCODE


nit: Edit the error message to something like "GenAPI failed for OpenAI with exit code $LASTEXITCODE" to differentiate it from failing for OpenAI.Responses.

joseharriaga · 2026-03-03T19:56:31Z

+if ($LASTEXITCODE -ne 0) {
+    Write-Error "GenAPI failed for OpenAI.Responses with exit code $LASTEXITCODE"
+    exit $LASTEXITCODE
+}


I see that the API listings for OpenAI still contain all the stuff from OpenAI.Responses, and I wonder if it would be preferable to not modify this script. I'm thinking it might be better to not produce individual API listings for Responses for a few reasons:

It feels redundant.

It sets the precedent of having to modify this script every time we split a library out of the base library.

It adds at least some latency to this script (which is already a little slow).

In general, if our infra can continue to work without modifications, I think that would be ideal. I'm thinking of this script, but I'm also thinking of other validation scripts (Test-ApiCompatibility.ps1, Test-AotCompatibility.ps1, etc.), as well as our pipelines.

I think as we have new assemblies it's important to understand if there are any differences between what shows up in the main assembly and what shows up in the sub-assembly. I think it will always be true that the main assembly will contain everything, but it's not always clear what subset would be available in the subassembly.

joseharriaga · 2026-03-03T20:07:14Z

@@ -0,0 +1,57 @@
+<Project Sdk="Microsoft.NET.Sdk">


Are there benefits to splitting the OpenAI.Tests project too, or is it reasonable to keep it unchanged? If keeping one single project works fine, I would strongly prefer that for simplicity. Otherwise, I worry that this will be difficult to scale and impact our productivity.

This is to validate that tests still pass when loading just the subassembly and not the main assembly.

I agree that this is valuable. Can we think of an alternative that allows us to get this benefit in some way that does not require maintaining separate projects and separate test infrastructure for each new library that we onboard? I'm a little worried because I'm envisioning a nearby future where we have over a dozen libraries, and the cost of standing up test infra for each, along with modifying pipelines, scripts, etc. and then maintaining all of it will hinder us.

I'm thinking about it in the following way: Because the OpenAI library is by design just a passthrough for the OpenAI.Responses library, testing OpenAI.Responses through OpenAI is a valid way of testing its functionality. Then, the question changes from "does this work at all?" to "can we validate that this is all actually coming from OpenAI.Responses?". The funny part is that because all the functionality related to the Responses API must be in OpenAI.Responses and we must not put any of it in OpenAI by design, the answer is technically an automatic "yes" by definition. So while I agree that this validation would be good to have to ensure that we don't accidentally break our design somehow, it also feels a little superfluous and makes the trade-off in complexity a bit of a hard pill to swallow. 😕

What could be considered a "good enough" way to validate that the functionality is actually coming from OpenAI.Responses? I'm even considering something like the following: "What if we had a job in our nightly pipeline that checks out main, deletes everything in the test project except Responses, swaps the dependency from OpenAI to OpenAI.Responses, and runs the recorded tests?". While a solution like this is still something that we will need to maintain, maintaining a single pipeline job is simpler compared to multiple test projects and test infras. It would be entirely isolated in a single YAML file, and because we're delegating the validation to a pipeline, we can basically forget about it during our day-to-day work. Am I crazy? 🤔

Let me see what I can do to improve it - worst case we can rely on just the main assembly

Just pushed an update that refactors things a bit to minimize duplication. Let me know if this looks ok to you.

Removed extra newline before 'Using the async API' section.

…tor' into chriss/module-refactor

joseharriaga · 2026-03-06T21:49:37Z

+    [ModelReaderWriterBuildable(typeof(WebSearchToolApproximateLocation))]
+    [ModelReaderWriterBuildable(typeof(WebSearchToolFilters))]
+    [ModelReaderWriterBuildable(typeof(WebSearchToolLocation))]
+    public partial class ResponsesModelContext


This should be auto-generated.

Are you suggesting we do this via a Visitor or something like that? We can certainly do that longer term.

joseharriaga · 2026-03-06T21:52:04Z

+
+namespace OpenAI.Responses.Internal
+{
+    internal partial class OpenAIError


Question: The name of this file says "Generated", but it's not in the Generated folder. Is this file generated or is it a custom copy of a generated file?

custom copy.

ShivangiReja · 2026-03-09T20:21:35Z

+    /// as the specified <see cref="OpenAIClientOptions"/>.
+    /// </summary>
+    /// <returns> A new <see cref="ResponsesClientOptions"/> with the same property values. </returns>
+    internal ResponsesClientOptions ToResponsesClientOptionss()


Suggested change

internal ResponsesClientOptions ToResponsesClientOptionss()

internal ResponsesClientOptions ToResponsesClientOptions()

ShivangiReja · 2026-03-09T20:32:47Z

Should these methods move to the Responses assembly as extension methods?

jsquire reviewed Jan 10, 2026

View reviewed changes

Comment thread src/Shared/debug.targets Outdated

Comment thread tests/Responses/OpenAI.Responses.Tests.csproj Outdated

christothes marked this pull request as ready for review January 22, 2026 20:44

christothes requested review from ShivangiReja and joseharriaga as code owners January 22, 2026 20:44

KrzysztofCwalina requested changes Jan 27, 2026

View reviewed changes

Comment thread src/Custom/Responses/OpenAIContext.Definition.cs Outdated

Comment thread src/Custom/TypeForwarding.cs Outdated

Comment thread src/Shared/OpenAI.Shared.csproj Outdated

christothes added 19 commits February 3, 2026 12:20

wip

3d38eb7

wip

2b8b270

wip

fa87799

building with OpenAI.Responses

3a96772

codegen

ab3f45b

wip after export

755ca91

wip after export

97ad0f1

Finalize configuration and testing for OpenAI.Responses client package

7eb41bb

tests wip

5f07e7b

finished tests

ccf1259

workflows

f5748c7

cleanup

610bf64

cleanup

013183a

tests fixup

8920833

fixes

4ff5961

cleanup

12e319b

fix

e0024b1

remove Shared project

fef9a40

remove Shared project

c6532a5

christothes force-pushed the chriss/module-refactor branch from eb86e8b to c6532a5 Compare February 4, 2026 16:08

christothes added 5 commits February 4, 2026 10:15

fix warnings

cf626be

fix export

1a632af

fix export

9ee279a

.

c801dc2

export?

130f284

christothes added 7 commits February 4, 2026 11:29

I think this finally fixed export

8f6c3a3

regen

fbbb2eb

merge and some fixes

79ac793

snippets

65f7f65

remove refactor plan

5fa9b77

cleanup

a4588d3

cleanup

3cefd1d

KrzysztofCwalina reviewed Feb 23, 2026

View reviewed changes

Comment thread api/OpenAI.Responses.netstandard2.0.cs Outdated

christothes added 3 commits February 23, 2026 12:13

fix for CI

5997b21

gitignore

4b3e620

ResponsesModelContext

2582475

KrzysztofCwalina approved these changes Feb 23, 2026

View reviewed changes

christothes added 2 commits February 23, 2026 13:50

fix codegen errors

6a2d728

merge

160346f

joseharriaga requested changes Mar 3, 2026

View reviewed changes

christothes added 6 commits March 3, 2026 14:58

fb

1cfb7ff

Fix formatting in README.md

27b69ae

Removed extra newline before 'Using the async API' section.

fix

6bb2ec4

Merge remote-tracking branch 'refs/remotes/origin/chriss/module-refac…

6aeade9

…tor' into chriss/module-refactor

refactor tests to minimize dupes

66c1dd0

Merge branch 'main' into chriss/module-refactor

e38677a

joseharriaga reviewed Mar 6, 2026

View reviewed changes

ShivangiReja reviewed Mar 9, 2026

View reviewed changes

		@@ -84,11 +85,30 @@ if ($LASTEXITCODE -ne 0) {
		exit $LASTEXITCODE

	internal ResponsesClientOptions ToResponsesClientOptionss()
	internal ResponsesClientOptions ToResponsesClientOptions()

Conversation

christothes commented Jan 8, 2026

Uh oh!

jsquire left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants