Kiota 1.5.1 fails to generate client (but 1.4.0 could)

[HowardvanRooijen]

Hi,

In July I did a spike to use Kiota v1.4.0 to generate a C# client for Firecracker micro-vm management API swagger definition

via

kiota generate -l CSharp -c FireClient -n Firecracker.Client -d "c:\temp\firecracker\firecracker.yaml" -o "c:\temp\firecracker\client"

and it worked, but generated the following warning:

warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/MmdsConfig/properties/ipv4_address - The format 169.254.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-4]).([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]) is not supported by Kiota for the type string and the string type will be used.

I've just upgraded to the latest version of Kiota (v1.5.1) and now the client fails to generate, with the following message:

warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/MmdsConfig/properties/ipv4_address - The format 169.254.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-4]).([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]) is not supported by Kiota for the type string and the string type will be used.
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: The element FirecrackerVersion could not be found in the class FirecrackerVersion

[baywet]

Thanks for your interest in kiota and for reporting this.
It seems the regression introduced with 1.5.1 is already fixed by the upcoming 1.6.0.
Please go ahead and try with the preview version dotnet tool update -g Microsoft.OpenApi.Kiota --prerelease

Also the URL of the description (to use as argument is) https://raw.githubusercontent.com/firecracker-microvm/firecracker/main/src/api_server/swagger/firecracker.yaml

[HowardvanRooijen]

Perfect! Can confirm it works again with 1.6.0-preview.202308240001 - I'm also excited to see the <auto-generated/> header!

[HowardvanRooijen]

OK - If I generate the client, using the following command:

kiota generate -l CSharp -c FirecrackerManagementClient -n Firecracker.Management -d https://raw.githubusercontent.com/firecracker-microvm/firecracker/main/src/api_server/swagger/firecracker.yaml -o "c:\temp\firecracker\client"

I get the following issues:

Firecracker.Management.Models.MachineConfiguration has a compile error on line 29:

CpuTemplate = CpuTemplate.None;

As the enum type is not properly referenced, because the correct namespace / alias is missing.

Firecracker.Management.FirecrackerManagementClient has a missing using statement using Microsoft.Kiota.Serialization.Multipart; - I'm not sure if we're missing a matching preview nuget package. Which leads to a missing type (`MultipartSerializationWriterFactory) on line 104:

`ApiClientBuilder.RegisterDefaultSerializer();

I have the following nuget packages installed:

<PackageReference Include="Microsoft.Kiota.Abstractions" Version="1.3.1" />
<PackageReference Include="Microsoft.Kiota.Http.HttpClientLibrary" Version="1.1.1" />
<PackageReference Include="Microsoft.Kiota.Serialization.Form" Version="1.0.1" />
<PackageReference Include="Microsoft.Kiota.Serialization.Json" Version="1.0.8" />
<PackageReference Include="Microsoft.Kiota.Serialization.Text" Version="1.0.3" />

[baywet]

Thanks for the additional information. Have you tried to run kiota info -l CSharp to know which dependencies you should be installing?
The enum thing is a bit more concerning. Can you check whether #3228 sounds like the same issue and provide the additional details there please? Otherwise please go ahead an create another issue so we can keep things focused.

[HowardvanRooijen]

Thanks! If I had my reading glasses on, I would have seen the HINT recommending running that command - although from a UX perspective I don't understand:

a) why we don't get a .csproj file with all the required packages
b) why the required packages aren't just included in the output message rather than the hint

Although this scenario was a bit of a gotcha as the Microsoft.Kiota.Serialization.Multipart package was a new dependency, as I re-generated into a project I created with v1.4.0

Enum - I think it's a different problem than #3228 and I'll raise another issue.

[HowardvanRooijen]

Done: #3233

[baywet]

Not touching the project files is a design decision. Projects are structured in really different ways, there can be multiple project management tech for any language (e.g. gradle and maven for java), lots of project management tech don't have a CLI or object model to edit dependencies (gradle or maven), versioning is also a constraint.... And you might want different dependencies (eg different authentication provider)
So rather than mess up with the project file and take on a massive maintenance matrix, we leave that to the user who knows better.

As for showing the dependencies right away, we might consider it. I think the thinking was one command for one thing, and also generate can produce a lot of logs, so having a separate command seemed like better UX.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[baywet]

closing since the initial bug was already addressed and we can follow up on a different issue for the dependencies aspect.