Introduction

In .NET, “assembly version” can mean several different version values, and the phrase “executing assembly” has a specific runtime meaning. If you want a reliable answer in code, you need to be clear about whether you want the assembly version, file version, informational version, or the version of the entry application.

Get the Version of the Executing Assembly

If you literally want the version of the assembly that contains the currently running code, Assembly.GetExecutingAssembly() is the direct API:

1using System;
2using System.Reflection;
3
4Assembly assembly = Assembly.GetExecutingAssembly();
5Version? version = assembly.GetName().Version;
6
7Console.WriteLine(version?.ToString() ?? "unknown");

GetName().Version returns the assembly version, which is the version the CLR uses for binding and identity. In SDK-style projects, that value often comes from your project file or build metadata.

Understand the Different Version Values

Developers often expect one “version,” but .NET commonly exposes at least three:

• Assembly version
• File version
• Informational version

The assembly version is used by the runtime. The file version is mainly for file metadata and Windows tooling. The informational version is often the most human-friendly string and may include pre-release labels or source-control details.

Here is how to read the informational version:

1using System;
2using System.Reflection;
3
4Assembly assembly = Assembly.GetExecutingAssembly();
5string infoVersion =
6    assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion
7    ?? "unknown";
8
9Console.WriteLine(infoVersion);

If you need the file version instead:

1using System.Diagnostics;
2using System.Reflection;
3
4Assembly assembly = Assembly.GetExecutingAssembly();
5string? fileVersion = FileVersionInfo
6    .GetVersionInfo(assembly.Location)
7    .FileVersion;
8
9Console.WriteLine(fileVersion ?? "unknown");

Set Versions in the Project File

In modern .NET projects, these values are often defined in the project file:

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net8.0</TargetFramework>
4    <Version>1.4.0</Version>
5    <AssemblyVersion>1.4.0.0</AssemblyVersion>
6    <FileVersion>1.4.0.0</FileVersion>
7    <InformationalVersion>1.4.0+build.20250923</InformationalVersion>
8  </PropertyGroup>
9</Project>

If you do not set them explicitly, the SDK may generate some of them for you. That is convenient, but it also means you should know which property your application is supposed to display.

Executing Assembly Versus Entry Assembly

This is where many bugs appear. Assembly.GetExecutingAssembly() returns the assembly that contains the currently executing code. That may be a class library, test project, plugin, or background worker helper, not the main app executable.

If you want the version of the application entry point instead, use Assembly.GetEntryAssembly():

1Assembly? entryAssembly = Assembly.GetEntryAssembly();
2Version? entryVersion = entryAssembly?.GetName().Version;
3
4Console.WriteLine(entryVersion?.ToString() ?? "no entry assembly");

This difference matters in ASP.NET Core, unit tests, plugin systems, and shared libraries. A helper library that logs its own version with GetExecutingAssembly() may not be giving you the version you intended to show to users.

A Practical Helper Method

If your application wants a display version for an “About” screen, a helper that prefers the informational version is often the most useful:

1using System.Reflection;
2
3public static class VersionHelper
4{
5    public static string GetDisplayVersion()
6    {
7        Assembly assembly = Assembly.GetEntryAssembly() ?? Assembly.GetExecutingAssembly();
8
9        return assembly
10            .GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion
11            ?? assembly.GetName().Version?.ToString()
12            ?? "unknown";
13    }
14}

This keeps the behavior sensible whether the code runs in the main app or in a library context.

Common Pitfalls

The biggest pitfall is assuming GetExecutingAssembly() always returns the application executable. It does not. It returns the assembly containing the code that is executing right now.

Another common mistake is using assembly version when the product team really wants file version or informational version. Those values often differ on purpose.

It is also easy to forget that Assembly.GetEntryAssembly() can return null in some hosting scenarios. If you use it, keep a fallback.

Finally, assembly.Location may behave differently in some publishing models, so file-version retrieval is not always the best source for an in-app display string. For user-facing version text, informational version is usually a better fit.

Summary

• Use Assembly.GetExecutingAssembly().GetName().Version for the literal executing assembly version.
• Use Assembly.GetEntryAssembly() if you actually want the host application version.
• Distinguish assembly version, file version, and informational version before choosing an API.
• Read AssemblyInformationalVersionAttribute when you need a display-friendly version string.
• Prefer a small helper method if your code can run from both executables and libraries.