I just saw that site revision is 126.96.36.199
Someone just dropped it to default state, or there is integer overflow?
This now fixed. It may be silly, but I bet others hit it so...details! TL;DR: a code move in our .NET Core migration read AssemblyVersion from an assembly that was set (via
AssemblyInfo.cs during a build) to one that wasn't (an SDK project which doesn't have that stuff).
I figure it's best to just literally paste my commit message here:
When we moved assembly versioning down to
StackOverflow.Common, the footer went back to 188.8.131.52. This happened because our build replaces the versioning in
AssemblyInfo.cswhich doesn't exist anymore in .NET Core. We need to instead replace it as
.csproj. We may change to git versioning here later, but this maintains the date version for the moment (e.g. in the footer).
This change is paired with a "File content replacer" feature on the TC builds to do the actual replacement. Again: this gets us back to working...but we should replace how all this works with built-in git versioning and a date feed from elsewhere if we want to maintain that in the footer.
Note: locking the build replacement down to
StackOverflow.Common.csprojsince it replaces the
<Version>element which catches this in
<PackageReference Include="System.ValueTuple"> <Version>4.5.0</Version> </PackageReference>
While this should be:
<PackageReference Include="System.ValueTuple" Version="4.5.0" />
...the tooling does that and the problem will just occur again. So let's just side-step most of the noise of such things by locking it down.
Setup in TeamCity:
Path pattern: "**/StackOverflow.Common.csproj" File encoding: UTF-8 Search for: (?-m)(<Version>)(.*)(<\/Version>) Match case: true Regex: true Replace with: $1%system.build.start.year%.%system.build.start.month%.%system.build.start.day%.%system.build.number%$3