[Monitor Ingestion] AOT Support

[jorgerangel-msft]

Contributing to the Azure SDK

Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.

For specific information about pull request etiquette and best practices, see this section.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Azure.Monitor.Ingestion

[Copilot]

Pull Request Overview

This pull request adds ModelReaderWriterContext support to the Azure Monitor Ingestion SDK by enabling the use-model-reader-writer option in AutoRest configuration and introducing the AzureMonitorIngestionContext class.

• Enables ModelReaderWriterContext functionality in AutoRest configuration
• Adds a new AzureMonitorIngestionContext class that extends ModelReaderWriterContext
• Updates API surface across all target frameworks

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

File	Description
sdk/monitor/Azure.Monitor.Ingestion/src/autorest.md	Enables ModelReaderWriterContext generation by adding use-model-reader-writer: true
sdk/monitor/Azure.Monitor.Ingestion/api/Azure.Monitor.Ingestion.netstandard2.0.cs	Adds AzureMonitorIngestionContext class for .NET Standard 2.0
sdk/monitor/Azure.Monitor.Ingestion/api/Azure.Monitor.Ingestion.net8.0.cs	Adds AzureMonitorIngestionContext class for .NET 8.0
sdk/monitor/Azure.Monitor.Ingestion/api/Azure.Monitor.Ingestion.net462.cs	Adds AzureMonitorIngestionContext class for .NET Framework 4.6.2

[jsquire]

//cc: @sbomer

[jsquire]

/azp run net - Azure.Monitor.Ingestion - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jsquire]

@sbomer: I'd appreciate your thoughts with respect to the AOT path here. We've got two warnings, for:

Azure.Monitor.Ingestion\src\LogsIngestionClient.cs(118): Trim analysis warning IL2026: Azure.Monitor.Ingestion.LogsIngestionClient.<Batch>d__22`1.MoveNext(): 
Using member 'System.BinaryData.FromObjectAsJson<T>(T,JsonSerializerOptions)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when 
trimming application code. JSON serialization and deserialization might require types that cannot be statically analyzed.

This traces back to an incoming type that we do not own, and therefore cannot provide a context for. It falls back to BinaryData.FromObjectAsJson and the reflection-based serializer path.

internal static IEnumerable<BatchedLogs> Batch<T>(IEnumerable<T> logEntries, LogsUploadOptions options = null)
{
 // ... SNIP
    foreach (var log in logEntries)
    {
        BinaryData entry;
        // If log is already BinaryData, no need to serialize it
        if (log is BinaryData d)
            entry = d;
        // If log is not BinaryData, serialize it. Default Serializer is System.Text.Json
        else if (options == null || options.Serializer == null)
            entry = BinaryData.FromObjectAsJson(log);
// ... SNIP

Seeing as how T is an unconstrained type passed as a parameter, I'm not sure the right path forward.

[m-nash]

Seeing as how T is an unconstrained type passed as a parameter, I'm not sure the right path forward.

Typically we mark the existing api with requires unreferenced / dynamic code and add an overload which will take in a context.

Either a ModelReaderWriterContext if we are using MRW here (most common for azure sdks) or a JsonSerializerContext if you are using STJ

[jsquire]

/azp run net - Azure.Monitor.Ingestion - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).