But we rarely preserve the thing that actually produced it: the session.
Six months later, when someone asks:
“Why was this implemented this way?”
“What constraints did we give the model?”
“Was this a deliberate tradeoff or just the first suggestion?”
… the only artifact left is the diff.
git-memento makes AI-assisted commits auditable using Git notes.
It does not rewrite commit history.
It does not modify commit hashes.
It does not stuff transcripts into commit messages.
It attaches the session transcript as a Git note.
Git already supports attaching metadata to commits via refs/notes/*.
git notes add -m "AI session: codex abc123" <commit>
git notes show <commit>
Notes:
git-memento standardizes this pattern for AI-assisted development.
When you run:
git memento commit <session-id> -m "feat: add idempotency key"
It:
git commit normally.HEAD.git notes add -f -m <rendered-markdown> <commit>
That’s it.
The commit hash stays the same.
AI makes it easy to produce code quickly.
It also makes it easy to lose context quickly.
Attaching the session transcript directly to the commit helps with:
Incident debugging
You can inspect the conversation that produced the code.
Code review
Reviewers can see intent and constraints, not just output.
Compliance / governance
You can demonstrate provenance for machine-assisted changes.
Long-term maintainability
Context lives with the commit, not in Slack or a browser tab.
This is not about policing developers.
It’s about preserving engineering context at the point where history is already recorded: the commit.
You can enforce note coverage in pull requests:
git memento audit --range origin/main..HEAD --strict
Fail if:
There’s also a GitHub Action that:
Notes can survive rebases and amendments via:
git memento notes-rewrite-setup
There are also commands for:
All built on top of normal Git primitives.
curl -fsSL https://raw.githubusercontent.com/mandel-macaque/memento/main/install.sh | sh
Repository:
This is intentionally boring.
No database.
No external service.
No commit rewriting.
No hidden state.
Just Git notes used deliberately.
If AI contributes to a commit, the session should be part of the artifact.
git-memento makes that practical.
When creating bindings between Objective-C and C#, you’re not just translating syntax—you’re bridging two runtimes with very different philosophies. Those differences show up most clearly in memory management, method dispatch, and abstraction mechanisms (protocols vs interfaces). Understanding these mismatches is critical to producing correct, safe, and idiomatic bindings.
Objective-C uses reference counting as its fundamental memory management model. Modern Objective-C relies on ARC (Automatic Reference Counting), which inserts retain, release, and autorelease calls at compile time.
Key points
NSObject *obj = [[NSObject alloc] init]; // retain count +1
self.property = obj; // retain
[obj release]; // release
ARC removes the need to write these calls manually, but the ownership rules still exist:
This ownership rules leak to the API design:
@property (nonatomic, strong) NSObject *owner;
@property (nonatomic, weak) NSObject *delegate;
This matters when designing an API in objc because:
C# uses a tracing garbage collector, we might have long conversations on why this is a better or worse approach; or you can be like python, and do both ;)
var obj = new object();
// No retain/release, GC handles cleanup
From the above, the important details we need to understand are:
The following table shows the mismatch between the two and what we have to be careful about:
| Concept | Objective-C | C# |
|---|---|---|
| Lifetime | Deterministic | Non-deterministic |
| Cycles | Leak | Collected |
| Weak refs | Built-in & common | Explicit & uncommon |
| Destruction | dealloc |
Finalizers / IDisposable |
When binding ObjC to C#, you must:
In Objective-C, methods are not called—they are messages sent at runtime.
[id object doSomething];
If we simplify the above a lot that can be translated to:
objc_msgSend(object, @selector(doSomething));
Consequences:
We can consider Objc to be a dynamic language more like Python or Smalltalk (or C like some smart people can argue)
C# uses compile-time method resolution, with runtime dispatch only for:
obj.DoSomething(); // must exist at compile time
We can summarize this as “If it does not exist, it does not compile”. This a HUGE simplification, virtual methods, interfaces and dynamic work in a diff way, they are useful but come with a cost.
Apple often returns objects that behave like a class but aren’t actually that class, and you can see a lot of this cases in the Microsoft.iOS bindings, I have had several issues with the NSData object and the NSUrlSession
NSString *s = [someApi returnsAString];
NSLog(@"%@", [s class]); // might be __NSCFString
This is legal because:
The fact that Apple does this is of a lot of importance in our API design. Bindings must:
Protocols define a contract of behavior, not inheritance. This is very heavily used and pushed in Swift with the concept of protocol oriented programming.
@protocol MyProtocol <NSObject>
@required
- (void)requiredMethod;
@optional
- (void)optionalMethod;
@end
Features:
if ([delegate respondsToSelector:@selector(optionalMethod)]) {
[delegate optionalMethod];
}
Traditionally, C# interfaces:
public interface IMyInterface
{
void RequiredMethod();
}
This made binding ObjC protocols awkward, especially when optional methods were involved. The old Xamarin API had to work around this situation when generating code and that is why the API for protocols is kind of complicated (we will look at the old API in a future post).
C# 8.0 introduced default implementations, partially closing the gap:
public interface IMyInterface
{
void RequiredMethod();
void OptionalMethod()
{
// default behavior
}
}
This was added to fix a few issues:
The following table simplifies the differences:
| Feature | ObjC Protocol | C# Interface |
|---|---|---|
| Optional methods | Yes | No (until defaults) |
| Runtime checks | Yes | No |
| Duck typing | Common | Rare |
| Delegation | Idiomatic | Less idiomatic |
Objective-C and C# are both “object-oriented,” but they express that idea very differently:
When creating bindings, you are translating:
Understanding these differences upfront helps avoid:
In short: good bindings don’t just compile—they respect the semantics of both worlds. If you think about it, Roslyn analyzer make perfect sense to allow the introduction of new semantics to the C# language. Enforcing these new semantics allows to create better and more idiomatic bindings with the safety net of a compile time check
]]>This post is the first in a series where I’ll explain how, while working on Microsoft.iOS, I came to see iOS bindings not as a code-generation problem, but as a language design problem. More specifically, how we used Roslyn to turn binding definitions into a Domain Specific Language (DSL)—with real syntax, real semantics, and compile-time guarantees.
This series uses Microsoft.iOS as a concrete example, but the ideas apply to anyone building SDKs, bindings, or large code-generated APIs.
A Domain Specific Language is a programming language designed to solve a specific problem, in contrast to a general-purpose language like C#.
This idea is closely related to language-oriented programming: instead of forcing a general language to model a domain, you design language constructs that reflect the domain itself.
The goal of Xamarin.iOS, and later Microsoft.iOS, was to fully expose Objective-C APIs to C# developers. To do that correctly, we needed more than wrappers. We needed a way to describe Objective-C APIs in C#, while preserving:
In other words, we needed a DSL that defines the contract between Objective-C and C#.
Roslyn is a compiler framework that allows you to write code that can be used to generate code. The way I view Roslyn is a set of APIs that allows me to be part of the compiler pipeline, and that way modify its behavior to match that one of the domain I am interested in. I am going to oversimplify how Roslyn works and focus on the parts that are relevant to our goal, but if you are interested in learning more about Roslyn I recommend reading the Roslyn documentation.
For our project we are going to use the three extension points that Roslyn provides:
The above list provides enough entry points to create a Domain Specific Language for iOS bindings and probably more. Let’s focus on what we are planning to do with each of these entry points.
Bindings are very repetitive, most of the code looks the same, and they can be easily automated. Most of the work of a binding is to work around the impedance mismatch between Objective-C and C#. That is, the Objective-C APIs are not as expressive as C# and the C# APIs are not as expressive as Objective-C and we need to work around that.
If you open any of the generated bindings from the Microsoft.iOS project you will notice that they are very repetitive. The majority of the code is the same, and looks like this:
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public static partial global::Foundation.NSCharacterSet Alphanumerics
{
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export ("alphanumericCharacterSet")]
get
{
global::Foundation.NSCharacterSet ret;
if (IsDirectBinding) {
ret = global::ObjCRuntime.Runtime.GetNSObject<global::Foundation.NSCharacterSet> (global::ObjCRuntime.Messaging.NativeHandle_objc_msgSend (this.Handle, global::ObjCRuntime.Selector.GetHandle ("alphanumericCharacterSet")))!;
} else {
ret = global::ObjCRuntime.Runtime.GetNSObject<global::Foundation.NSCharacterSet> (global::ObjCRuntime.Messaging.NativeHandle_objc_msgSendSuper (this.SuperHandle, global::ObjCRuntime.Selector.GetHandle ("alphanumericCharacterSet")))!;
}
global::System.GC.KeepAlive (this);
MarkDirty ();
__mt_Alphanumerics_var_static = ret;
return ret;
}
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export ("setAlphanumericCharacterSet:")]
set
{
var value__handle__ = value!.GetNonNullHandle (nameof (value));
if (IsDirectBinding) {
global::ObjCRuntime.Messaging.void_objc_msgSend_NativeHandle (this.Handle, global::ObjCRuntime.Selector.GetHandle ("setAlphanumericCharacterSet:"), value__handle__);
} else {
global::ObjCRuntime.Messaging.void_objc_msgSendSuper_NativeHandle (this.SuperHandle, global::ObjCRuntime.Selector.GetHandle ("setAlphanumericCharacterSet:"), value__handle__);
}
global::System.GC.KeepAlive (this);
global::System.GC.KeepAlive (value);
MarkDirty ();
__mt_Alphanumerics_var_static = value;
}
}
The above code is generated for every Objective-C API exposed in the bindings. The example above is for the
alphanumericCharacterSet property, and most of the code focuses on converting C# types to Objective-C types and vice
versa. It also makes sure that the memory management is correct, as Objective-C APIs are reference counted while C#
APIs are not. Memory could be a post of its own; maybe in the future I could write about it.
Before Roslyn existed, the approach that Miguel de Icaza took was to write an application that would generate the bindings for us. In his impressive wisdom, Miguel realized that the best way to describe how an API from Objective-C should be exposed in C# was by writing the binding contract itself in C#. To do so, the first (and current) binding generator for Xamarin.iOS was born (bgen). To tackle this task without access to the compiler is very ingenious; the bindings contract would be written as interfaces that the generator would load via reflection and generate the bindings based on that. This approach worked well for bgen, especially before the introduction of nullable annotations in both C# and Objective-C. The process of generating the bindings would follow this pipeline:
graph TD
A[Parse Obj-C Headers] -->|LLVM| B[Generate Definitions]
B -->|C# Interfaces| C[Compile Intermediate DLL]
C -->|Reflection| D[Run bgen]
D -->|Write .g.cs Files| E[Final Compilation]
While the above pipeline is basic, it is still a very powerful tool that can be used to generate bindings for Objective-C APIs. Nevertheless, the more we had to bind, the more complex the process became:
Action<string> and
Action<string?>.Moving to Roslyn allowed us to solve all the above problems and make the process much simpler. We moved from several compilations to a single compilation. What is more, we could use Roslyn to generate the bindings for us as well as access the semantic model of Roslyn to make decisions based on the API structure.
Roslyn generators allowed us to create a more concise API via the use of generic attributes (yes, they exist) for the contract definitions. For example:
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[BindingType<Class>]
public partial class MyObjCClass {
[Export<Constructor> ("initWithScheme:host:path:")]
public ConstructorTests (string scheme, string host, string path);
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export<Property> ("count")]
public virtual partial nuint Count { get; set; }
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export<Method> ("valueForKey:", Flags = Method.MarshalNativeExceptions)]
public virtual unsafe partial NSObject ValueForKey (NSString key);
}
If you look closely, the binding is using the ExportAttribute to describe the Objective-C API for constructors, properties,
and methods. This is invaluable because it allows us to set the Flags property definition to match that of the enum passed
to the ExportAttribute. What does this mean? Well, it means that we can use a single attribute to describe both
properties and methods; at the same time, the compiler will know which one it is and will ensure that the flags match.
I defined the export attribute as follows:
using System.Reflection;
using System.Diagnostics.CodeAnalysis;
using Registrar;
#nullable enable
namespace ObjCBindings {
[Experimental ("APL0003")]
[AttributeUsage (AttributeTargets.Method | AttributeTargets.Constructor | AttributeTargets.Property)]
public class ExportAttribute<T> : Attribute where T : Enum {
/// <summary>
/// Get/Set the selector that is exposed by the decorated method.
/// </summary >
public string? Selector { get; set; } = null;
/// <summary>
/// Get/Set the export configuration flags.
/// </summary >
public T? Flags { get; set; } = default (T);
/// <summary>
/// Get/Set the argument semantics to be used with the native method.
/// </summary >
public ArgumentSemantic ArgumentSemantic { get; set; } = ArgumentSemantic.None;
/// <summary>
/// Get/Set the native prefix to be used in the custom marshal directive.
///
/// The generator will only respect this value if the CustomMarshalDirective flag is set.
/// If the flag is not set the analyzer will raise a compiling error.
/// </summary >
public string? NativePrefix { get; set; } = null;
/// <summary>
/// Get/Set the native suffix to be used in the custom marshal directive.
///
/// The generator will only respect this value if the CustomMarshalDirective flag is set.
/// If the flag is not set the analyzer will raise a compiling error.
/// </summary >
public string? NativeSuffix { get; set; } = null;
/// <summary>
/// Get/Set the library to be used in the custom marshal directive.
///
/// The generator will only respect this value if the CustomMarshalDirective flag is set.
/// If the flag is not set the analyzer will raise a compiling error.
/// </summary >
public string? Library { get; set; } = null;
/// <summary>
/// The type of the result for an async method.
/// </summary>
public Type? ResultType { get; set; } = null;
/// <summary>
/// The name of the generated async method.
/// </summary>
public string? MethodName { get; set; } = null;
/// <summary>
/// The name of the type of the result for an async method.
/// </summary>
public string? ResultTypeName { get; set; } = null;
/// <summary>
/// A code snippet to be executed after the async method call.
/// </summary>
public string? PostNonResultSnippet { get; set; } = null;
/// <summary>
/// The type of the strong delegate for a weak delegate property.
/// </summary>
public Type? StrongDelegateType { get; set; } = null;
/// <summary>
/// The name of the strong delegate for a weak delegate property.
/// </summary>
public string? StrongDelegateName { get; set; } = null;
/// <summary>
/// Get/Set the type of the strong dictionary key class.
/// </summary>
public Type? StrongDictionaryKeyClass { get; set; } = null;
/// <summary>
/// The type of the event args to use.
/// </summary>
public Type? EventArgsType { get; set; } = null;
/// <summary>
/// The name of the type of the event args method.
/// </summary>
public string? EventArgsTypeName { get; set; } = null;
protected ExportAttribute () { }
/// <summary>
/// Mark a managed method as an exported selector.
/// </summary >
/// <param name="selector">The native selector to be exported.</param>
public ExportAttribute (string? selector)
{
Selector = selector;
}
/// <summary>
/// Mark a managed method as an exported selector.
/// </summary >
/// <param name="selector">The native selector to be exported.</param>
/// <param name="semantic">The argument semantics to use when calling the native selector.</param>
public ExportAttribute (string? selector, ArgumentSemantic semantic)
{
Selector = selector;
ArgumentSemantic = semantic;
Flags = default (T);
}
/// <summary>
/// Mark a managed method as an exported selector.
/// </summary >
/// <param name="selector">The native selector to be exported.</param>
/// <param name="flags">The configuration flags for the managed method.</param>
public ExportAttribute (string? selector, T? flags)
{
Selector = selector;
ArgumentSemantic = ArgumentSemantic.None;
Flags = flags;
}
/// <summary>
/// Mark a managed method as an exported selector.
/// </summary >
/// <param name="selector">The native selector to be exported.</param>
/// <param name="semantic">The argument semantics to use when calling the native selector.</param>
/// <param name="flags">The configuration flags for the managed method.</param>
public ExportAttribute (string? selector, ArgumentSemantic semantic, T? flags)
{
Selector = selector;
ArgumentSemantic = semantic;
Flags = flags;
}
}
}
Any avid reader will notice that the ExportAttribute is generic and, not only that, but it exposes properties that do not
make sense in all possible cases. For example, StrongDelegateType only makes sense for weak delegate properties, but
not on methods. This is an example where C# as a general-purpose language is not enough to describe the Objective-C APIs.
The language allows us to describe something that the semantics of the API does not allow; we will talk about this in
the Roslyn analyzers section. That is when we move from a simple API to describe bindings to a DSL that has both
syntax and semantics. For anyone interested, all the attributes are defined in the ObjCBindings namespace.
Rgen, in the Microsoft.iOS project, contains the generator for the bindings. I do want to point out the architecture of the generator:
StringBuilder with
interpolation to generate code, but that is an error in large code generators. My approach was to create a SyntaxFactory
similar to the one provided by Roslyn that would use tokens. This approach allows writing code such as
AssignVariable (GetReturnVariableName (), ConvertToManaged (method, invocation)!);. This allows doing function
composition to generate statements. Some devs might notice that I took a very functional programming approach with
readonly structures and function composition.At this point, we have our first step in the process: we can create a contract definition and compile it, but we still need to ensure that the binding definitions are semantically correct.
The analyzer is probably the cornerstone to ensure that we move from a simple API to a DSL that has both syntax and semantics. The analyzer will be able to detect errors in the binding contract and report them to the user at compile time. This is a crucial step because it will ensure that the bindings are correct and that we do not break the API contract as well as the semantics of the Objective-C APIs. Let’s look at an example:
using System;
using System.Runtime.Versioning;
using AVFoundation;
using CoreGraphics;
using Foundation;
using ObjCBindings;
using ObjCRuntime;
using nfloat = System.Runtime.InteropServices.NFloat;
namespace TestNamespace;
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[BindingType<Class>]
public partial class TestClass{
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export<Property> ("delegate",
ArgumentSemantic.Weak,
Flags = Property.WeakDelegate,
StrongDelegateType = typeof (INSUserActivityDelegate),
StrongDelegateName = "Delegate"
)]
public virtual partial NSObject? OtherWeakDelegate { get; set; }
[SupportedOSPlatform ("ios")]
[SupportedOSPlatform ("tvos")]
[SupportedOSPlatform ("macos")]
[SupportedOSPlatform ("maccatalyst13.1")]
[Export<Property> ("delegateSecond",
ArgumentSemantic.Weak,
Flags = Property.WeakDelegate,
StrongDelegateType = typeof (INSUserActivityDelegate),
StrongDelegateName = "Delegate"
)]
public virtual partial NSObject? WeakSecondDelegate { get; set; }
}
The above code is valid C#; there is nothing that the compiler would complain about, yet it is an invalid Objective-C binding. The issue with the above code is that the weak delegate ‘WeakSecondDelegate’ strong delegate ‘Delegate’ is already used by ‘OtherWeakDelegate’. I cannot stress enough how important this is: we are moving from an API that allows us to define the bindings to a DSL in which the binding definitions are semantically correct and the syntax is straightforward.
Currently, with the bgen implementation used by the project, the only time errors could be reported was at generation time, and dealing with the errors was a pain. With Roslyn analyzers, we can report errors at compile time and provide the user with a detailed error message as well as a fix suggestion. Not only that, but diagnostic messages are clickable on any modern editor and will take the user directly to the line of code that caused the error.
If you look at the Microsoft.iOS project, you will notice that the most complicated code is in the generator, yet the code that provides the most value is in the analyzers.
The Roslyn code fix providers allow us to complete the full developer experience. If the analyzer reports an error, the user can click on the error and the code fix provider will be able to provide a fix suggestion. Because we can provide semantic validations, we also can provide a fix suggestion that will automatically fix the error and correct any issues that the user might have.
So far I have introduced the main idea of using Roslyn to generate bindings for Objective-C APIs and move from a simple API to a DSL that has both syntax and semantics. In the following posts, I will get into the implementation details of the Roslyn generators and analyzers, and how I managed to write a huge amount of unit tests for the generator. I am sure there are a number of things that will help you understand the Roslyn APIs better as well as writing SDKs that use Roslyn to enforce semantic checks at compile time. I will also introduce the full API I was designing for the Microsoft.iOS project as well as how the rgen process was going to be exposed to an MCP to get Copilot to automatically generate the bindings for us from the Objective-C headers.
This post sets the foundation. In the next parts, I’ll go deeper into:
Generating bindings for an API as big as the one provided by Apple in their platforms is a incredibly hard thing to do, on top of already an impossible task, one of the main goals of Xamarin back in the day was to provide next day support. As you can imaging, tackling such a task manually is nearly impossible without a huge amount of developers. Thankfully, from very early in the project, the bindings were mostly generated. I cannot say who were the original inceptors of the design but I have a very strong feeling (and some git logs) that the original idea was from Miguel. Understanding how Xamarin on iOS is build is important to understand why it has taking us so long to enable nullability over all the API.
Building Xamarin iOS is based on a very smart design. Rather than manually writing all the PInvokes manually, the project uses a what I like to call a two pass compilation. The process is as follows:
The following code is an example of one of those API definitions:
[NoWatch, NoTV, iOS (10, 0)]
[MacCatalyst (13, 1)]
[DisableDefaultCtor]
[BaseType (typeof (UIFeedbackGenerator))]
interface UIImpactFeedbackGenerator {
[Export ("initWithStyle:")]
NativeHandle Constructor (UIImpactFeedbackStyle style);
[Export ("impactOccurred")]
void ImpactOccurred ();
[iOS (13, 0)]
[MacCatalyst (13, 1)]
[Export ("impactOccurredWithIntensity:")]
void ImpactOccurred (nfloat intensity);
}
And the corresponding generated code:
[Register("UIImpactFeedbackGenerator", true)]
[Unavailable (PlatformName.WatchOS, ObjCRuntime.PlatformArchitecture.All)]
[Unavailable (PlatformName.TvOS, ObjCRuntime.PlatformArchitecture.All)]
[Introduced (PlatformName.iOS, 10,0, ObjCRuntime.PlatformArchitecture.All)]
public unsafe partial class UIImpactFeedbackGenerator : UIFeedbackGenerator {
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
static readonly IntPtr class_ptr = Class.GetHandle ("UIImpactFeedbackGenerator");
public override IntPtr ClassHandle { get { return class_ptr; } }
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
[EditorBrowsable (EditorBrowsableState.Advanced)]
protected UIImpactFeedbackGenerator (NSObjectFlag t) : base (t)
{
}
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
[EditorBrowsable (EditorBrowsableState.Advanced)]
protected internal UIImpactFeedbackGenerator (IntPtr handle) : base (handle)
{
}
[Export ("initWithStyle:")]
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public UIImpactFeedbackGenerator (UIImpactFeedbackStyle style)
: base (NSObjectFlag.Empty)
{
global::UIKit.UIApplication.EnsureUIThread ();
if (IsDirectBinding) {
InitializeHandle (global::ObjCRuntime.Messaging.IntPtr_objc_msgSend_IntPtr (this.Handle, Selector.GetHandle ("initWithStyle:"), (IntPtr) (long) style), "initWithStyle:");
} else {
InitializeHandle (global::ObjCRuntime.Messaging.IntPtr_objc_msgSendSuper_IntPtr (this.SuperHandle, Selector.GetHandle ("initWithStyle:"), (IntPtr) (l
ong) style), "initWithStyle:");
}
}
[Export ("impactOccurred")]
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public virtual void ImpactOccurred ()
{
global::UIKit.UIApplication.EnsureUIThread ();
if (IsDirectBinding) {
global::ObjCRuntime.Messaging.void_objc_msgSend (this.Handle, Selector.GetHandle ("impactOccurred"));
} else {
global::ObjCRuntime.Messaging.void_objc_msgSendSuper (this.SuperHandle, Selector.GetHandle ("impactOccurred"));
}
}
[Export ("impactOccurredWithIntensity:")]
[Introduced (PlatformName.iOS, 13,0, ObjCRuntime.PlatformArchitecture.All)]
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public virtual void ImpactOccurred (nfloat intensity)
{
#if ARCH_32
throw new PlatformNotSupportedException ("This API is not supported on this version of iOS");
#else
global::UIKit.UIApplication.EnsureUIThread ();
if (IsDirectBinding) {
global::ObjCRuntime.Messaging.void_objc_msgSend_nfloat (this.Handle, Selector.GetHandle ("impactOccurredWithIntensity:"), intensity);
} else {
global::ObjCRuntime.Messaging.void_objc_msgSendSuper_nfloat (this.SuperHandle, Selector.GetHandle ("impactOccurredWithIntensity:"), intensity);
}
#endif
}
} /* class UIImpactFeedbackGenerator */
PS: In this post I am ignoring the amazing work that Rolf does in teh runtime and the native code needed to write the trampolines between C# and ObjC, but that is probably a good topic for another post. PS PS: All this work was done A LONG time before code generators were a thing, and I would argue they are not powerful enough for our use case.
Full nullability support to dotnet (that includes references types) was added in C# 7 yet objectiveC had Nullability annotations earlier than that. Perse that was not an issue for Xamarin since we could annotate the not null parameters in our API definitions and generate the right code, for example:
[NoWatch, NoTV, iOS (15, 0), MacCatalyst (15, 0)]
[BaseType (typeof (UIPresentationController))]
[DisableDefaultCtor]
interface UISheetPresentationController {
[Export ("initWithPresentedViewController:presentingViewController:")]
[DesignatedInitializer]
NativeHandle Constructor (UIViewController presentedViewController, [NullAllowed] UIViewController presentingViewController);
// rest of the API
}
That would generated the following:
[Export ("initWithPresentedViewController:presentingViewController:")]
[DesignatedInitializer]
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public UISheetPresentationController (UIViewController presentedViewController, UIViewController? presentingViewController)
: base (NSObjectFlag.Empty)
{
#if ARCH_32
throw new PlatformNotSupportedException ("This API is not supported on this version of iOS");
#else
global::UIKit.UIApplication.EnsureUIThread ();
var presentedViewController__handle__ = presentedViewController!.GetNonNullHandle (nameof (presentedViewController));
var presentingViewController__handle__ = presentingViewController.GetHandle ();
if (IsDirectBinding) {
InitializeHandle (global::ObjCRuntime.Messaging.IntPtr_objc_msgSend_IntPtr_IntPtr (this.Handle, Selector.GetHandle ("initWithPresentedViewController:
presentingViewController:"), presentedViewController__handle__, presentingViewController__handle__), "initWithPresentedViewController:presentingViewController:");
} else {
InitializeHandle (global::ObjCRuntime.Messaging.IntPtr_objc_msgSendSuper_IntPtr_IntPtr (this.SuperHandle, Selector.GetHandle ("initWithPresentedViewC
ontroller:presentingViewController:"), presentedViewController__handle__, presentingViewController__handle__), "initWithPresentedViewController:presentingViewController:");
}
#endif
}
This approached worked very very well for those parts of the API we control, and it was great when nullability for reference types did not exist. Yet, the approach before nullability had a few annoying corner cases. There is no way to add attributes to the following:
You cannot do:
public Dictionary<string, [NotNull] MyObject> Data { get; set;}
This is perse a limitation of the generator, but the following does not work:
delegate NSComparisonResult NSComparator ([NotNull] NSObject obj1, [NotNull] NSObject obj2);
Once nullability was added to C# 7 we wanted to add annotations to all the code, and while we supported a number of uses cases, using attributes would not fix the situation in which we had to annotate generic types.
dotnet 6 brought with it NullabilityInfoContext the API we needed to be able to use ? as a way to annotate nullability in our API definitions, the problem, Xamarin iOS had to maintain support to code older than dotnet 6. This supposed a problem, we could nto use the new APIs, yet it gave me an idea. Rather that doing some complicated use of pramgas or two different versions of the generator, I decided to do my own implementation of the NullabilityInfoContext for pre dotnet 6 code. That was added and landed in this PR.
The code follows the documentation from the dotnet team to read the nullability metadata. In reality, the process is very simple.
The two attributes we want to look at are:
Both of the use bytes to let you know what nullability state the type has, being:
Teh implementation I wrote is very simple and uses recursion, could have been implemented as a stack, but I prefer clarity for this code which should die soon. Ideally, this implementation will only be used by the generator during the time we have to compile it pre dotnet6 (we already have a dotnet 6 version). Here is the very simple implementation:
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Reflection;
#nullable enable
namespace bgen {
// extension shared between NET and !NET make our lives a little easier
public static class NullabilityInfoExtensions {
public static bool IsNullable (this NullabilityInfo self)
=> self.ReadState == NullabilityState.Nullable;
}
#if !NET
// from: https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
public enum NullabilityState : byte {
Unknown = 0,
NotNull = 1,
Nullable = 2,
}
public class NullabilityInfo {
public NullabilityState ReadState { get; set; } = NullabilityState.NotNull;
public Type? Type { get; set; }
public NullabilityInfo? ElementType { get; set; }
public NullabilityInfo []? GenericTypeArguments { get; set; }
}
// helper class that allows to check the custom attrs in a method,property or field
// in order for the generator to support ? in the bindings definition. This class should be
// replaced by NullabilityInfoContext from the dotnet6 in the future. The API can be maintained (hopefully).
public class NullabilityInfoContext {
static readonly string NullableAttributeName = "System.Runtime.CompilerServices.NullableAttribute";
static readonly string NullableContextAttributeName = "System.Runtime.CompilerServices.NullableContextAttribute";
public NullabilityInfoContext () { }
public NullabilityInfo Create (PropertyInfo propertyInfo)
=> Create (propertyInfo.PropertyType, propertyInfo.DeclaringType, propertyInfo.CustomAttributes);
public NullabilityInfo Create (FieldInfo fieldInfo)
=> Create (fieldInfo.FieldType, fieldInfo.DeclaringType, fieldInfo.CustomAttributes);
public NullabilityInfo Create (ParameterInfo parameterInfo)
=> Create (parameterInfo.ParameterType, parameterInfo.Member, parameterInfo.CustomAttributes);
static NullabilityInfo Create (Type memberType, MemberInfo? declaringType,
IEnumerable<CustomAttributeData>? customAttributes, int depth = 0)
{
var info = new NullabilityInfo { Type = memberType };
if (memberType.IsByRef) {
var e = memberType.GetElementType ();
info = Create (e, declaringType, customAttributes);
// override the returned type because it is returning e and not ref e
info.Type = memberType;
return info;
}
if (memberType.IsArray) {
info.ElementType = Create (memberType.GetElementType ()!, declaringType, customAttributes, depth + 1);
}
if (memberType.IsGenericType) {
// we need to get the nullability type of each of the generics, we use an array to make sure
// order is kept
var genericArguments = memberType.GetGenericArguments ();
info.GenericTypeArguments = new NullabilityInfo [genericArguments.Length];
for (int i = 0; i < genericArguments.Length; i++) {
info.GenericTypeArguments [i] = Create (genericArguments [i], declaringType,
customAttributes, depth + (i + 1)); // the depth can be complicated
}
}
// there are two possible cases we have to take care of:
//
// 1. ValueType: If we are dealing with a value type the compiler converts it to Nullable<ValueType>
// 2. ReferenceType: Ret types do not use an interface, but a custom attr is used in the signature
if (memberType.IsValueType) {
var nullableType = Nullable.GetUnderlyingType (memberType);
info.ReadState = nullableType != null ? NullabilityState.Nullable : NullabilityState.NotNull;
info.Type = memberType;
return info;
}
// at this point, we have to use the attributes (metadata) added by the compiler to decide if we have a
// nullable type or not from a ref type. From https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
//
// The byte[] is constructed as follows:
// Reference type: the nullability (0, 1, or 2), followed by the representation of the type arguments in order including containing types
// Nullable value type: the representation of the type argument only
// Non-generic value type: skipped
// Generic value type: 0, followed by the representation of the type arguments in order including containing types
// Array: the nullability (0, 1, or 2), followed by the representation of the element type
// Tuple: the representation of the underlying constructed type
// Type parameter reference: the nullability (0, 1, or 2, with 0 for unconstrained type parameter)
// interesting case when we have constrains from a generic method
if ((customAttributes?.Count () ?? 0) == 0 && memberType.CustomAttributes is not null)
customAttributes = memberType.CustomAttributes;
var nullable = customAttributes?.FirstOrDefault (
x => x.AttributeType.FullName == NullableAttributeName);
var flag = NullabilityState.Unknown;
if (nullable is not null && nullable.ConstructorArguments.Count == 1) {
var attributeArgument = nullable.ConstructorArguments [0];
if (attributeArgument.ArgumentType == typeof (byte [])) {
var args = (ReadOnlyCollection<CustomAttributeTypedArgument>) attributeArgument.Value!;
if (args.Count > 0 && args [depth].ArgumentType == typeof (byte)) {
flag = (NullabilityState) args [depth].Value;
}
} else if (attributeArgument.ArgumentType == typeof (byte)) {
flag = (NullabilityState) attributeArgument.Value!;
}
info.Type = memberType;
info.ReadState = flag;
return info;
}
// we are using the context of the declaring type to decide if the type is nullable
for (var type = declaringType; type is not null; type = type.DeclaringType) {
var context = type.CustomAttributes
.FirstOrDefault (x => x.AttributeType.FullName == NullableContextAttributeName);
if (context is null ||
context.ConstructorArguments.Count != 1 ||
context.ConstructorArguments [0].ArgumentType != typeof (byte))
continue;
if (NullabilityState.Nullable == (NullabilityState) context.ConstructorArguments [0].Value!) {
info.Type = memberType;
info.ReadState = NullabilityState.Nullable;
return info;
}
}
// we need to consider the generic constrains
if (!memberType.IsGenericParameter)
return info;
// if we do have a custom null atr in any of them, use it
if (memberType.GenericParameterAttributes.HasFlag (GenericParameterAttributes.NotNullableValueTypeConstraint))
info.ReadState = NullabilityState.NotNull;
return info;
}
}
#endif
}
I have not complited all the work, but soon I should have added the needed support for the generator which will fix a number of API bugs.
This post has to goals:
I hope you find it as interesting as I do. If you already knew about this, sorry for making you read.
]]>We want to be able to retrieve all the pull requests created in a repository between two given dates and all their reviews.
If one wants to interact with the Github API the first thing it does is to search in the Octokit documentation to find a solution for their needs
The documentation has a number of examples, but to make it easier for the reader I have added the needed code to get you started. Perse the implementation is quite simple and very naive. Retrieving the PRs can be divided in 4 different operations:
There is no more to it than that, lets take a look at the actual implementation:
The following snippets are from an actual application I have been writing. Where ever you see a Log.Error/Debug just think about it as a log message (I am using Serilog.Sinks.Console).
Perform the search.
async Task<SearchIssuesResult?> GetPullRequests (string repository, DateTimeOffset startDate, DateTimeOffset endDate)
{
// we need to use the search api for this:
try {
var request = new SearchIssuesRequest {
Type = IssueTypeQualifier.PullRequest,
Repos = new () { repository },
Created = new (startDate, endDate),
};
return await ghClient.Search.SearchIssues (request).ConfigureAwait (false); // yes, PRs are issues.. \0/
} catch (Exception e) {
Log.Debug ("Exception {@Message} searching for pull requests", e.Message);
return default;
}
}
Once we have received the search results, we need to get the actual PR objects. The search API does not return a PR but a SearchIssueResult which is an object that represents both, pull requests and issues. As the comment in the code says, GitHub treats PRs as issues. The SearchIssuesResult contains all the numbers of the PRs that match the search. Ideally at this point, we would be done. We could get all the numbers of the PRs that matched and retrieve them, but there are two important details that we need to tackle:
The above makes our code a little uglier, yet doable. We can create a single method that will take a PR number, get the PR object AND all of its reviews and returns those in a tuple. Once we have the method for a single PR, we can create a method that will do the loop in an async way so that all requests are done in parallel.
async Task<(PullRequest Request, PullRequestReview [] Reviews)?> GetPullRequest (RepositoryConfig repositoryConfig, int pullRequestId)
{
try {
var pullRequest = await ghClient.PullRequest
.Get (repositoryConfig.Org, repositoryConfig.Project, pullRequestId)
.ConfigureAwait (false);
Log.Debug ("SUCCESS retrieving PR {@PRId} in repo {@Org}/{@Project}", pullRequestId, repositoryConfig.Org, repositoryConfig.Project);
// retrieve the reviews for the PR
var reviews = await ghClient.PullRequest.Review
.GetAll (repositoryConfig.Org, repositoryConfig.Project, pullRequestId).ConfigureAwait (false);
var reviewsArray = reviews.ToArray ();
Log.Debug ("SUCCESS retrieved {@ReviewCount} reviews for PR {@PRId} in {@Org}/{@Prject}", reviewsArray.Length, pullRequestId, repositoryConfig.Org, repositoryConfig.Project);
return (Request: pullRequest, Reviews: reviewsArray);
} catch (Exception e) {
Log.Error ("Exception {@Message} when trying to retrieve PR {@PRId} in repo {@Org}/{@Project}", e.Message, pullRequestId, repositoryConfig.Org, repositoryConfig.Project);
return default;
}
}
Task<(PullRequest Request, PullRequestReview [] Reviewa)? []> GetAllPullRequests (RepositoryConfig repository, IReadOnlyList<int> ids)
{
var prTasks = new Task<(PullRequest Request, PullRequestReview [] Reviews)?> [ids.Count];
for (int index = 0; index < prTasks.Length; index++) {
prTasks [index] = GetPullRequest (repository, ids [index]);
}
return Task.WhenAll (prTasks);
}
If you look at the above code and wonder why I an using a Task.WhenAll rather than an await per loop instruction, ping me, we need to talk :)
Later in your code you can use the methods as follows:
DateTimeOffset startDateTimeOffset = new (startDate.ToDateTime (TimeOnly.MinValue));
DateTimeOffset endDateTimeOffset = new (endDate.ToDateTime (TimeOnly.MaxValue));
var prsSearchTask = GetPullRequests ($"{repository.Org}/{repository.Project}", startDateTimeOffset, endDateTimeOffset);
var searchResult = await prsSearchTask.ConfigureAwait (false);
var prsTask = GetAllPullRequests (repository, prsSearchTask.Result.Items.Select (i => i.Number).ToArray ());
The above code works perfectly alright, but has a fundamental flaw, it uses a lot of requests. And because we are performing the requests in parallel you will get a secondary threshold warning from GitHub:
HTTP/2 403 Content-Type: application/json; charset=utf-8 Connection: close
{ “message”: “You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.”, “documentation_url”: “https://docs.github.com/rest/overview/resources-in-the-rest-api#secondary-rate-limits” }
At this point, we need to think about how we are approaching the problem. There are several things we can do to fix the rate problem:
I am a fan of implementing both solutions. Not because we reduce the number of requests we are going to fix the problem, it will simply take us longer to get there. Writing code that throttles is not a hard problem to solve, and I am sure there are lots of solutions out there, but how do we reduce the number of requests if we do not own the GitHub REST API? The best approach is to move away from the REST API and uses GitHub GraphQL endpoint.
We already have seen how to solve the problem with Octokit, but how do we solve the problem using GraphQL, or better, can we find any examples on how to do it? Well, either my google foo is not good, or there are no examples our there, which is the reason I an writing this post to being with. As we did with the Octokit implementation, we are going to focus on the steps we need to perform to get to our solution:
I am by definition a lazy developers, if there is something out there that already does the job I tend to avoid re-inventing the wheel. Although there are no libraries that use the GitHub GraphQL endpoint in C# there is a GraphQL.Client library for dotnet. Yes, it does no fully solve our problem but does get us there:
var personAndFilmsRequest = new GraphQLRequest {
Query =@"
query PersonAndFilms($id: ID) {
person(id: $id) {
name
filmConnection {
films {
title
}
}
}
}",
OperationName = "PersonAndFilms",
Variables = new {
id = "cGVvcGxlOjE="
}
};
The above is taken from their examples, we will see how we integrate that with our code alter.
There is no point of me getting into describing how GraphQL works because I am no expert (I have read the docs and used it, but no expert).
The best way for you to understand GraphQL is to use the Explorer provided by GitHub. To make your life easier, you can use the following query as a starting point:
Query:
query GetPRs($query: String!, $cursor: String) {
search(query:$query type:ISSUE after:$cursor first:100) {
issueCount
edges {
cursor
node {
... on PullRequest {
author {
... on User {
login
name
}
}
authorAssociation
number
title
closed
createdAt
closedAt
headRefName
isDraft
labels (last:100) {
totalCount
edges {
node {
... on Label {
name
}
}
}
}
mergeable
merged
mergedAt
reviewRequests (last:100) {
totalCount
}
reviews (last:100) {
totalCount
edges {
node {
... on PullRequestReview {
state
commit {
id
}
author {
... on User {
login
name
}
}
}
}
}
}
state
updatedAt
}
}
}
}
}
Variables (you need to update the values of startDateString, endDateString and repository):
{
"query": "created:{startDateString}..{endDateString} is:pr repo:{repository}"
}
Now, GraphQL queries return json, but you need to understand several concepts to understand the result:
The above query returns a result similar to the following (this is from one of our open source repos, do not worry):
{
"data": {
"search": {
"issueCount": 58,
"edges": [
{
"cursor": "Y3Vyc29yOjE=",
"node": {
"author": {
"login": "dustin-wojciechowski",
"name": null
},
"authorAssociation": "MEMBER",
"number": 17073,
"title": "[src] Added try catches to the methods in AVAudioPlayer to prevent Initiali…",
"closed": false,
"createdAt": "2022-12-15T18:46:40Z",
"closedAt": null,
"isDraft": true,
"labels": {
"totalCount": 0,
"edges": []
},
"mergeable": "MERGEABLE",
"merged": false,
"mergedAt": null,
"reviewRequests": {
"totalCount": 0
},
"reviews": {
"totalCount": 0,
"edges": []
},
"state": "OPEN",
"updatedAt": "2022-12-15T20:42:01Z"
}
},
{
"cursor": "Y3Vyc29yOjI=",
"node": {
"author": {},
"authorAssociation": "CONTRIBUTOR",
"number": 17072,
"title": "[net8.0] Update dependencies from xamarin/xamarin-macios",
"closed": false,
"createdAt": "2022-12-15T17:59:36Z",
"closedAt": null,
"isDraft": false,
"labels": {
"totalCount": 0,
"edges": []
},
"mergeable": "MERGEABLE",
"merged": false,
"mergedAt": null,
"reviewRequests": {
"totalCount": 0
},
"reviews": {
"totalCount": 0,
"edges": []
},
"state": "OPEN",
"updatedAt": "2022-12-15T18:02:32Z"
}
},
...
}
}
}
At this point, we are close to have the full solution. We need to solve two problems:
As I mentioned, GraphQL returns json objects, so we can use System.Text.Json to deal with the result, which is what GraphQL.Client uses. But System.Text.Json does now know how to handle Edges and Nodes :/
The following generic code will help you with that, we just need an Edge and a Node class that will contain the needed information, hen just use the generic type you need to deserialize:
public record GraphQLNode<T> {
[JsonPropertyName ("node")]
public T? Node { get; set; }
[JsonPropertyName ("cursor")]
public string? Cursor { get; set; }
}
public record GraphQLEdge<T> {
[JsonPropertyName ("edges")]
public GraphQLNode<T> [] Edges { get; set; } = Array.Empty<GraphQLNode<T>> ();
[JsonPropertyName ("totalCount")]
public int TotalCount { get; set; }
}
Pagination is a pain in any language, any framework in any place.. but it has to be done and your users will be happy about it. Now, how do we deal with pagination in the GraphQL world and GitHub. If you go back to the qeury sample I provided you will notices that I am using a variable called $cursor:
query GetPRs($query: String!, $cursor: String) {
search(query:$query type:ISSUE after:$cursor first:100) {
}
}
This cursor is what we are going to use to let GitHub know that we want the first 100 results after a given position. 100 is not a random number, is the maximun number of results allowed by GitHub. With that in mind, the process to follow is vry very simple:
It is very important to pay attention and remember that you need the last node cursor, else you will get duplicated results or if you use the first one, an infinite loop.
The following code uses a generic, gut shows the process that needs to be performed. I am use dotnet 7 so my interfaces have static methods, all the rest is straight forward for the above described steps.
public async Task<IEnumerable<TReturn>> GetGraphQLSearch<TSearch, TReturn> (string repository, DateOnly startDate, DateOnly endDate) where TSearch : IGraphQLSearch<TReturn>
{
try {
string? cursor = null;
int? issuesCount = null;
int currentlyFetch = 0;
List<TReturn> result = new ();
do {
var graphQlRequest = (cursor is null)
? TSearch.BuildRequest (repository, startDate, endDate)
: TSearch.BuildRequest (repository, startDate, endDate, cursor);
var graphQLResponse = await graphQLClient.SendQueryAsync<TSearch> (graphQlRequest);
if (graphQLResponse.Errors is not null) {
var errors = string.Join (',', graphQLResponse.Errors.Select (e => e.Message));
Log.Error ("GraphQL Errors {@GraphQLErrors}", errors);
return Array.Empty<TReturn> ();
}
if (graphQLResponse.Data.Search is null)
return Array.Empty<TReturn> ();
// fluent and nullability are not friends :(
var nodes = from node in graphQLResponse.Data.Search.Edges
where node is not null
select node.Node;
var nodesArray = nodes.ToArray ();
result.AddRange (nodesArray);
Log.Debug ("Received {@PRCount} from GraphQL search", nodesArray.Length);
if (issuesCount is null) {
Log.Debug ("GraphQL first search request for {@Repository}", repository);
// the issue count will be the TOTAL issue count (in the first request) minus what we have in the
// current request
issuesCount = graphQLResponse.Data.Search.IssueCount;
Log.Debug (
"GraphQL search issue count for {@Repository} is {@IssueCount} after removing {@ResponseCount}",
repository, issuesCount, graphQLResponse.Data.Search.Edges.Length);
}
currentlyFetch += graphQLResponse.Data.Search.Edges.Length;
Log.Debug ("GraphQL search fetched {@FetchCount} out of {@IssueCount}", currentlyFetch, issuesCount);
// if the issuesCount is not 0, set the cursor to do a second request
if (issuesCount > currentlyFetch) {
Log.Debug ("GraphQL search remaining issues {@IssueCount}", issuesCount);
cursor = graphQLResponse.Data.Search.Edges [^1].Cursor; // grab the last cursor
} else {
// we hve retrieved all pages, could be achieved by setting cursor to null, but always be
// explicit over implicit
Log.Debug ("GraphQL search retrieved all {@PRCount} PRs", issuesCount);
break;
}
} while (cursor is not null);
return result;
} catch (Exception e) {
Log.Debug ("Exception GraphQl search {@ExceptionMessage}", e.Message);
return Array.Empty<TReturn> ();
}
}
The last step to have a real solution is to be able to write a test. But how do we write tests against a GRaphQL API? Well, believe it or not is not as hard as it sounds. T o do show what we are going to be doing is to use RichardSzalay.MockHttp a library that can only be said to be the nest best thing after slice bread (for testing network calls).
The MockHttp is the corner stone to test all the different calls. What we want to do is to create a GraphQL.Client client that uses an HttpClient that has a mocked handler, once we have done that, we can set the expectations, and happy testing (the sample code uses xUnit):
public class TestGraphQL {
readonly HttpClient httpClient;
readonly GraphQLHttpClient graphQlHttpClient;
readonly MockHttpMessageHandler mockHttpMessageHandler;
readonly string githubGraphQLEndpoint = "https://api.github.com/graphql";
public TestGraphQL () {
mockHttpMessageHandler = new ();
httpClient = new (mockHttpMessageHandler);
// this is where the magic happens
var options = new GraphQLHttpClientOptions { EndPoint = new (githubGraphQLEndpoint) };
graphQlHttpClient = new (options, new SystemTextJsonSerializer (), httpClient);
}
[Fact]
public async Task SampleTest ()
{
// set the mocker expectations
var prData = TestsHelpers.ReadJsonFile ("graphQLPRSearch.json");
Assert.NotNull (prData);
mockHttpMessageHandler.When (githubGraphQLEndpoint)
.WithPartialContent ("GetPRs")
.Respond ("application/json", prData);
// tet your code :)
}
}
From the above I would like to point out a few things:
WithPartialContent method with the function name of my query GetPRs. If you have more queries, keep that in mind.With the given exmaples, you should have all the pieces you need to perform queries against the GitHub GraphQL api using C#. In is not complicated, but there is no documentation or many example. Hope it helps.
]]>