R
Robert Misiak
Is it possible to manually change the auto-build number used in VS.NET?
Thanks,
Robert
Thanks,
Robert
B
Branimir Giurov
You can set it as a constant, by editing the assembly.cs file.
The AssemblyVersion attribute:
[assembly AssemblyVersion("1.0.0.0")]
Cheers,
Branimir
The AssemblyVersion attribute:
[assembly AssemblyVersion("1.0.0.0")]
Cheers,
Branimir
R
Robert Misiak
Thanks, but perhaps I should have explained myself better.
I already have set AssemblyInfo.cs appropriately. However the current build
is x.x.1665.x, and soon that 3rd number will increase. Call me old
fashioned but I would like to skip the next number and go directly to
x.x.1667.x. Is that possible?
Robert
I already have set AssemblyInfo.cs appropriately. However the current build
is x.x.1665.x, and soon that 3rd number will increase. Call me old
fashioned but I would like to skip the next number and go directly to
x.x.1667.x. Is that possible?
Robert
Branimir Giurov said:
G
Guest
The easiest thing to do would be to set your version explicitly to x.x.1667.*
That should get you what you want.
--
C Addison Ritchie, MCSD
Ritch Consulting, Inc.
That should get you what you want.
--
C Addison Ritchie, MCSD
Ritch Consulting, Inc.
Robert Misiak said:
R
Robert Misiak
Thanks, but this is an ongoing project that has been going on for over a
year - there are new builds at least once a week and frequently a few times
a day, it would be difficult to explicitly set the build number each time.
Robert
year - there are new builds at least once a week and frequently a few times
a day, it would be difficult to explicitly set the build number each time.
Robert
C Addison Ritchie said:
E
Eric Cadwell
You can set it to whatever you want.
-Eric
-Eric
E
Eric Cadwell
Just set the value and leave it - not on each build, but on each
deployment.. I agree that the x.x.1667.* format would be best.
The only real requirement is that you change the build number when you
deploy. MSI will not recognize the revision number so each deployed version
must be unique in the major, minor, or build number.
-Eric
deployment.. I agree that the x.x.1667.* format would be best.
The only real requirement is that you change the build number when you
deploy. MSI will not recognize the revision number so each deployed version
must be unique in the major, minor, or build number.
-Eric
R
Robert Misiak
This doesn't seem right though because it's been x.x.1665.x for a week or
so. I also just changed the system date and recompiled and it was still
1665. The number must be stored in the project somewhere because I've found
that compiling on a different system will produce a similar build number.
Robert
(July 24, 2004) it will be the number which we will not mention.
Sunday it will be 1668. So the answer seems to be... don't compile
tomorrow.
so. I also just changed the system date and recompiled and it was still
1665. The number must be stored in the project somewhere because I've found
that compiling on a different system will produce a similar build number.
Robert
since January 1, 2000. Which means today it is going to be 1665. TomorrowC Addison Ritchie said:
(July 24, 2004) it will be the number which we will not mention.
Sunday it will be 1668. So the answer seems to be... don't compile
tomorrow.
R
Robert Misiak
Apparently I should have restarted VS.NET when changing the date; when I
changed the date to the 7-25 and restarted VS, I got build #1667. Thanks!
Robert
(July 24, 2004) it will be the number which we will not mention.
Sunday it will be 1668. So the answer seems to be... don't compile
tomorrow.
changed the date to the 7-25 and restarted VS, I got build #1667. Thanks!
Robert
since January 1, 2000. Which means today it is going to be 1665. TomorrowC Addison Ritchie said:
(July 24, 2004) it will be the number which we will not mention.
Sunday it will be 1668. So the answer seems to be... don't compile
tomorrow.