c-sharp service emitter #2458
c-sharp service emitter #2458
Conversation
markcowl
requested review from
bterlson,
daviwil,
allenjzhang and
timotheeguerin
as code owners
|
Changes in this PR will be published to the following url to try(check status of TypeSpec Pull Request Try It pipeline for publish status): Website: https://tspwebsitepr.z5.web.core.windows.net/prs/2458/ |
|
Companion PR in azure repo here: https://github.com/Azure/typespec-azure/pull/3617 |
|
|
||
| class CSharpCodeEmitter extends CodeTypeEmitter { | ||
| #names: string[] = []; | ||
| #licenseHeader = `// Copyright (c) Microsoft Corporation. All rights reserved. |
There was a problem hiding this comment.
(Curious) I understand the direct boilerplate types and the generator code itself falling under the MIT license and the Microsoft copyright.
But does this license header end up on “my” generated files from my TypeSpec? (Edit: Yes it does per my reading of the code.) I would expect that the types generated would NOT include this license header.
There was a problem hiding this comment.
This is a good point, we should make this configurable so that generated code could fall under any selected license (or have no license header).
| return this.emitter.result.declaration( | ||
| enumName, | ||
| code`${this.#licenseHeader} | ||
| // <auto-generated /> |
There was a problem hiding this comment.
(Food for thought)
-
I often see a "generated by XXX tool" and sometimes a timestamp for generated code. Does this
<auto-generated />tag get replaced with additional detail or is this a raw comment string? -
I am still learning C#, but does the GeneratedCodeAttribute apply to the use case here? (In Java world, I used
@GeneratedIIRC.)
There was a problem hiding this comment.
The primary reason for this is that they are keys for many c-sharp linting rules
|
Thanks for sharing @Petermarcu! I will try it out when released. If it does not make the October cut, I guess I could build from source and try it that way. 👍🏻 |
|
Is there an example of the output? Does it support both minimal APIs and Controllers? |
|
+1 to seeing a full example. (Maybe an "end to end" test can reference a .cs file that provides the example?) For now, I scanned through the diff. |
|
@connorjs Yes, the best end-to-end at this point is an Azure-specific end-to-end. Adding a REST end-to-end equivalent in samples and in the unit tests is on the task list for check-in (hopefully next week). |
|
@davidfowl The plan is to allow modelsOnly or modelsAndOperations or full asp.net with controllers, based on configuration. For the first iteration, it is the whole thing. |
| enumName, | ||
| code`${this.#licenseHeader} | ||
| // <auto-generated /> | ||
| using Newtonsoft.Json; |
There was a problem hiding this comment.
Is there a reason System.Text.Json isn't used?
There was a problem hiding this comment.
We have an issue tracking that in the Azure repo here: https://github.com/Azure/typespec-azure/issues/3285. The thought is that we will use the same serialization mechanism as Azure client SDKs, which is built on core .net libraries, but does not primarily use System.Text.Json (also does not use Newtonsoft.Json).
I will recreate the general interest issues in this repo so folks can follow along
|
Do y’all have any planned timelines around merging this PR and releasing it? Is it possible to get this into the November release? |
|
Hi again. I’m excited to see the November release of TypeSpec but know this did not make it. I also know we are entering Holiday season where development like this likely slows down. Please let me know if I can help with anything (reviews, beta testing, documentation, sample repos, etc). I would love to pull this into our repositories in December/early January, so that I can reference it in beginning of the year discussions and planning. |
|
For anyone else watching C# Service emitter, I personally will just look at the related label I see: emitter:service:csharp Happy to be corrected on this. Just very excited to see the progress 😃 |
No description provided.