Turn off dynamic versioning
-
When you say dynamic versioning, do you mean the auto increment of build and version numbers? If so you can turn this off by acessing the projects AssemblyInfo.cs file. There'll be a section that looks like:
[assembly: AssemblyVersion("1.0.*")]Just remove the star and set it manually and your away. If you don't mean this then sorry. -
When you say dynamic versioning, do you mean the auto increment of build and version numbers? If so you can turn this off by acessing the projects AssemblyInfo.cs file. There'll be a section that looks like:
[assembly: AssemblyVersion("1.0.*")]Just remove the star and set it manually and your away. If you don't mean this then sorry.I was about to ask a question related to this. Right now my code looks like:
[assembly: AssemblyVersion("1.0.0.0")]But I have versions like 1.0.1300.27939, anyway! That's fine with me, actually, since I wanted to have build numbers included, too -- it seemed like that would make sense to have some sort of subminor version. So I'm really confused where it's getting "1.0.*" from... The funny thing is, if I set the assembly version to "1.0.*", then I build a new installer (setup.msi), and it won't install! It only installs when assembly version is set to "1.0.0.0". And then, it's a really minor thing, but when browsing C:\Windows\Assembly, I see that the System assemblies have different Versions vs. Assembly/Product versions (which seem to be the same in the Properties dialog). And I don't see how to set that -- perhaps it's set by an Installer? What's the reasoning behind having it be major.minor.build.revision, anyway? Doesn't it make more sense as major.minor.revision.build? -
I was about to ask a question related to this. Right now my code looks like:
[assembly: AssemblyVersion("1.0.0.0")]But I have versions like 1.0.1300.27939, anyway! That's fine with me, actually, since I wanted to have build numbers included, too -- it seemed like that would make sense to have some sort of subminor version. So I'm really confused where it's getting "1.0.*" from... The funny thing is, if I set the assembly version to "1.0.*", then I build a new installer (setup.msi), and it won't install! It only installs when assembly version is set to "1.0.0.0". And then, it's a really minor thing, but when browsing C:\Windows\Assembly, I see that the System assemblies have different Versions vs. Assembly/Product versions (which seem to be the same in the Properties dialog). And I don't see how to set that -- perhaps it's set by an Installer? What's the reasoning behind having it be major.minor.build.revision, anyway? Doesn't it make more sense as major.minor.revision.build?So I figured out the problem with my installer is that I'm using a custom installer, with included code:
Assembly VisITBarAssembly { get { return AppDomain.CurrentDomain.Load("VisIT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d504ee06f99380a"); } }And so that probably fails if I use "1.0.*" in AssemblyInfo. Is there a way to get the above code to work if I set AssemblyVersion to "1.0.*"? I've tried some different attacks, and they've all been failing. I'd like to not have to change version numbers in 10 different places all the time. :) -
I was about to ask a question related to this. Right now my code looks like:
[assembly: AssemblyVersion("1.0.0.0")]But I have versions like 1.0.1300.27939, anyway! That's fine with me, actually, since I wanted to have build numbers included, too -- it seemed like that would make sense to have some sort of subminor version. So I'm really confused where it's getting "1.0.*" from... The funny thing is, if I set the assembly version to "1.0.*", then I build a new installer (setup.msi), and it won't install! It only installs when assembly version is set to "1.0.0.0". And then, it's a really minor thing, but when browsing C:\Windows\Assembly, I see that the System assemblies have different Versions vs. Assembly/Product versions (which seem to be the same in the Properties dialog). And I don't see how to set that -- perhaps it's set by an Installer? What's the reasoning behind having it be major.minor.build.revision, anyway? Doesn't it make more sense as major.minor.revision.build?The question of "What's the reasoning behind having it be major.minor.build.revision, anyway? Doesn't it make more sense as major.minor.revision.build?" is one that we are puzzling over. From various articles posted around it seems that there are some Microsoft strategies such as maj.min.d.s (elapsed days since Feb 1 1970 and elapsed seconds since midnight) and other 'private' strategies of fixing the build and /or revision numbers. We favour using maj.min.iter.build where for every build the last digit is incremented (1.2.3.4 goes to 1.2.3.5), and 'iter' is incremented when :|we move to the next iteration (Agile / Extreme). Whenever we move up any of iteration, minor or major numbers we reset the lower numbers to 0. E.g. If we have 1.2.3.4 and update the mojor number then the next full number will be 2.0.0.0.