Introduction

In C#, you can create an array of anonymous objects as long as every element has the same anonymous type shape. This is useful for short-lived projections and local data shaping, but anonymous types are intentionally limited in scope, so they are not a good substitute for named DTOs in public or long-lived APIs.

Creating an Array of Anonymous Types

The usual pattern is:

1var items = new[]
2{
3    new { Id = 1, Name = "Ada" },
4    new { Id = 2, Name = "Grace" },
5    new { Id = 3, Name = "Linus" }
6};
7
8foreach (var item in items)
9{
10    Console.WriteLine($"{item.Id}: {item.Name}");
11}

This works because all three elements have the same property names and property types in the same order, so the compiler can infer one anonymous type for the entire array.

What "Same Shape" Means

These must match:

• property names
• property types
• property order

This fails because the anonymous types are different:

1var bad = new[]
2{
3    new { Id = 1, Name = "Ada" },
4    new { Id = 2, Title = "Engineer" }
5};

The compiler cannot infer one common anonymous type because the shapes differ.

Anonymous Types Are Strongly Typed, Not Dynamic

Although the type has no explicit name in your code, it is still a real compile-time type generated by the compiler.

That means you still get:

• IntelliSense
• compile-time property checking
• type inference through var

It is not the same as dynamic.

Great for Local Projections

Anonymous object arrays are especially useful in LINQ projections where the result stays local.

1using System.Linq;
2
3var numbers = new[] { 1, 2, 3, 4 };
4
5var projected = numbers
6    .Select(n => new { Value = n, Square = n * n })
7    .ToArray();
8
9foreach (var row in projected)
10{
11    Console.WriteLine($"{row.Value} -> {row.Square}");
12}

This is a clean fit because the anonymous type is used immediately and does not need to cross a method boundary.

Where Anonymous Arrays Become Awkward

Anonymous types do not travel well across API boundaries. You cannot declare a return type using the anonymous type name because there is no source-level name to write.

That means code like this is awkward:

• returning anonymous arrays from public methods
• storing them in fields with explicit reusable types
• sharing them across layers of the application

If the data shape matters outside one local scope, define a named record or class instead.

Use a Record or Class When the Shape Is Real

If the structure has meaning, give it a name:

1public record PersonRow(int Id, string Name);
2
3var items = new[]
4{
5    new PersonRow(1, "Ada"),
6    new PersonRow(2, "Grace")
7};

This is usually the better choice for method returns, serialization, contracts, and test fixtures.

Read-Only Nature of Anonymous Type Properties

Anonymous type properties are read-only after construction.

var person = new { Id = 1, Name = "Ada" };
// person.Name = "Grace"; // not allowed

That makes them convenient for small immutable projections, but not for workflows that need later mutation.

Common Pitfalls

The biggest mistake is assuming anonymous types are dynamic or weakly typed. They are still compiler-generated static types.

Another issue is mixing different anonymous shapes in one array and expecting the compiler to unify them automatically.

A third problem is using anonymous arrays beyond local scope when a named record or class would make the code clearer and easier to maintain.

Summary

• Arrays of anonymous objects work when every element has the same anonymous type shape.
• Anonymous types are strongly typed and work well with var.
• They are especially useful for local LINQ projections and short-lived data shaping.
• Their properties are read-only after construction.
• Use a named type when the data needs to cross method or architectural boundaries.