none
WPF application build

    Question

  • When I build my application and have the assembly version set to  1.1.*

    i get for example a version number 1.1.2980.20720

    (the file version is blanked out as the documentation says)

     

    The rebuild a day later still gives the same build version 1.1.2980.20720 ??????????????????

     

    Seems like a bug to me.
    Thursday, March 06, 2008 10:21 AM

Answers

All replies

  • Is the source code changed between the two days?
    Thursday, March 06, 2008 10:24 AM
  • Yes i did change the system date +1 day in between.

    I even ended VS2008 updated the date and restarted it.

     

    Just create a new wpf project.

    change the build to 1.1.*,

    remove the file version number and build the project.

    have a look at the number

    change the date,

    rebuild and have again a look at the number.

     

     

    Thursday, March 06, 2008 11:46 AM
  • I cannot produce this problem, have you tried to clear the previous build, and rebuild the whole app again?

    Thanks
    Monday, March 10, 2008 2:45 AM
  • Yes I did. Same result.

    My Colleque has the same problem on his PC.

     

    I have installed VS 2003, VS 2005 and VS2008.

     

    Could this be a problem?

     

    Is there some kind of VS project settings file where i could look at.

     

     

    Monday, March 10, 2008 8:23 AM
  • I think you are talking about the AssemblyVersion attribute in AssemblyInfo.cs

     

    [assembly: AssemblyVersion("1.0.*")]

     

    The default for a C# project is 1.0.* and the * means that, that part of the version number will keep on auto incrementing.

     

    It is a recommended practice to replace this with an absolute value and increment it as and when you require.

     

    [assembly: AssemblyVersion("1.0.0.1")]

     

    I think this behavior is for C# projects and doesn't happen for VB.NET projects, but I don't have VB.NET currently installed so cannot verify.

     

    Even letting it auto increment isn't really a problem as such, but can make version tracking and debugging difficult since you will not really know which version you have released to customers. That said, you can additionally use either or both of the following to keep track of version number and can view this via Explorer, right click -> Properties.

     

    [assembly: AssemblyFileVersion("1.0.1.0")]

    [assembly: AssemblyInformationalVersion("1.1.0.0")]

     
    AssemblyFileVersion appears as File Version and AssemblyInformationVersion appears as Product Version.
    Monday, March 10, 2008 10:04 AM
  • This is what I have set:

     

    <Assembly: AssemblyVersion("3.11.*")>

     

    I do not want to manually set the version number since I have 15 projects that are compiled for creation of a new version.

    In the help it says that the 3.11.* will automatic increment revision and build where revision is the day number.

    But this does not work on my system.

     

    product version must be removed, otherwise the automatic increment will not work.

     

    Monday, March 10, 2008 10:15 AM
  • Unfortunately, the auto increment doesn't necessarily increment by 1. I haven't figured out what logic is used to increment the number.

     

    You may have to look at exploring options of creating custom build script where in you modify the version number and then do a build.

     

    Monday, March 10, 2008 10:37 AM
  • The increment of the build number is based on the day since 1-1-2000.

    So rebuilding the project the next day would mean that the build number should increase with 1 when specifying a *.

     

    Let me show you a part of the help file:

    Code Snippet

    You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (*). For example, [assembly:AssemblyVersion("2.3.25.1")] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.*")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is random.

     

     

     

     

    Monday, March 10, 2008 10:45 AM
  • Thanks.

     

    I just tried all of this again. Started with 1.0.* as the assembly version and compiled. The assembly version was 1.0.2991.*. Leaving the last portion since it is revision number and is random.

     

    I then modified my machine's date to tomorrow and rebuilt (after having touched 1 file). I got the version now as 1.0.2992.*. I tried it for another day's increment and it showed the value as 1.0.2993.*

     

    So it is incrementing on a daily basis. I am using VS 2008 RTM and working with the a C# project.

     

    Needless to say that the number increments only if there is something to build, i.e. at least 1 file included in the project has been modified and has a time stamp later than that of the assembly. Else, it will not be impacted and the version number will remain as is.
    Monday, March 10, 2008 11:26 AM
  • What I did now is creating a new C# program with the 3.1.*

    Compile,change date, recompile.

    And this works!

     

    OK,

    So now I created a new Visual Basic project with the 3.1.*

    Compile,change date, recompile.

     

    This does not work. It still had the same build version.

     

    So this means there would be a BUG in the Visual Basic environment!

     

    I use (copy info button):

    Microsoft Visual Studio 2008
    Version 9.0.21022.8 RTM
    Microsoft .NET Framework
    Version 3.5

    Installed Edition: Enterprise

    Microsoft Visual Basic 2008   91904-270-4772985-60000
    Microsoft Visual Basic 2008

    Microsoft Visual C# 2008   91904-270-4772985-60000
    Microsoft Visual C# 2008

    Microsoft Visual C++ 2008   91904-270-4772985-60000
    Microsoft Visual C++ 2008

    Microsoft Visual Studio 2008 Tools for Office   91904-270-4772985-60000
    Microsoft Visual Studio 2008 Tools for Office

    Microsoft Visual Studio Team System 2008 Development Edition   91904-270-4772985-60000
    Microsoft Visual Studio Team System 2008 Development Edition

    Portions of International CorrectSpell™ spelling correction system © 1993 by Lernout & Hauspie Speech Products N.V.  All rights reserved.

    The American Heritage® Dictionary of the English Language, Third Edition Copyright © 1992 Houghton Mifflin Company.  Electronic version licensed from Lernout & Hauspie Speech Products N.V.  All rights reserved.


    Microsoft Visual Web Developer 2008   91904-270-4772985-60000
    Microsoft Visual Web Developer 2008

    Crystal Reports    AAJ60-G0MSA4K-68000CF
    Crystal Reports Basic for Visual Studio 2008

     

    Willie Jan.

     

    Monday, March 10, 2008 12:49 PM
  • From what I know it isn't a bug in VB, but an additional feature that C# compiler offers. This isn't a .net feature, but something that C# compiler provides. So if you want this feature, you need to work with C#  or if you want to stay with VB.NET, you won't get this particular feature.

     

    There have been and are differences between some of these types of features between VB.NET and C#. I don't think we can call them as bug !

    Tuesday, March 11, 2008 6:05 AM
  • If the manual says it's possible, and it does not work, than it's a bug.....

     

    In the past VS 2003 and vs2005 it worked fine!

     

    So, what do I have to do to get this working?

    Call Bill? Oh that's right, he retired..

     

    This is a real pain in the xxx.

     

    Tuesday, March 11, 2008 8:57 AM
  • My mistake. I just tried it on a friend's machine which has VB.NET with VS 2008 and the auto increment is working fine. I did had to manually edit the AssemblyInfo.vb file though to set it is 1.0.*.*. The UI in Project settings didn't allow me to set it.

     

    Found a discussion on Channel 9 on this as well - http://channel9.msdn.com/ShowPost.aspx?PostID=378591

     

    Thursday, March 13, 2008 6:46 AM
  • Hi,

     

    I found a Microsoft page where the vb team confirms.

     

    No solution until now for automatic build numbering....

     

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=331107

     

     

    What I did now is creating a program that runs through all my project folders searching for assemblyinfo.vb files and replacing the internal build number before i compile my product.

    Thursday, March 13, 2008 7:28 AM
  • The particular entry talks about VB based Workflow application. And I have myself confirmed that the autoincrement worked on my VS 2008 Professional Edition.

     

    I noticed that you have Web Express Edition. Not sure if it is a limitation with that particular edition

    Thursday, March 13, 2008 9:23 AM
  • I can uninstall it to see what happens.

     

    My machine also contains VS2005.

     

    A colleque my has the same problem with building his projects in VS2008 (VB).

     

    Thursday, March 13, 2008 12:13 PM
  •  

    The link you have provided talks about VB and a Workflow solution. Not sure if there is some specific issue with that. Also I tested this on VS 2008 Professional Edition and it worked fine for a VB.NET solution. I see that you are using Web express edition. I don't have access to it to try on it, but could be a limitation of express edition
    Friday, March 14, 2008 11:47 AM
  • Actual what I am using is the (Help / About box info)

     

    Visual Studio Team system 2008 development edition.

    Microsoft Visual Studio 2008

    Version 9.0.21022.8 RTM

     

    I do not think we have a express edition running here.

     

    I am running this on A Windows XP machine which is updated (auto).

    The language of this XP version is Dutch. A colleque of my has Windows Vista (english) with the same problem.

    I manually checked the updates yesterday to be sure for the last patches, but nothing to do..

     

    There is also VS 2005 installed on this machine.

     

     

    What I did now is manually with notepad adjusting the assemblyinfo.vb file to fill in a new buid.revision number.

    after that I open the project and Rebuild it. Afterwards I checked the number, it contains still the same (old) number....

     

    Next i closed the project.

    removed the obj folder and emptied the bin folder.

    Opened the project and rebuild it.

    Afterwards I checked the number, it even now contains still the same (old) number....

    How is this possible because i removed all the files where the old number was available from???????

    Or is something stored in the <project>.suo file which is binary, so I can not see if there is something stored.

    Friday, March 14, 2008 11:59 AM
  • Strange !! Just curious ... where and how are you confirming that the number hasn't changed?

     

    Friday, March 14, 2008 12:32 PM
  • File properties.

     

    Version Tab

     

     

    Friday, March 14, 2008 1:22 PM
  • If you are setting the AssemblyVersion attribute, you need to verify that using ILDASM. Open the assembly in ILDASM and verify that assembly version that is displayed right towards the bottom. This is what i have verified, does get's auto incremented.

     

    For File version (in explorer), set the AssemblyFileVersion attribute

     

    Sunday, March 16, 2008 5:29 AM
  • I found a strange thing.

     

    I compiled a new WPF VB 2008 project with 3.11.5.1.

     

    Next I set the lines in the assemblyinfo to:

    Code Snippet

    <Assembly: AssemblyVersion("3.11.7.1")>

    <Assembly: AssemblyFileVersion("3.11.7.1")>

     

    Recompile:  The product version and fileversion are the same, 3.1.7.1 as expected.

     

    Now I made comment for the fileversion.

    Code Snippet

    <Assembly: AssemblyVersion("3.11.7.1")>

    '<Assembly: AssemblyFileVersion("3.11.7.1")>

     

    Recompile:  The product version and fileversion are the same, 3.1.5.1  ?????????.

     

    Who can explain this to me?

    Where does it get the number from. It's an old version number that it is showing, not the one i set.

     

    Monday, March 17, 2008 9:06 AM
  • if you want to get the auto increment, do this

     

    <Assembly: AssemblyVersion("3.11.*")>

     

    When you compile and check in ILDASM tool, you will see the version as something like 3.11.2395.123223

     

    change the system date to 1 day ahead, and make some edit to any file (could be as simple as inserting a  blank space somewhere in the file) and then recompile. Again check in ILDASM and the version would be something like 3.11.2396.12443

     

    You should see the 2395 become 2396 (actual values will differ, but there will be an increment)

     

    Monday, March 17, 2008 11:14 AM
  •  Atul Gupta wrote:

    if you want to get the auto increment, do this

     

    <Assembly: AssemblyVersion("3.11.*")>

     

    When you compile and check in ILDASM tool, you will see the version as something like 3.11.2395.123223

     

    change the system date to 1 day ahead, and make some edit to any file (could be as simple as inserting a  blank space somewhere in the file) and then recompile. Again check in ILDASM and the version would be something like 3.11.2396.12443

     

    You should see the 2395 become 2396 (actual values will differ, but there will be an increment)

     

     

    Question:

    Why should I use ILDasm to check the product version and fileversion ??

     

    Properties of the file show me the versions.

     

     

    Sure I know that I can use the 3.1.*, but that does not work!

    When I increment the day by one, the next compile still shows me the same as before. In your case 2395.

     

    Only as described above when i set the assemblyversion AND assemblyfileversion to the same number it works and the compile takes the new number i entered. When i comment out the asemblyfileversion, it does not work anymore.

    Monday, March 17, 2008 11:25 AM
  •  Willie007 wrote:

    Question:

    Why should I use ILDasm to check the product version and fileversion ??

    I was suggesting use of ILDasm to verify Assembly Version and not assembly file or product version. The assembly version can be viewed only in MSIL and hence the use of ILDasm

     

    Let me check on this again on a VB project and get back. In the meantime, look at a custom task that MSBuild can use to increment the version numbers - http://weblogs.asp.net/bradleyb/archive/2005/12/02/432150.aspx

     

    Q1. Do you want all three version# (assembly version, assembly file version and assembly product version) to auto increment?

     

    Q2. Can you share a URL from where you had earlier shared the documentation details on auto increment feature?

    Monday, March 17, 2008 4:47 PM
  • Q1:

    Yes i want all versions to increment.

    (that is what happens in VS 2005 when you enter 3.1.* for assemblyversion and blank the rest out.)

     

    Q2:

    http://msdn2.microsoft.com/nl-nl/library/system.reflection.assemblyversionattribute(en-us).aspx

     

    Tuesday, March 18, 2008 2:25 PM
  • Here is what I did using VS 2008 Professional Edition (9.0.21022.8 RTM) edition and using VB.NET solution type

     

    I had only the following in my AssemblyInfo.vb file

     

    <Assembly:AssemblyVersion(1.0.*)>

     

    When I first built my project, the version (for all three - Assembly version, Assembly file version and Assembly Product version) was seen as 1.0.3000.25661

     

    I then did a minor edit in the file so that the project will build again and verified that all 3 version numbers did indeed increment to 1.0.3000.25685

     

    I then modified by machine's date to set it to a day ahead. Again did a minor edit in 1 file so that the project will build and verified that the version numbers now showed up as 1.0.3001.25711

     

    So the version number does auto increment when the day changes.

     

    Note that it is important to modify/edit at least 1 file everytime, else, even if you hit build in VS, it won't actually build anything and hence you won't see any change in version number. I hope you are doing that between your builds to verify the changes in version number.

    Wednesday, March 19, 2008 8:56 AM
  • When I perform your test here,

     

    I get the number 1.0.3000.20269 after the first compile for all version numbers.

     

    After that it doesnt matter what I do, it get the same 1.0.3000.20269 number for all.

     

    Even when I am standing on my head

     

     

    Wednesday, March 19, 2008 3:54 PM
  •   i give up !!!

     

    Thursday, March 20, 2008 5:35 AM
  • Hi...Sorry for make a question about this thread, for one year ago...

    Im doing a wpf application and have the same issue that you, without using autoversion, but in one developer machine, the number of assemblyinfo.vb is not used when compiled, and ever show other old number.

    Do you remember, how fixed this...

    Thanks
    Wednesday, July 01, 2009 11:47 AM