add pet store examples to the samples repo
- [ ] in the kiota-samples repo, copy the "templates" folder into a "petstore" folder.
- [ ] for each language, generate an SDK from this description
- [ ] add an entry to the table of content
- [ ] update the readme in the folder that was created.
Note: the projects won't build until you add references to kiota abstractions.
Sure, I'll get to it.
Further to this issue, here's the cli command I've been trying to use (but with no luck / errors out):
>kiota.exe --openapi https://petstore.swagger.io/v2/swagger.json -o OpenApiClient\Generated -c PetShopGraphClient --loglevel Information
and this throws an error:

(one of the two schema instances is a null instance)
@PureKrome Thanks for reporting this and trying to generate the pet store samples. Fixed it with #185
@pureKrome, are you still working on this or should we let @wcontayon take a stab at this?
Note: it'll probably be better to wait for #204 to be merged before taking this on.
Happy to wait and/or let @wcontayon take it - i've still tried and haven't had too much luck yet.
Thanks for the lightspeed answer! Did you run into any additional issue? If so, can you report them as new issues so we can tackle them please?
I thought the latest code pull .. didn't work? i think the generated code was requiring nuget packages that didn't exist?
You should be able to get the packages by configuring the package manager to use the github package feed. Which language are you targeting at the moment?
C# / .NET Core.
Yep - I just haven't done the Github PAT yet. Feels like a frustrating (temp) barrier to entry. But I'll give it a go!
the very summarized instructions are here. If this is not clear enough, don't hesitate to complain/PR the instructions. We'll be removing this barrier once we go to public preview as mentioned in #122 and #128 but it's too early for now.
I'm going to assign this to you for now, to avoid having multiple people working on the same thing. If you feel like you don't have time or or don't want to do it anymore, just let me know. Thanks for the help!
Status Update:
- [x] Created GH PAT
- [x] Forked "Samples" repo
- [x] Duplicated then rename templates folder
** "alt-tabbed" over to another version of VS with
Kiota upstream/master - [x] Pulled (to make sure I've got the latest Kiota code)
- [x]
"commandLineArgs": "--language csharp --openapi https://petstore.swagger.io/v2/swagger.json -o ..\\..\\..\\PetstoreClient-dotnet -c GraphClient --loglevel Information " - [x] copied generated csharp client over to the new samples folder ** "alt-tabbed" back to "kiota-samples"
- [x] (TEMP STEP) updated
nuget.configwith myusernameandPAT Token - [x] Installed package
Microsoft.Kiota.Abstractions(with the PAT, this works π) - [x] βCompile code : fails
- [ ] βSDK generation failed (see pictures) :


Thoughts:
- Not sure what
Fileis and why it didn't get generated? usernamevsusername. this is frustrating :( the class AND the property are the same (which can't be allowed, it seems). One of these will need to be renamed auto-magically during generation if both exist? I'm guessing the property ... with maybe a hint? This might be above my pay-grade π
Update
The File might be related to this node:

Hey @PureKrome Thanks for the additional feedback here! Pet Store is full of surprises π² ! I've logged a few issues to track future work to fully support all those cases. We won't be fixing #219, #220 and #221 for now. I however authored #222 which works around these issues and fixes #218. Give it a try and let me know what you think! Thanks again for all the work.
Thanks again @baywet for looking into this.
I don't understand #219 and #220 (that just me struggling to grok stuff).
but with #221 - until that is done, File will always be generated, preventing the GeneratedClient from compiling, right?
no because this file type is only included because of the schema of the "multipart/form-data" request schema. And I have excluded that content type for requests with my latest PR as even if we fix the generation issue, we'll still need to add a new serializer we don't have today. If you delete the previous generation result and do it again, you should end up with everything for pet store except that operation.
Hey @PureKrome, How are things going on this front?
Heya - i've not forgotton this. I've just been slammed. I still want to do this (i have started on it. I got stuff done/generated in docker images, actually :P )
Heya again @baywet - trying this again.
- β
Downloaded v
0.05 x64 exe - β
Copied
templatedirectory. renamed topetshop - β
kiota.exe --openapi https://petstore.swagger.io/v2/swagger.json --language csharp -o PetshopClient-c ApiClient --loglevel information
(just ignore that the folder should be called something like PetStoreClient .. not Pet -SHOP- Client π

- β
Updated
nuget.configwith my username | PAT - β open dotnet.csproj
- π replaced the file reference with a package reference

- β Build solution.

i'm guessing i've done some incorrect/missing step.
Hey @PureKrome You've made great progress! No, it's not you doing anything wrong, it's me forgetting to update the template project and probably the fact the released version is a bit behind.
Project file updates
Not only these references only work relatively to cloning kiota and kiota samples as a submodule, it reference to the older kiota core single package that was splat a while ago.
Here is how to fix it:
-
remove all the project references.
-
Keep the abstractions reference as it is.
-
Add the following package references (you don't need those to compile, but you'll need those to run)
<PackageReference Include="Microsoft.Kiota.Authentication.Azure" Version="1.0.2" /> <PackageReference Include="Microsoft.Kiota.Serialization.Json" Version="1.0.2" /> <PackageReference Include="Microsoft.Kiota.Http.HttpClient" Version="1.0.2" />
Released version behind
Can you generate from a kiota built from the latest of the main branch please? If it does fix the issue, I'll create a release. If it doesn't, I'll investigate further.
Thanks @baywet ! I'll give all this another go :) this is great info!
Heya @baywet.
had another attempt at this. I feel bad for keeping posting questions/problems. Sincerely, so sorry.
So I've tried again. This time, I used kiota (latest code as of 30 mins ago) to generate the -client-.
Here's some WARNING output:

Ignoring these warnings, I continued on:
- [x] Pulled latest copy of
kiota-samples - [x] Created a new branch.
- [x] Copied dotnet folder from
msgraph-mail - [x] Copied my generated files which
kiotajust created for me, over to this new folder - [x] Updated
.csprojto use the nugets, as mentioned above. - [x] Updated
nuget.configwith my credentials AND added nuget.org as a 2nd source (fall back) - [x]
dotnet restoreworked - [ ]
dotenet buildfails

For simplicity, I have:
- Made a solution (yes, that doesn't work for vs code users)
- Added a new branch, to my fork .. to show you want i'm doing.
Does any of this info, help?
@PureKrome No need to apologize at all. This effort is super valuable and helps us identify and fix the rough edged corners of Kiota before it reaches prime time. From what you describe, you did everything right. I'm not sure why you have that bug though since I already fixed with with #218 (you had already reported it earlier in the conversation). I reopened the bug and will take another look at it. Thanks for your patience on the matter and for all the super valuable feedback!
also put that together in case it was a confusion between forks/remotes etc... https://github.com/PureKrome/kiota/pull/1
@PureKrome I can confirm that was an issue with the generator. A casing issue π€¦ββοΈ Put a PR to fix it #378. Can you give it another try using that branch (or after it gets merged) please? Thanks a lot again!
Woot! Sure will! i'll give it a go, tonight! Exciting .. hopefully getting closer ... :)

I've had a few more attempts in the last three weeks and still not working. I've had different errors over this period .. with today's being different again.
This is the latest error(s): (sorry the images are so wide)


Note that I've just pulled 1.0.4 for one of the packages.
dotnet.csproj
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="Microsoft.Kiota.Authentication.Azure" Version="1.0.3" />
<PackageReference Include="Microsoft.Kiota.Serialization.Json" Version="1.0.3" />
<PackageReference Include="Microsoft.Kiota.Http.HttpClient" Version="1.0.4" />
</ItemGroup>
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
and the client was generated with latest code from main branch, which I just pulled down about 15 mins ago.
Thoughts? I'm wondering if this is my fault, now?
@PureKrome Thanks for the feedback once again! No you didn't do anything wrong, this is another limitation that wasn't anticipated. I've logged #467 , the note at the bottom provides a little more context on the issue. I'll try to get going on that bug as soon as I have some time. :)
Thanks mate :) really appreciate it, as always!
@baywet - good news tonight!
- βοΈ latest
kiotacode - βοΈ latest nugets
- βοΈ client generated and code compiles
so my next question -> how to use the generated ApiClient ?
It says it requires an IHttpCore. So i've been digging around various folders in the root directory and did find an HttpCore. this though, requires an IAuthenticationProvider which .. after further searching, looks like there is only -one- implimentation of this? An AzureIdentityAuthenticationProvider only? Which wouldn't apply to me, here because I'm not hitting an Azure auth-secured endpoint.
HttpCore requires an IAuthenticationProvider. Was this an oversight?
Next, I did find some docs on this ... and the docs have no requires parameters?

any ideas?
That's great news! Thank you for all the feedback on this, it definitively help mature Kiota. As a general disclaimer, we know the documentation is far behind at this point. We do have a few issues to capture that see #129, #130 & #132. Help on those is welcomed, and I'll try to see with the PMs (@roinochieng @maisarissi) whether we can slow down on feature work and tackle this as the lack of up to date documentation is hurting both our community adoption and the ramp-up of new internal developers on the project. Nonetheless I put together #495 to at least address your comments.
Now, here is a question for you: we made the assumption that most clients generated with Kiota would talk to APIs using some form of authN/authZ. This is why we made the choice of requiring an auth provider, this guides the consumer into "doing the right thing". How does that assumption hold from your point of view?
Another question for you: did you try looking at the doc comments/navigating the symbols to discover where this authentication provider could come from? Did it help at all?
At this time a workaround for you would be to implement a "no-op authentication provider" from the IAuthenticationProvider interface and return non-empty string. Hopefully the target API will ignore the bearer.
But I think a few things could be done to make it easier for other authentication schemes:
- Update the interface to accept the full request info, so implementations can set any header they want to, or nothing.
- Provide a default "AnonymousAuthenticationHandler" in the abstractions library.