When building from within Visual Studio (following the post http://tinyurl.com/p9fpvnh), is it possible to have the current version automatically replaced if it exists?
I know there is an option when uploading a package from the UI. I want to use the same option when building from Visual Studio.
Hi Mdw-od,
Thanks for getting in touch!
The short answer is no, Octopus won’t accept a Nuget package with the same version as an existing package.
Consider the situation where you push version 1.0.0 of a build to Octopus and then create a Release and deploy to your Development environment.
If you then push a new version 1.0.0, and promote your Release to the Test environment, the new package will be used (ignoring caching).
You now have a situation where different packages have been used in your environments, but there’s no way to tell there’s a difference.
It’s important to know that version 1.0.0 of an artifact or a release (e.g. an exe or dll) is unique. The version number is a way to identify when something has changed - no matter how small.
We allow this option from the UI because if you’re uploading manually, the packages unlikely to be part of your core deployment process. Even then, we discourage writing over an existing version.
In Visual studio, you can get a new version number for each build by setting the AssemblyVersion to 1.0.* in your AssemblyInfo.cs file. That will result in a version that starts with 1.0 each time, but also has a unique version number.
I hope that helps!
Damo
Damo,
Thanks for the update. I’m still confused about two things. Here is the common code from AssemblyInfo.cs.
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the ‘*’ as shown below:
[assembly: AssemblyVersion(“1.0.0.0”)]
[assembly: AssemblyFileVersion(“1.0.0.0”)]
[assembly: AssemblyVersion(“1.0..0")]
[assembly: AssemblyVersion("1.0.0.”)]
[assembly: AssemblyVersion(“1.0..”)]
Hi,
- What’s the difference between the following AssemblyVersion settings? Any recommendations on best practice?
The first and last options won’t work - if you want auto-incrementing numbers, you need to have one asterisk at the end of the number. There’s more information about the allowed formats on MSDN.
The format of the version number is <major>.<minor>.<build>.<revision>. The most common practice is to use 1.0.* as the pattern because this guarantees a unique version number that always increases (important if you need to work out the newest version). If you choose 1.0.0.*, your versions won’t be guaranteed to be in order. From the MSDN article:
“The default build number increments daily. The default revision number is the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.”
- What about AssemblyFileVersion? I’ve seen some posts that say to comment this out. Any recommendations on best practice?
This is up to you. OctoPack doesn’t use the AssemblyFileVersion attribute, so it shouldn’t affect anything with Octopus.
I hope that helps!
Damo