How to Get Assembly Version in C#

Learn how to retrieve the assembly version in C# across .NET Framework and .NET Core using reflection, FileVersionInfo, and informational attributes, with clear, runnable code examples and debugging tips.

Disasembl Team

March 16, 2026·5 min read

Disassembly PC Assembly Assembly Language

Assembly Version Lookups - Disasembl — Photo by roketpikvia Pixabay

Quick AnswerDefinition

To retrieve the assembly version in C#, use reflection to query the executing assembly’s name and version. Common pattern: var v = Assembly.GetExecutingAssembly().GetName().Version; Console.WriteLine(v); This returns the Version object (Major.Minor.Build.Revision). For more detail, consider InformationalVersion or FileVersion for release labeling. Format it as a string with v?.ToString() or break out Major/Minor/Build/Revisions as needed, and remember that different project types (netframework vs netcore) may expose different metadata sources.

Understanding Assembly Versioning in .NET

When you explore how to get assembly version in c#, you must distinguish between three commonly used version attributes: AssemblyVersion, FileVersion, and InformationalVersion. AssemblyVersion is used by the CLR for binding, FileVersion is a Windows file property, and InformationalVersion is a human-facing string for release labeling. The runtime can expose these values through reflection or by reading file metadata. In this section, we explore practical patterns for accessing these versions in C# applications.

using System;
using System.Reflection;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        // Running assembly version
        var av = Assembly.GetExecutingAssembly().GetName().Version;
        Console.WriteLine("AssemblyVersion: {0}", av?.ToString());

        // Optional: read the assembly's full location file version
        var location = Assembly.GetExecutingAssembly().Location;
        var fvi = FileVersionInfo.GetVersionInfo(location);
        Console.WriteLine("FileVersion: {0}", fvi.FileVersion);

        // Optional: informational version attribute
        var info = Assembly.GetExecutingAssembly()
                          .GetCustomAttribute<AssemblyInformationalVersionAttribute>()
                          ?.InformationalVersion;
        Console.WriteLine("InformationalVersion: {0}", info);
    }
}

Notes: The three version types serve different purposes. AssemblyVersion affects binding redirects and compatibility; FileVersion is primarily for display in file properties; InformationalVersion provides human-readable tags (e.g., 1.0.0-preview).

wordCountSection2PlaceholderForCountShouldBeKept

Accessing Version via AssemblyName and Strongly Named Assemblies

A common approach when you want to read the version at runtime is to access the AssemblyName object. This yields the Version object, which you can format or deconstruct. If you use strongly named assemblies, the Version value will reflect the AssemblyVersion attribute embedded at build time. You can also query Major, Minor, Build, and Revision components individually for precise logic branches in your application.

using System;
using System.Reflection;

class Program
{
    static void Main()
    {
        var name = Assembly.GetExecutingAssembly().GetName();
        Console.WriteLine("Full Version: {0}", name.Version?.ToString());
        Console.WriteLine("Major.Minor: {0}.{1}", name.Version?.Major, name.Version?.Minor);
    }
}

This pattern is robust across .NET Framework and .NET Core alike, as long as the assembly contains a version.

Reading InformationalVersion and FileVersion

For release tagging and build metadata, you often rely on InformationalVersion and FileVersion. The informational version can be set in the project file or via AssemblyInformationalVersionAttribute. The FileVersion is embedded in the file’s properties and not used by the CLR for binding, but it’s invaluable for release notes and troubleshooting. Reading these values via reflection or FileVersionInfo provides a complete picture of the versioning strategy for an app.

using System;
using System.Reflection;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        var av = typeof(Program).Assembly.GetName().Version?.ToString();
        var info = typeof(Program).Assembly
                    .GetCustomAttribute<AssemblyInformationalVersionAttribute>()
                    ?.InformationalVersion;
        var file = FileVersionInfo.GetVersionInfo(typeof(Program).Assembly.Location).FileVersion;

        Console.WriteLine("AssemblyVersion: {0}", av);
        Console.WriteLine("InformationalVersion: {0}", info);
        Console.WriteLine("FileVersion: {0}", file);
    }
}

Be mindful that not every project sets all three; always provide fallbacks in code.

Practical Console App: Printing Versions at Runtime

The most direct way to validate your approach is to build a tiny console app that prints the various versions at runtime. This example shows how to compile and run a minimal app that prints AssemblyVersion, InformationalVersion, and FileVersion. You can extend this pattern to log versions on startup and in telemetry.

using System;
using System.Reflection;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        var a = Assembly.GetExecutingAssembly().GetName().Version?.ToString();
        var info = Assembly.GetExecutingAssembly()
                    .GetCustomAttribute<AssemblyInformationalVersionAttribute>()
                    ?.InformationalVersion;
        var location = Assembly.GetExecutingAssembly().Location;
        var file = FileVersionInfo.GetVersionInfo(location).FileVersion;
        Console.WriteLine($"AssemblyVersion={a} ", a);
        Console.WriteLine($"InformationalVersion={info}", info);
        Console.WriteLine($"FileVersion={file}", file);
    }
}

To run:

dotnet build
dotnet run --project <YourProjectName>

This yields concrete values you can use for diagnostics and compliance checks.

Variations by Framework and Runtime

Versions can behave slightly differently across .NET Framework, .NET Core, and .NET 5+/6/7+. The AssemblyVersion attribute has historically influenced binding behavior in full framework apps, while in newer runtimes, binding is more flexible. Regardless of runtime, GetName().Version retrieves the compiled AssemblyVersion. If you rely on informational labels, ensure your csproj sets <InformationalVersion> and that your deployment pipeline injects consistent metadata at build time.

using System;
using System.Reflection;

class Program
{
    static void Main()
    {
        var v = typeof(Program).Assembly.GetName().Version?.ToString();
        Console.WriteLine($"Runtime Version: {v}");
    }
}

For multi-target projects, you may want to surface the correct version depending on the target framework; tests should confirm behavior on each target.

Deployment considerations and Logging

When exposing version data to users or logs, consider including all three sources: AssemblyVersion for binding stability, FileVersion for build history, and InformationalVersion for release labels. In production environments, you might publish a single composite string like "1.2.3.4 (info: 1.2.3.4-prod)". Always ensure your logging and telemetry pipelines scrub sensitive build details if necessary and format versions consistently across services.

using System;
using System.Reflection;

class Program
{
    static void Main()
{
        var name = Assembly.GetExecutingAssembly().GetName();
        var v = name.Version?.ToString();
        var info = Assembly.GetExecutingAssembly()
                    .GetCustomAttribute<AssemblyInformationalVersionAttribute>()
                    ?.InformationalVersion;
        Console.WriteLine($"Version={v} | Info={info}");
    }
}

Integrate these values into your logging framework for traceability.

Common Pitfalls and How to Avoid Them

Relying solely on AssemblyVersion for user-facing messages can cause binding surprises if the value changes during patch releases. Always include InformationalVersion for release labeling.
FileVersion is not used by the CLR for binding; do not depend on it for runtime decisions.
If Version is null, ensure you have a fallback path to read InformationalVersion or FileVersion.
Different project templates may omit certain attributes unless explicitly set in the csproj. Always verify the emitted metadata after build.

Debugging and Validation Techniques

To validate your approach, build a small test project and print every available version value. Use assertions in unit tests to ensure that InformationalVersion and FileVersion align with your release metadata. A good practice is to version-control the expected values and verify at CI/CD time. This helps ensure that the values you surface in logs and UI match the deployed build.

Summary

Reading assembly version information in C# involves understanding the distinctions among AssemblyVersion, FileVersion, and InformationalVersion, and applying reflection to retrieve them. Use GetName().Version for runtime binding checks, informational attributes for release labeling, and FileVersion for Windows-level metadata. This approach works across .NET Framework and .NET Core, with minor adjustments depending on how your project emits metadata.

Steps

Estimated time: 60-90 minutes

1
Create a sample project
Generate a small console app to experiment with version querying. Use dotnet new console -n AssemblyVersionDemo to scaffold the project, then open the folder in your editor.
Tip: Name the project clearly to reflect its purpose (e.g., AssemblyVersionDemo).
2
Add using directives
In Program.cs, add using System.Reflection; to access reflection APIs needed to read version data at runtime.
Tip: Keep using statements organized to avoid namespace conflicts.
3
Read AssemblyVersion at runtime
Retrieve the version via Assembly.GetExecutingAssembly().GetName().Version and print it. This demonstrates the core pattern.
Tip: Handle nulls with ?.ToString() to avoid null reference exceptions.
4
Read additional metadata
Read InformationalVersion via AssemblyInformationalVersionAttribute and FileVersion using FileVersionInfo.GetVersionInfo.
Tip: InformationalVersion often carries release tags; FileVersion tracks build numbers.
5
Test across frameworks
Build and run on both .NET Framework and .NET Core targets to confirm behavior.
Tip: If your project targets multiple frameworks, ensure metadata is emitted for each target.
6
Integrate into logging
Extend your startup code to log these version values for traceability.
Tip: Avoid exposing internal build numbers in public error messages; use a sanitized label.

Pro Tip: Use InformationalVersion for release labels; keep AssemblyVersion stable for binding.

Warning: Version values can be null in unusual deployment scenarios; always provide fallbacks.

Note: FileVersion is property metadata; do not rely on it for runtime decisions.

Pro Tip: Document versioning strategy in your project guidelines to ensure consistency.

Prerequisites

Required

.NET SDK 6.0+ (or latest LTS)↗
Required
C# knowledge (reflection basics)
Required
A code editor (e.g., Visual Studio or VS Code)↗
Required
A sample project to experiment with (console app)
Required

Optional

Familiarity with csproj-based versioning
Optional

Commands

Action	Command
Check installed .NET SDK versionVerifies you have a valid SDK before building.	—
Create a new console projectBase project to test version retrieval.	`dotnet new console -n AssemblyVersionDemo`
Build the projectCompiles the project and generates binaries.	`dotnet build AssemblyVersionDemo`
Run the projectExecutes code to print version data.	`dotnet run --project AssemblyVersionDemo`
Print the version in codeQuick verification in script form (optional).	`dotnet script -e 'using System.Reflection; Console.WriteLine(Assembly.GetExecutingAssembly().GetName().Version?.ToString() ?? "unknown");'`

Got Questions?

What is the difference between AssemblyVersion and FileVersion?

AssemblyVersion influences binding and compatibility at runtime, while FileVersion is a Windows file property used for display purposes. InformationalVersion provides a human-readable label for releases. Use the trio to convey binding behavior and release metadata.

How do I read a version that might be null at runtime?

Check for nulls when retrieving Version from GetName().Version and provide fallbacks to FileVersion or InformationalVersion as needed. Using the null-conditional operator helps avoid exceptions.

Can I set the version at build time in the project file?

Yes. You can set Version or InformationalVersion in the csproj using MSBuild properties, for example <Version>1.2.3</Version> or <InformationalVersion>1.2.3-beta</InformationalVersion>. This ensures consistent metadata across builds.

Where should version attributes be placed?

Version attributes can be placed in AssemblyInfo.cs or directly in the csproj using MSBuild properties. In modern projects, project file configuration is preferred for simplicity and consistency.

What to Remember

Read AssemblyVersion for binding decisions
InformationalVersion is ideal for release tags
FileVersion serves as file metadata for displays

← More in Tools & Techniques

Understanding Assembly Versioning in .NET

Accessing Version via AssemblyName and Strongly Named Assemblies

Reading InformationalVersion and FileVersion

Practical Console App: Printing Versions at Runtime

Variations by Framework and Runtime

Deployment considerations and Logging

Common Pitfalls and How to Avoid Them

Debugging and Validation Techniques

Summary

Steps

Create a sample project

Add using directives

Read AssemblyVersion at runtime

Read additional metadata

Test across frameworks

Integrate into logging

Prerequisites

Commands

Got Questions?

What to Remember

Related Articles