TeamCity AssemblyInfo Patcher: How to use version with three digits? - teamcity

I'm using TeamCity's built-in AssemblyInfo version patcher to patch the Assemblyversion of my project.
This is the content of my AssemblyInfo.cs:
[assembly: AssemblyVersion("2020.8.1")]
This is my AssemblyInfo patcher feature setting:
However, the actual version of my application is 2020.8.1.0 - it has four version digits and has a trailing zero:
After researching a lot about this and reading several SO questions, I did not find a way to use a version with only three digits. The only way I can think of is using not the AssemblyVersion patcher, but a "general" patcher that can replace anything by using a RegEx. But before doing that, I prefer to update the AssemblyInfo version manually in my source code.
Is there a way to use the AssemblyInfo patcher with a three-digit version?

I fixed the issue. Actually the trailing zero has nothing to do with TeamCity's AssemblyVersion patcher. It is simply the behavior of the AssemblyVersionAttribute itself. If you use a version with three digits, it will automatically set the revision number to "0". This is documented in the example code in the docs.

Related

How to constrain Gradle's "latest.integration" or "latest.release" to a range?

Still learning gradle here. Looking for a way to get either the latest "anything" (snapshot/integration or release) or latest must-be-release for a given range, say [1.0,2.0). Is there a way to specify that? Searched everywhere and only found references to either using ranges (which does not seem to allow me to restrict to releases or work with snapshots) or to always keep it entirely open using "latest.integration" and/or "latest.release".
Please help!
[1.0,2.0) already means either "latest anything" or "latest must-be-release" (I think the latter, but not entirely sure). The other isn't currently supported.
OK, I just updated to the newest Gradle 2.1. That resolved some issues I was having. Otherwise, I discovered the following:
"latest.integration" will match the latest anything - snapshot or release, whatever it finds newer.
"latest.release" will match the latest release and skip the snapshots.
"major.minor.+" (however many version number segments you have) will actually behave as "latest.integration" restricted to major.minor. Originally I thought it was restricted to releases but, no, it actually matches snapshots too.
"[1.0,2.0)" will actually behave list "latest.integration" within the range, too and will include snapshots, unlike I thought and commented above.
So, what I now don't know how to do is how to restrict a range or "1.+" to releases, but that is not my immediate problem (may be some hours from now, LOL).
UPDATE
One way to restrict versions to a range seems to be to mess with "Component metadata rules". Non-matching versions (those outside range) could be artificially declared non-releases. This is really ugly, though...
UPDATE 2
A part of my confusion was due to behavioural change between the old Gradle I was using and the new 2.1 one. Above is for 2.1 - old one I had (1.8) did NOT behave cleanly as per above.

OctoPackPackageVersion variable not picked up in TeamCity on single project out of multiple in same solution

(TeamCity version 7.1.3 on Windows 2008 R2, using Octopack NuGet package 2.0.20 for Console applications.)
Having some weird issues here: Rather than repeat the entire thread, I was hoping I could get some takers reading my linked post (short) and maybe offer some insight.
Basic issue is stated in the title of this post.
http://help.octopusdeploy.com/discussions/problems/6435-octopackpackageversion-variable-not-usedpicked-up-in-teamcity
I have been trying to determine why in just one particular project within the same solution why it is that the OctoPackPackageVersion variable is not being passed to nuget via Octopack whereas all other projects in the solution behave as they should picking up the proper version from the TeamCity system variable defined as:
...nuget\NuGet.exe" pack "bin\Release\NuGet-temp\CaptiveAire.Core.SocketServers.ServiceHost.nuspec" -OutputDirectory "bin\Release" -basePath "bin\Release\NuGet-temp" -Version "1.0.0.0" -NoPackageAnalysis
Thanks for any assistance.
Ok so this came down to having mixed versions of OctoPack support files: targets and newer C# targets DLL for msbuild.
See the linked support page in the original question.
Hope this possibly helps someone else.

Having a string in a MSI / WiX version number

I'm trying to convert our NSIS setup to a WiX/MSI based one. I used to use version numbers like 1.0.4 or 1.0.4.898, which works fine. However when I make a beta, I call it 1.0.4beta1, which is different from 1.0.4 (for example, it says 'beta' in the aboutbox, so it's actually build with different preprocessor #defines). This doesn't seem to be possible with WiX, the Version attribute of a Product can only contain a 'x.x.x.x' string. How do I encode free-text status in the version string, like beta or demo status? Thanks.
Windows Installer doesn't allow this (it encodes the ProductVersion property into a DWORD registry value). You must instead place your custom version string in another property.

Make Visual Studio not care about DLL versions

Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.

Should I auto-increment the assembly version when I build my software?

In Visual Studio 2003, you could easily set your project assembly to auto-increment every time you built it, but with Visual Studio 2005, this functionality was removed. You can still auto-increment your assembly version on every build, but it's a complicated custom build step instead of an integrated feature.
I'm not sure why this was removed, but here's a question I should have asked a while ago - Should I be using a workaround to continue to auto-increment when I build, or is there a good reason to stop doing this, in favor of manually incrementing? Since Microsoft removed it from VS, perhaps there's a good reason, and I'm wondering if anybody knows it.
No, auto-increment on the [AssemblyVersion] is supported in VS2005 and up. Make it look like this:
[assembly: AssemblyVersion("2.0.*")]
I have little use for this capability myself. [AssemblyVersion] describes the outward visible public interface for an assembly. That doesn't change when I simply rebuild the assembly. [AssemblyFileVersion] is appropriate for tracking build numbers. Sadly, it does not have the auto-increment capability. Note how the .NET assemblies use that version numbering strategy as well.
Also note this feedback item.
I personally prefer not to do it since I at the moment work on a project where I need to be able to know exactly what features where added to exactly what version and if it autoincremented every time I built it would increase too rapidly.
However, I think it depends on your project if the advantages outweigh the disadvantages. Here's an old MS Patterns page that discusses advantages vs disadvantages of the built in auto incrementation:
http://msdn.microsoft.com/en-us/library/ee817676.aspx

Resources