none
Difference Between AssemblyVersion and FileVersion and ProductVersion in .Net Versioning philosophy! RRS feed

  • Question

  • Hi to all dear .net developer,

    i'm read a lot about this question but everyone says Something, for this reason i'm soooooo confused now!.

    please explain about question with real world sample (for example: Visual Studio, photoshop, office and so on)

    i'm know some things about this question but it is not structured in my brain!

    Until now i know that:

    1- only Assembly version is checked at run time by CLR and two other versions isn't checked by .net CLR.

    2- File Version and product version is used only by human and not used by .net Architecture at run time! but i don't know what is the difference and also when we have to use file version or product Version (or both)? please explain with real world samples :)

    3- i know about major and minor part of versioning String in .net but i don't know about difference between build and revision and what is meaning? (when and where we have to use it and how). please suppose we're not work in team and we don't have build server or source control.

    4- Why Microsoft does not use the Semantic Versioning, what is difference between this scheme and Microsoft .net versioning? (which is better? if semantic then how use it in .net)

    please explain about this question easy and with Real World sample or Understandable Example near Reality!

    thanks for your time!


    • Moved by Caillen Thursday, September 4, 2014 7:00 AM
    Wednesday, September 3, 2014 2:52 PM

Answers

  • 1) AssemblyVersion is a .NET specific thing and is used by the CLR when trying to find assemblies by version #. 

    2) FileVersion and ProductVersion are native version numbers used by Windows proper.  The ProductVersion is generally used by applications as their product version # when displaying About boxes, uninstall information, etc.  In general all files deployed as part of a product will have the same product version. 

    FileVersion is used to version an individual file.  This is useful when you have hotfixes as the ProductVersion doesn't change but the impacted files will.  Installers tend to use the FileVersion value when determining whether a file needs to be replaced or not.

    3) Build and revision numbers are completely up to you to decide how to use.  One common approach is that the build version changes every day.  A common value for this is the Julian date.  The revision number starts at 1 each day.  Each time you build during the day the revision is incremented by 1.  Hence if you see a version of 1.2.14001.3 you'd know that this is version 1.2 of the product, build on 1/1/2014 and this is the 3rd build of the day.  In general the version # is only updated when you do non-dev builds (aka automated builds or deployment builds).  For general dev work it is not necessary to change the version info.

    4) You also have string versions of the native versioning which is used when displaying localized content (such as from Windows Explorer).  The string versions are where semantic versioning is implemented.  MS supports semantic versioning. They have been using it for years in CTPs, betas and RCs.  Windows is the one you're most likely to see but some of the server products use it as well.  Semantic versioning tends to only be used for non-RTM builds with some exceptions. 

    In general the ProductVersion is set to something like 1.2.0.0 for the 1.2 version of a product.  The AssemblyVersion and FileVersion are set to the unique version for the build (1.2.build.rev).  However if you're building stuff that is strongly named then the AssemblyVersion tends to be the ProductVersion to avoid needless issues when referencing the assembly elsewhere.  InformationalVersion (which is a string representation) tends to be where the semantic versioning is used and is generally the product version with semantic info added (if any).  The remaining localized version strings follow the ProductVersion/FileVersion values.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    Wednesday, September 3, 2014 5:10 PM
    Moderator
  • You can do just about anything you want but you should really consider how to version your files so it is easy to identify which files go together with what build. This makes it easier when someone says they found a bug you can get the version # and know what code they were running (and if it is the latest).

    The process that I've been following for years is as follows.  Note that when I refer to a release I'm talking about a public release (aka you publish your software to the world).  Builds are the daily (or manual) builds of your code.

    1. Major version - Increment only when there are major functional changes to the product, breaking compatibility changes and/or I want to support this version along with previous versions on the same machine.  This is incremented only once in a release, if at all.
    2. Minor version - Increment this for any releases where there are no major functional changes, no breaking compatibility changes and I don't want to support side-by-side installation with previous versions of the same major version (aka 1.2 and 1.3 cannot be installed at the same time).  This is generally incremented at the start of a new release cycle and stays the same until the next release cycle.  This value is generally reset to 0 when the Major version increments.  Service packs/hotfixes to existing versions generally doesn't change the Minor version #.
    3. Build version - Use the Julian date for this (YYDOY).  That means it changes every day but it provides a quick indicator of how the build relates to other builds and when the build occurred.  For example 14240 is older than 14250 by 10 days.  You can technically use any value you want but Julian works well.
    4. Revision - Indicates the # of builds for the day.  It starts at 1 and goes up by 1 each time you build during the same day.  It resets to 1 on the next day.

    If you're using automated builds like TFS then there are TFS extensions that can handle all this for you.  In our environment we have a build template that allows us to specify the major/minor version for a product as part of the build definition.  The build number is calculated by the build and the revision number comes from TFS.  We have a task that calculates the version info and updates all the projects in the solution to use that version.

    Product Version - All files should share the same product version and it is generally Major.Minor.0.0.  Hence the product version is stable for the entire release cycle and for any hotfixes for release cycle.

    File Version - This follows the pattern I mentioned earlier around Major.Minor.Build.Rev.  Every time you build all files get a new version but they are all tied by the same PV so you know they are related.

    Assembly Version - This one should generally be the FV as well.  But a special case exists for strongly named assemblies that are going to be referenced by version.  In that case the assembly version may be the PV.  Changing the version of a strongly named assembly will force clients to have to update so you don't want it changing that often.

    Informationl Version - This should probably be the PV but you can add any semantic info you want.  For example during early builds you might put Beta in the version.  For a release candidate you might switch to RC.  It's up to you.

    MSDN has an article on how assembly versioning is used by the CLR.  Here's an article on how the FV impacts installation.

    Thursday, September 4, 2014 1:59 PM
    Moderator

All replies

  • 1) AssemblyVersion is a .NET specific thing and is used by the CLR when trying to find assemblies by version #. 

    2) FileVersion and ProductVersion are native version numbers used by Windows proper.  The ProductVersion is generally used by applications as their product version # when displaying About boxes, uninstall information, etc.  In general all files deployed as part of a product will have the same product version. 

    FileVersion is used to version an individual file.  This is useful when you have hotfixes as the ProductVersion doesn't change but the impacted files will.  Installers tend to use the FileVersion value when determining whether a file needs to be replaced or not.

    3) Build and revision numbers are completely up to you to decide how to use.  One common approach is that the build version changes every day.  A common value for this is the Julian date.  The revision number starts at 1 each day.  Each time you build during the day the revision is incremented by 1.  Hence if you see a version of 1.2.14001.3 you'd know that this is version 1.2 of the product, build on 1/1/2014 and this is the 3rd build of the day.  In general the version # is only updated when you do non-dev builds (aka automated builds or deployment builds).  For general dev work it is not necessary to change the version info.

    4) You also have string versions of the native versioning which is used when displaying localized content (such as from Windows Explorer).  The string versions are where semantic versioning is implemented.  MS supports semantic versioning. They have been using it for years in CTPs, betas and RCs.  Windows is the one you're most likely to see but some of the server products use it as well.  Semantic versioning tends to only be used for non-RTM builds with some exceptions. 

    In general the ProductVersion is set to something like 1.2.0.0 for the 1.2 version of a product.  The AssemblyVersion and FileVersion are set to the unique version for the build (1.2.build.rev).  However if you're building stuff that is strongly named then the AssemblyVersion tends to be the ProductVersion to avoid needless issues when referencing the assembly elsewhere.  InformationalVersion (which is a string representation) tends to be where the semantic versioning is used and is generally the product version with semantic info added (if any).  The remaining localized version strings follow the ProductVersion/FileVersion values.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    Wednesday, September 3, 2014 5:10 PM
    Moderator
  • thank you Michael Taylor,

    Just to make sure I understand correctly:

    i suppose i created a program MyApp 1.0.0.0 today.

    MyApp has a lot of files and class library(DLL) with specific versions (for the first public release all dll's file versions is 1.0.0.0 same as product version generally if i get it correctly :) ), Hence for the first release:

    MyApp product version is: 1.0.0.0

    MyApp (itself and other dll and files) Assemblyversion and FileVersion is:1.0.0.0 (same as product version)

    after two week and after bugs reporting, I/we decide to slove problems, for example the big bug exist in myDll of MyApp then based on .net versioning and semantic versioning i have to increase major part for example myDll's version will become : 2.0.0.0 (but product version is same before release)

    i have some questions here:

    in this here about myDll do i change assemblyVersion or FileVersion or both? (why?)

    and other two question:

    Question 1) when we have to change product version?

    1- when a lot of files and dll are changed in our product even without any visual change? in other words Intangible for users?

    2- when exist tangible change in our product even this change can only related to one core dll for example comprehensive changes in GUI without any performance or algorithmic change or not exist any other features? 

    Question 2) can we have increase major or Specially minor part, multi numbers for example 1.2.45.2 --> 1.8.12.4 or 3.4.0.0

    if yes (when? and In what circumstances? What does the standard says?)

    thanks/.

    Thursday, September 4, 2014 5:32 AM
  • You can do just about anything you want but you should really consider how to version your files so it is easy to identify which files go together with what build. This makes it easier when someone says they found a bug you can get the version # and know what code they were running (and if it is the latest).

    The process that I've been following for years is as follows.  Note that when I refer to a release I'm talking about a public release (aka you publish your software to the world).  Builds are the daily (or manual) builds of your code.

    1. Major version - Increment only when there are major functional changes to the product, breaking compatibility changes and/or I want to support this version along with previous versions on the same machine.  This is incremented only once in a release, if at all.
    2. Minor version - Increment this for any releases where there are no major functional changes, no breaking compatibility changes and I don't want to support side-by-side installation with previous versions of the same major version (aka 1.2 and 1.3 cannot be installed at the same time).  This is generally incremented at the start of a new release cycle and stays the same until the next release cycle.  This value is generally reset to 0 when the Major version increments.  Service packs/hotfixes to existing versions generally doesn't change the Minor version #.
    3. Build version - Use the Julian date for this (YYDOY).  That means it changes every day but it provides a quick indicator of how the build relates to other builds and when the build occurred.  For example 14240 is older than 14250 by 10 days.  You can technically use any value you want but Julian works well.
    4. Revision - Indicates the # of builds for the day.  It starts at 1 and goes up by 1 each time you build during the same day.  It resets to 1 on the next day.

    If you're using automated builds like TFS then there are TFS extensions that can handle all this for you.  In our environment we have a build template that allows us to specify the major/minor version for a product as part of the build definition.  The build number is calculated by the build and the revision number comes from TFS.  We have a task that calculates the version info and updates all the projects in the solution to use that version.

    Product Version - All files should share the same product version and it is generally Major.Minor.0.0.  Hence the product version is stable for the entire release cycle and for any hotfixes for release cycle.

    File Version - This follows the pattern I mentioned earlier around Major.Minor.Build.Rev.  Every time you build all files get a new version but they are all tied by the same PV so you know they are related.

    Assembly Version - This one should generally be the FV as well.  But a special case exists for strongly named assemblies that are going to be referenced by version.  In that case the assembly version may be the PV.  Changing the version of a strongly named assembly will force clients to have to update so you don't want it changing that often.

    Informationl Version - This should probably be the PV but you can add any semantic info you want.  For example during early builds you might put Beta in the version.  For a release candidate you might switch to RC.  It's up to you.

    MSDN has an article on how assembly versioning is used by the CLR.  Here's an article on how the FV impacts installation.

    Thursday, September 4, 2014 1:59 PM
    Moderator
  • thanks but in bellow picture All files related to one release of product but exist difference at major.minor part in it's ProductVersion! 

    What is your interpretation about this?


    Thursday, September 4, 2014 4:27 PM
  • I cannot answer how Adobe does versioning but I don't think it makes sense to necessarily follow their practice because: a) they aren't a .NET shop I don't believe, and b) their process may be completely different than yours.  You can see, based upon PVs, where some of the grouping of files are though.  These are most likely common or third-party libraries they are linking in.  Such libraries will probably not share any versioning info with the product.  In some cases it looks like they are versioning files within the same product line separately (5.3, 5.5, etc).  Since I don't know their process I don't know how they map file versions to product versions.  I would guess that they started out the same FV if they shared the same PV but hotfixes and/or service packs updated some of the files to newer FVs (but the same PV).

    Thursday, September 4, 2014 5:19 PM
    Moderator