.NET
AssemblyInformationalVersion
C#
software development
versioning

Get the .NET assembly's AssemblyInformationalVersion value?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

AssemblyInformationalVersion is the .NET attribute typically used for human-readable or semantic version strings such as 1.4.0-beta+sha1234. To read it at runtime, you usually retrieve the assembly and then ask for AssemblyInformationalVersionAttribute through reflection.

Read the Attribute With Reflection

The core pattern is straightforward:

csharp
1using System;
2using System.Reflection;
3
4Assembly assembly = typeof(Program).Assembly;
5
6AssemblyInformationalVersionAttribute? attribute =
7    assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>();
8
9string version = attribute?.InformationalVersion ?? "unknown";
10Console.WriteLine(version);

This is usually the most direct answer when you want the informational version that was compiled into the currently running assembly.

Using typeof(Program).Assembly is often clearer than Assembly.GetExecutingAssembly() because it makes the target assembly explicit.

Know How It Differs From Other Version Values

Developers often mix up several version-related values in .NET:

  • 'AssemblyVersion'
  • 'AssemblyFileVersion'
  • 'AssemblyInformationalVersion'

AssemblyInformationalVersion is the flexible one. It can contain non-numeric text and semantic-version metadata. That makes it ideal for display in about screens, logs, or diagnostic endpoints.

By contrast, AssemblyVersion is more closely tied to assembly identity and binding behavior. So if you want the version string users or support staff should see, AssemblyInformationalVersion is often the better choice.

Setting the Value

In classic projects, the attribute may appear in AssemblyInfo.cs:

csharp
[assembly: AssemblyInformationalVersion("1.4.0-beta+sha1234")]

In SDK-style projects, it is often supplied through the project file:

xml
1<PropertyGroup>
2  <Version>1.4.0-beta</Version>
3  <InformationalVersion>1.4.0-beta+sha1234</InformationalVersion>
4</PropertyGroup>

The retrieval code is the same either way, because at runtime you are reading the compiled attribute from the assembly metadata.

Reading Another Assembly's Value

You are not limited to the entry assembly. If you want the informational version of a referenced assembly, point reflection at that specific assembly:

csharp
1using System;
2using System.Reflection;
3
4Assembly assembly = typeof(SomeLibraryType).Assembly;
5
6string version =
7    assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()
8            ?.InformationalVersion
9    ?? "unknown";
10
11Console.WriteLine(version);

That is useful in plugin systems or multi-assembly applications where each component has its own release cadence.

Prefer Explicit Fallbacks

Not every assembly is guaranteed to define the attribute. If it is missing, reflection returns null, so code should provide a fallback rather than throwing unexpectedly.

That is why the null-conditional and null-coalescing operators are helpful in this scenario.

If the informational version is important to your diagnostics, consider verifying during build or startup that the attribute exists and contains the format you expect.

A Common Real-World Use Case

One practical use is displaying build information in a diagnostics page or about dialog. AssemblyInformationalVersion is a better fit there than the assembly identity version because it can include prerelease tags, commit identifiers, or CI metadata without affecting binding behavior.

It is also useful in startup logs and support bundles, where a descriptive version string helps operators confirm exactly which build is running without reverse-engineering assembly binding numbers.

In larger applications, be deliberate about which assembly you inspect. Assembly.GetEntryAssembly() refers to the process entry point, while typeof(SomeType).Assembly refers to the library that defines that type. Those are often different in test hosts, ASP.NET applications, and plugin systems.

Common Pitfalls

  • Reading AssemblyVersion when the requirement is really the informational version string.
  • Using GetExecutingAssembly() in a context where the executing assembly is not the one you actually care about.
  • Assuming the attribute always exists and dereferencing it without a null check.
  • Confusing file version, assembly identity version, and informational display version.
  • Forgetting that SDK-style project properties can generate the attribute automatically without an explicit AssemblyInfo.cs entry.

Summary

  • Read AssemblyInformationalVersion by retrieving AssemblyInformationalVersionAttribute from the target assembly.
  • 'typeof(SomeType).Assembly is often the clearest way to pick the assembly you want.'
  • This value is different from AssemblyVersion and is usually better for display and diagnostics.
  • Provide a fallback because the attribute may be missing.
  • The value can come from either assembly attributes or SDK-style project metadata, but runtime retrieval works the same way.

Related reading
Course
Intermediate
27 lessons
14 hours
OOD Fundamentals

Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.