This project is read-only.

Assembly version is not updated when releasing artifact

Jun 6, 2010 at 2:08 PM
Edited Jun 6, 2010 at 2:56 PM

Hi All,

I have a question concerning AssemblyVersion metadata parameter. Why is it not updated (as AssemblyFileVersion) during execution of compile phase? I checked-out in the code base - it is only latter one gets updated but not the first one. But in this case AssemblyVersion stays (or in some cases forever in which case Assembly signing does not make any sense because for .NET framework two files with the same AssemblyVersion (even with different AssemblyFileVersion) are totally the same. May be I missed something?

Thanks for the help


Jun 11, 2010 at 4:08 AM

I can't think of a reason off the top of my head - perhaps it's a bug?

Jun 11, 2010 at 6:35 AM

I found the problem with it - in maven compile plugin ( If there is AssemblyInfo.cs file, it updates only AssemblyFileVersion (which is visible in dll-file properties, but not taken into account when resolving assembly version by CLR). It's AssemblyVersion that is taken into account by CLR. Moreover if in AssemblyInfo.cs there was not any AssemblyFileVersion attribute at all, plugin throws IndexOutOfRangeException (because it uses substring-based replace and indexOf). I wrote a patch for this file addressing both issues (using Regular Expressions). It works good in my environment. Today I will upload it here.

Jun 11, 2010 at 11:27 AM

Uploaded corresponding patch

Jun 12, 2010 at 8:55 AM

Hi artemfedorenko,

Did you create a corresponding issue for this in the issue tracker? You can also upload the patch there, and we would be glad to test it out.

Thanks for the patch :D





Nov 23, 2010 at 4:08 PM

I added a comment to the issue tracker but I thought maybe I should add this here.


When using this patch, I am attempting update the version number dynamically from a build box. We are setting the enviroment variable for a value, and then runs mvn clean package command. The problem I am receiving is that after it is run, I get the previous build number, and the assembly value is updated.

Steps to reproduce:


(returns 5)
mvn clean package

Builds a dll into target directory with file version
Updates Assembly.cs so that AssemblyVersion("")

mvn clean package

Builds a dll into target directory with file version
Updates Assembly.cs so that AssemblyVersion("")

(returns 6)
mvn clean package

Builds a dll into target directory with file version
Updates Assembly.cs so that AssemblyVersion("")

After reviewing the target directory, my team and I have found that the folder build-sources assemblyinfo.cs file is not being updated. Rather it is updating the project assembly file (referenced in Visual Studio), but compiling off of the build-sources. This does not seem to me to be correct functionality, so I am confused if this is really fixed at all.

I've looked around trying for find further documentation on this, but I can't see what I am doing incorrectly. Is there additional steps I am required to follow?

Nov 23, 2010 at 4:29 PM
Try to use mvn clean install command instead. That should work.

Nov 23, 2010 at 5:39 PM

Still no dice.

The install command does the same issue as the package or even compile does.

Rather then update the version in the build-sources, its updating it in the projects assembly. Also, the dll file being produced still has 0.0.0 as its version rather then the I expect (or even




Nov 24, 2010 at 12:13 AM
Edited Nov 24, 2010 at 12:38 AM

It should also be pointed out that using a syntax like <version>${buildVersion}</version> within the pom file does not work correctly using the following mvn command.

mvn clean install -DbuildVersion=

The build will complete "successfully" and the DLL will deploy to the local repo as MyLibrary\\MyLibrary- but the assembly is not updated correctly.  

Instead an error is thrown in the AbstractCompilerMojo.

View the error log here

I have also created an new issue in the Issue Tracker which can be found here (

Nov 24, 2010 at 12:29 AM

This is a known issue that we are slowly working to resolve by removing the customized code we inherited in NPanday and returning to Maven-based code.

Also note that we are phasing out the Codeplex project - I recommend posting your questions & issues to the new lists & JIRA at Apache.

Nov 24, 2010 at 12:48 AM

Thanks Brett,

I believe raposoc's problem stems from the fact that the AbstractCompilerMojo class updates the current working directory's assembly file instead of the version that has already been copied to target\build-sources directory.

Is it possible to have the main file updated before the sources are copied to the target directory?

Modifying the updateAssemblyInfoVersion method to grab the target\build-sources version seems to fix the issue.

String assemblyInfoFile = currentWorkingDir+File.separator+"target"+File.separator+"build-sources"+File.separator+"Properties"+File.separator+"AssemblyInfo.cs"; 

Perhaps both the main file and the target version could be updated?