Introduction

Changing the assembly version of a compiled .NET assembly is possible, but it is usually the wrong first choice. In most cases, the correct fix is to change version attributes in source code and rebuild, because assembly metadata participates in binding, signing, and compatibility decisions.

Understand which version you mean

.NET assemblies can carry several version-like values, and they are not interchangeable:

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

AssemblyVersion affects binding identity. AssemblyFileVersion is mostly informational for file properties. AssemblyInformationalVersion is often used for display or package metadata.

A typical source-level definition looks like:

1using System.Reflection;
2
3[assembly: AssemblyVersion("2.3.0.0")]
4[assembly: AssemblyFileVersion("2.3.4.0")]
5[assembly: AssemblyInformationalVersion("2.3.4+build.18")]

If your goal is just to change what Windows Explorer shows, that is different from changing what the CLR uses for reference binding.

Best option: change source and rebuild

If you have the project, update the version attributes or project file and rebuild. In SDK-style projects, versioning is often set in the .csproj:

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net8.0</TargetFramework>
4    <AssemblyVersion>2.3.0.0</AssemblyVersion>
5    <FileVersion>2.3.4.0</FileVersion>
6    <InformationalVersion>2.3.4+release</InformationalVersion>
7  </PropertyGroup>
8</Project>

Then rebuild:

dotnet build -c Release

This keeps the metadata consistent with the IL, resources, and any strong-name signature process you already use.

When you only have the compiled assembly

If source is unavailable, changing metadata in a compiled DLL becomes a binary rewriting task. Tools such as IL disassemblers and assembly editors can do it, but you need to understand the consequences:

• strong-name signatures may become invalid
• file hashes change
• binding expectations may no longer match dependent applications
• vendor support may be voided

For example, after editing and reassembling, a strongly named assembly usually needs re-signing:

sn -R MyLibrary.dll mykey.snk

If you do not control the signing key, you may be unable to restore the original trust model.

Inspect the current version first

Before changing anything, inspect what is currently embedded. PowerShell is a quick option on Windows:

[System.Reflection.AssemblyName]::GetAssemblyName("C:\libs\MyLibrary.dll").Version

You can also inspect file-version metadata:

(Get-Item "C:\libs\MyLibrary.dll").VersionInfo | Format-List *

This distinction matters because many people think they need to change the assembly version when they actually only care about file version.

Binding redirects may solve the real problem

If the issue is application compatibility rather than cosmetic metadata, a binding redirect may be safer than modifying the DLL:

1<configuration>
2  <runtime>
3    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
4      <dependentAssembly>
5        <assemblyIdentity name="MyLibrary" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
6        <bindingRedirect oldVersion="1.0.0.0-2.3.0.0" newVersion="2.3.0.0" />
7      </dependentAssembly>
8    </assemblyBinding>
9  </runtime>
10</configuration>

If your goal is to make an app accept a newer dependency, this may be the correct fix and avoids binary tampering.

Use binary editing only with clear ownership

There are real cases where editing a compiled assembly is acceptable:

• internal legacy software with lost source
• forensic or recovery work
• lab environments
• temporary migration tooling

Even then, document exactly what changed, how the assembly was re-signed, and what was tested afterward. Assembly version changes are not harmless metadata cleanup when strong naming and dependency resolution are involved.

Common Pitfalls

The most common mistake is changing AssemblyFileVersion when the runtime problem is actually tied to AssemblyVersion. Another is editing a compiled assembly without realizing a strong-name signature will become invalid. Developers also sometimes patch a vendor DLL to satisfy one application and then break another application that expects the original identity. Binding redirects are often ignored even when they would solve the problem more safely. Finally, people make version edits without first inspecting the current metadata, so they end up changing the wrong field and misdiagnosing the result.

Summary

• The safest way to change assembly version is to edit source and rebuild.
• 'AssemblyVersion, AssemblyFileVersion, and AssemblyInformationalVersion serve different purposes.'
• Patching a compiled assembly is possible but can break signing and binding behavior.
• Inspect the existing metadata before changing anything.
• Use binding redirects when the real issue is dependency compatibility.
• Treat binary version edits as controlled maintenance, not a routine shortcut.