Introduction

In C#, string.Join is not limited to string[]. It can also join object collections by calling ToString() on each element. The main decision is whether that default conversion is good enough for your data, or whether you should project the objects into a more explicit string representation first.

string.Join Can Handle Object Arrays

A simple example works directly with object[].

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        object[] values = { 42, true, 3.14, "done" };
8        string result = string.Join(", ", values);
9        Console.WriteLine(result);
10    }
11}

This prints a comma-separated string because string.Join uses ToString() on each element.

Why Explicit Projection Is Often Better

Relying on ToString() is convenient, but it may not produce the exact output you want. Custom objects often inherit the default implementation from object, which gives the type name rather than useful content.

1using System;
2using System.Linq;
3
4public class User
5{
6    public string Name { get; set; } = "";
7    public int Score { get; set; }
8}
9
10class Program
11{
12    static void Main()
13    {
14        var users = new[]
15        {
16            new User { Name = "Ada", Score = 10 },
17            new User { Name = "Ben", Score = 20 }
18        };
19
20        string result = string.Join(", ", users.Select(u => $"{u.Name}:{u.Score}"));
21        Console.WriteLine(result);
22    }
23}

This is usually the better pattern because the formatting is explicit and stable.

ToString() Versus Projection

There are two good strategies:

• override ToString() on the type if the object has one obvious string form
• use Select(...) when the joined text is specific to this one output context

For domain objects, overriding ToString() just to satisfy one logging or export case can be too broad. Projection is often safer.

Null Values Need Attention

When joining object arrays, null values can appear. string.Join treats null elements as empty strings, which may or may not be what you want.

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        object?[] values = { "apple", null, "orange" };
8        string result = string.Join("|", values);
9        Console.WriteLine(result);
10    }
11}

This produces apple||orange. If that output is ambiguous, filter or replace nulls before joining.

1using System.Linq;
2
3string safe = string.Join(
4    "|",
5    values.Select(v => v?.ToString() ?? "<missing>")
6);

Prefer Strong Typing When Possible

If the data is already strongly typed, do not convert it to object[] unless you have to. A typed collection plus projection is more readable and avoids unnecessary boxing or vague intent.

string.Join works well with IEnumerable<string>, so a common pattern is:

• keep the collection typed
• map each item to the desired text
• join the resulting strings

That expresses the output rule clearly to the next reader.

Overload Choice Still Matters

Even though string.Join can accept object collections, the best overload is still the one that matches your real data shape. If you already have strings, join strings directly. If you have objects, project them first when the output format is part of business logic rather than a generic display form.

Common Pitfalls

• Assuming string.Join only works with string[].
• Relying on ToString() for custom objects that do not override it meaningfully.
• Forgetting that null values become empty strings by default.
• Converting everything to object[] when a typed collection plus Select would be clearer.
• Hiding important formatting rules inside an accidental ToString() result.

Summary

• 'string.Join can join object arrays, not only string arrays.'
• For simple built-in values, default ToString() behavior is often enough.
• For custom objects, explicit projection with Select is usually the clearer option.
• Handle null values intentionally before joining.
• Prefer typed collections and explicit formatting rules over broad object-based joining.