Introduction

In C#, a namespace is just metadata attached to a type, not a live container that can hand you a list of classes by itself. To get all classes within a namespace, you normally use reflection over one or more assemblies and then filter the discovered types by their Namespace value.

A namespace is not a registry

This point matters because it explains why there is no direct API like "namespace.getClasses()". The runtime knows about loaded assemblies and the types they expose. A namespace is simply a string on those types.

So the problem is really:

1. decide which assemblies you want to inspect
2. enumerate their types
3. keep only classes whose namespace matches your target

If you skip step one and assume the whole application universe is already loaded, you will usually miss types.

Query classes from one assembly

If you only need classes from the currently executing assembly, reflection is straightforward:

1using System;
2using System.Linq;
3using System.Reflection;
4
5class Program
6{
7    static void Main()
8    {
9        string targetNamespace = "MyApp.Services";
10
11        var classes = Assembly.GetExecutingAssembly()
12            .GetTypes()
13            .Where(t => t.IsClass && t.Namespace == targetNamespace)
14            .OrderBy(t => t.Name);
15
16        foreach (var type in classes)
17        {
18            Console.WriteLine(type.FullName);
19        }
20    }
21}

This is the most common answer when the types you care about are known to live in one assembly.

Search all loaded assemblies

If the application spans multiple assemblies, expand the search:

1using System;
2using System.Linq;
3
4class Program
5{
6    static void Main()
7    {
8        string targetNamespace = "MyApp.Plugins";
9
10        var classes = AppDomain.CurrentDomain.GetAssemblies()
11            .SelectMany(a => a.GetTypes())
12            .Where(t => t.IsClass && t.Namespace == targetNamespace)
13            .OrderBy(t => t.FullName);
14
15        foreach (var type in classes)
16        {
17            Console.WriteLine(type.FullName);
18        }
19    }
20}

This works well for plugin systems, dependency injection scans, and diagnostics tooling, as long as the assemblies are already loaded into the current AppDomain.

Exact namespace match versus nested namespaces

Decide whether you want only MyApp.Services or also MyApp.Services.Internal and MyApp.Services.Admin. An exact comparison only returns the first case.

If you want nested namespaces too, filter differently:

1string targetNamespace = "MyApp.Services";
2
3bool InNamespace(Type t) =>
4    t.Namespace == targetNamespace ||
5    (t.Namespace != null && t.Namespace.StartsWith(targetNamespace + "."));

That distinction matters in larger codebases where related classes are often split into namespace hierarchies.

Unloaded assemblies are a separate problem

Reflection only sees assemblies that are available to the process and, in most cases, already loaded. If the classes live in another .dll that has not been loaded yet, you must load that assembly explicitly before scanning it.

var assembly = Assembly.LoadFrom("/path/to/MyLibrary.dll");
var types = assembly.GetTypes()
    .Where(t => t.IsClass && t.Namespace == "MyLibrary.Models");

Be careful with this in production code, because loading assemblies can have side effects and dependency resolution requirements.

Use the result for registration, not just printing

Many real use cases involve more than listing names. You might register discovered handlers in a container, instantiate implementations of an interface, or enforce project conventions in a build step. In those cases, add more filters such as:

• '!t.IsAbstract'
• 'typeof(IMyService).IsAssignableFrom(t)'
• 't.GetCustomAttributes(...)'

Namespace filtering is usually only the first step.

Common Pitfalls

• Expecting namespaces themselves to expose a class enumeration API.
• Searching only the executing assembly when the target classes live elsewhere.
• Forgetting to exclude abstract classes or unrelated helper types.
• Using exact namespace equality when nested namespaces should be included.
• Calling GetTypes() on assemblies that may fail to load dependent types without handling exceptions.

Summary

• In C#, you get classes within a namespace by reflecting over assemblies and filtering type metadata.
• 'Assembly.GetExecutingAssembly().GetTypes() is enough for single-assembly cases.'
• 'AppDomain.CurrentDomain.GetAssemblies() is useful when classes may be spread across loaded assemblies.'
• Decide explicitly whether nested namespaces should count as matches.
• If the assembly is not loaded, load it first or scan it through a separate assembly-loading workflow.