feat: .NET SDK update for version 6.0.0#99
Conversation
Greptile SummaryThis PR upgrades the Appwrite .NET SDK from v5.1.0 to v6.0.0, aligning it with new server-side APIs. The changes are largely auto-generated and follow consistent SDK patterns already established in the codebase.
Confidence Score: 5/5All breaking changes are intentional and documented in CHANGELOG; new code follows established SDK patterns with no logic errors found. The diff is auto-generated SDK code. Breaking changes (Health/Usage removal, field removals, type narrowing) are all explicitly called out in the CHANGELOG. The new SetBearer method correctly includes the "Bearer " scheme prefix. No missing null guards, incorrect conversions, or mismatched API paths were identified in the changed paths. No files require special attention; the previously flagged Program model naming issue is tracked in an existing review thread. Important Files Changed
Reviews (3): Last reviewed commit: "chore: update .NET SDK to 6.0.0" | Re-trigger Greptile |
| namespace Appwrite.Models | ||
| { | ||
| public class Program | ||
| { |
There was a problem hiding this comment.
Program conflicts with .NET entry-point class name
Naming a model class Program inside the Appwrite.Models namespace can cause confusing compiler errors for users whose top-level Program class is in the global namespace or in a project that imports Appwrite.Models with a using directive. .NET's implicit Program entry-point class (C# 9+ top-level statements) is also unqualified, so any file that does using Appwrite.Models; and then references Program will see an ambiguity error. Consider renaming to BillingProgram or ProgramDetails to avoid the collision.
Prompt To Fix With AI
This is a comment left during a code review.
Path: Appwrite/Models/Program.cs
Line: 13
Comment:
**`Program` conflicts with .NET entry-point class name**
Naming a model class `Program` inside the `Appwrite.Models` namespace can cause confusing compiler errors for users whose top-level `Program` class is in the global namespace or in a project that imports `Appwrite.Models` with a `using` directive. .NET's implicit `Program` entry-point class (C# 9+ top-level statements) is also unqualified, so any file that does `using Appwrite.Models;` and then references `Program` will see an ambiguity error. Consider renaming to `BillingProgram` or `ProgramDetails` to avoid the collision.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
This PR contains updates to the SDK for version 6.0.0.
What's Changed
Healthservice with all its models and enumsUsageservice andUsageEvent/UsageGaugemodelsMessaginglog methodsListMessageLogs,ListProviderLogs,ListSubscriberLogs,ListTopicLogscountryCode/countryNamefromActivityEvent(countryremains)defaultparameters fromList<object>to typed coordinate listsProjectOAuth2 server properties nullableOrganizationservice methodsGet,Update,Delete, and membership CRUDClient.SetBearerfor OAuth access token authenticationQuery.VectorDot,Query.VectorCosine,Query.VectorEuclideanProject.UpdateOAuth2AppwriteandProject.UpdateDenyCorporateEmailPolicymethodspromptandmaxAgeparameters plus OAuth2 device-flow server optionsspecificationonTablesDB.Create,newSpecificationonBackups.CreateRestorationtypeonListSpecifications,tokenonGetDeploymentDownloadLocale, email classification fields onUserDatabaseStatus,BillingPlanGroup,OAuth2OidcPromptenums and new key scopesDatabase.Status,BackupPolicy.Type,Block.Mode,Membership.UserAccessedAt