Repository navigation
Arcade is using assembly version 42.42.42.42 in official builds, but only on Linux #2941
Description
Since Monday, we've been seeing build failures in aspnet/Extensions with this error in official builds on Linux:
error MSB3243: No way to resolve conflict between "Microsoft.Extensions.Configuration.Abstractions, Version=42.42.42.42, Culture=neutral, PublicKeyToken=adb9793829ddae60" and "Microsoft.Extensions.Configuration.Abstractions, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60". Choosing "Microsoft.Extensions.Configuration.Abstractions, Version=42.42.42.42, Culture=neutral, PublicKeyToken=adb9793829ddae60" arbitrarily.
Example: https://dev.azure.com/dnceng/internal/_build/results?buildId=209617
This error only happens in the Linux leg of our build. It's unclear what is happening and why we are getting 42.42.42.42 even though /p:OfficialBuildId is being passed to the build.
Any ideas @tmat @mmitche ? I'm digging through binlogs and haven't found the answer yet.
Activity
mmitche commentedon Jun 4, 2019
/cc @dotnet/dncenghot since this is critical for p6
/fyi @leecow @wtgodbe
natemcmaster commentedon Jun 4, 2019
Ok, here is what I have uncovered so far. No solution yet, but here is what the logs show:
In aspnet/Extensions, we are building both reference and implementation assemblies. The reference assemblies build with the right assembly version, but the implementation project does not.
But, in the same binlog, the build of Microsoft.Extensions.FileProviders.Physical shows that 3.0.0.0 should have been used
tmat commentedon Jun 4, 2019
Additional observation: Searching
42.42.42.42424in binlog results in no entries, indicatinghttps://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/Version.targets#L29-L41 does not get executed.
natemcmaster commentedon Jun 4, 2019
I can confirm that somehow we're getting an AssemblyInfo.cs file generated with 42.42.42.42 in it, even though the binlog doesn't show this during the
WriteCodeFragmenttask.natemcmaster commentedon Jun 4, 2019
So, I believe the problem is coming from tests which result in executing
dotnet msbuild. Because test and build are interleaved, the tests might run before we finish building all projects, causing a double build.cc @Tratcher - I suspect the hosting deployer tests will be the source of our problem here.
Tratcher commentedon Jun 4, 2019
@natemcmaster any thoughts on why this just started happening? Those Hosting tests have been there for months.
natemcmaster commentedon Jun 4, 2019
It's likely a race condition which only happens under certain conditions. One of the unrelated changes I made last week to include NPM packages in our Linux build triggered the conditions.
What is currently scaring the most is that there is a small chance this could result in us shipping assemblies with version=42.42.42.42. I think I'm going to workaround this by explicitly setting
<AssemblyVersion>in aspnet/Extensions. I'm not sure what the 42.42.42.42 fallback gives us.natemcmaster commentedon Jun 4, 2019
Fixed with dotnet/extensions#1791