Introduction

In C#, partial class declarations merge only when they describe the same type in the same namespace and assembly. If the namespaces differ, even by one segment, the compiler creates separate types, which is why partial classes in different namespaces do not combine.

How Partial Type Merging Actually Works

A partial type is not a fuzzy grouping by file name. It is a compile-time merge of declarations that must match on the identity of the type.

For a successful merge, the declarations must share:

• the same namespace
• the same class name
• the same generic arity, if generic
• the same assembly output

This works:

1namespace App.Domain
2{
3    public partial class Customer
4    {
5        public int Id { get; set; }
6    }
7}
8
9namespace App.Domain
10{
11    public partial class Customer
12    {
13        public string Name { get; set; } = string.Empty;
14    }
15}

The compiler combines those into one Customer type.

Different Namespace Means Different Type

If the namespace changes, the declarations no longer describe the same type.

1namespace App.Domain.V1
2{
3    public partial class Customer
4    {
5        public int Id { get; set; }
6    }
7}
8
9namespace App.Domain.V2
10{
11    public partial class Customer
12    {
13        public string Name { get; set; } = string.Empty;
14    }
15}

These are two unrelated classes. The shared type name does not matter because the fully qualified names are different.

That is the core answer: partial classes do not merge across namespaces.

Why Teams Run Into This

This issue usually appears during refactors or generated-code workflows rather than in hand-written examples.

Common causes include:

• renaming the namespace in only one partial file
• generated code still using the old namespace
• moving one partial file into another project or assembly
• mixing file-scoped and block-scoped namespace edits carelessly

The symptoms can be confusing. One file appears to "lose" members from the other partial declaration, or reflection shows fewer properties than expected.

Generated Code Makes This More Likely

Partial classes are especially common when a generated file and a manual file extend the same type. That is a good pattern, but only if the namespace is kept perfectly aligned.

For example, a generator may output:

1namespace App.Generated;
2
3public partial class Invoice
4{
5    public int Id { get; set; }
6}

while the manual extension file says:

1namespace App.Domain;
2
3public partial class Invoice
4{
5    public decimal Total { get; set; }
6}

Those do not merge. The fix is not about the partial keyword. The fix is to make both declarations identify the same type.

Assembly Boundaries Matter Too

Even with matching namespace and class name, partial declarations do not merge across assemblies. If one partial file is compiled into one project and another file into a different project, you still get separate types.

That matters in solutions where shared generated code gets moved into a different library. From the developer's point of view the code still "looks partial," but the compiler sees separate compilation units producing different assemblies.

Verify the Result When Debugging

If you suspect a namespace or assembly mismatch, inspect the compiled type directly.

1using System;
2using System.Reflection;
3
4namespace App.Domain
5{
6    public partial class Customer
7    {
8        public int Id { get; set; }
9    }
10
11    public partial class Customer
12    {
13        public string Name { get; set; } = string.Empty;
14    }
15
16    public static class Program
17    {
18        public static void Main()
19        {
20            Type t = typeof(Customer);
21            Console.WriteLine(t.FullName);
22
23            foreach (PropertyInfo property in t.GetProperties())
24            {
25                Console.WriteLine(property.Name);
26            }
27        }
28    }
29}

If expected members are missing, verify namespace and project boundaries first.

Common Pitfalls

The most common mistake is assuming that identical file names or identical class names are enough for partial merging. They are not. Type identity includes namespace and assembly.

Another issue is half-finished namespace refactors where one partial file moves and the other does not. Generated code makes this easier to miss because developers may not review the generated namespace carefully.

Finally, partial classes are useful, but they should not be used as a substitute for better decomposition. If a type is split across many human-authored partial files, maintenance often gets worse instead of better.

Summary

• Partial classes merge only when namespace, type name, and assembly all match.
• Different namespaces create different types, even with the same class name.
• Generated code and refactors are the most common sources of namespace mismatch.
• Matching partial keywords alone do not guarantee a merge.
• When debugging missing members, check namespace and assembly identity before anything else.