Build fails on missing generated files

[eddynaka]

Hi,

I started to see this in one of my Azure Pipeline builds for the specific .AssemblyAttributes file but random projects:

CSC : error CS2001: Source file 'D:\a\1\s\src\..\bld\obj\AnyCPU_Release\WorkItems\.AssemblyAttributes' could not be found. [D:\a\1\s\src\WorkItems\WorkItems.csproj]

I observed that this started to happen after net5.0 got installed by default in windows-latest machines.

environment: windows-latest azure pipeline
dotnet versions: 2.1.x, 3.1.x, 5.0.x (versions pre-installed).

cc: @jasonmalinowski

[rainersigwald]

@eddynaka Is it possible for you to share a binlog for the failure? That looks like this line

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets

Line 21 in c816dee

<GeneratedAssemblyInfoFile Condition="'$(GeneratedAssemblyInfoFile)' ==''">$(IntermediateOutputPath)$(MSBuildProjectName).AssemblyInfo$(DefaultLanguageSourceExtension)</GeneratedAssemblyInfoFile>

is missing some information--but it doesn't make much sense for $(MSBuildProjectName) to be empty, since that's set very early in the MSBuild evaluation process by MSBuild itself (not any .props/.targets files).

[eddynaka]

@rainersigwald , i will configure the binlog. The issue is that it does not happen always. So, will keep triggering the build.

[eddynaka]

@rainersigwald, how do I enable for dotnet builds? I saw commands just for MSBuild and in the dotnet docs, I couldn't find anything related.

Thank you!

[PathogenDavid]

how do I enable for dotnet builds?

Add -bl to your command. IE: dotnet build -bl (dotnet build just wraps MSBuild, it passes command line arguments it doesn't know about through to it directly.)

The log will be written to msbuild.binlog in the current working directory.

(Make sure none of your CI secrets end up in it. Binlogs end up with a listing of all environment variables.)

[eddynaka]

@PathogenDavid , thank you! will add and check!

[eddynaka]

Now, since the issue does not happen all the time, a binlog from a successful build would be useful?

[dsplaisted]

A failing binlog would be better, but a successful one might help.

@rainersigwald Per the error message, the file it can't find is .AssemblyAttributes, not .AssemblyInfo. So it's probably coming from here:

https://github.com/dotnet/msbuild/blob/5abf1ff7bc05ef47a7680f6a5ea87f3c6f32812c/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3390

So it looks like the TargetFrameworkMoniker may not be set in some cases.

[eddynaka]

Attached you can find a working binlog (build that succeeded).
msbuild.zip

For the TargetFramework, I'm sure that it is set everywhere.

[rainersigwald]

Per the error message, the file it can't find is .AssemblyAttributes, not .AssemblyInfo. So it's probably coming from here:

https://github.com/dotnet/msbuild/blob/5abf1ff7bc05ef47a7680f6a5ea87f3c6f32812c/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3390

So it looks like the TargetFrameworkMoniker may not be set in some cases.

🤦🏻‍♂️ I'm going to blame Friday Brain for that one.

@eddynaka The unusual path is caused by this line in src\build.props:

<TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>

That's essentially a copy/paste of the line Daniel linked above but in MSBuild order matters--and here the properties $(TargetFrameworkMoniker) and $(DefaultLanguageSourceExtension) aren't defined until later in the import order (in Common.CurrentVersion.targets).

While having a funky path/filename there is nonfatal, I think the lack of $(TargetFrameworkMoniker) might be the root cause of your problems. Some of your projects are multitargeted (in the binlog, Sarif.csproj is), so they may build multiple times in parallel. If one of those tries to write a new copy of the file, there may be a period of time where the file isn't there for another one to find it.

Can you just delete that line from build.props? I think it doesn't do anything different from the default.

[eddynaka]

@rainersigwald , that is used for the github sourcelink when we have a multitarget project. Adding the flag -maxcpucount:1 would work?

[rainersigwald]

that is used for the github sourcelink when we have a multitarget project

Can you clarify please? Since this is a generated file it shouldn't have any sourcelink impact--there's no GitHub URL for the file.

Adding the flag -maxcpucount:1 would work?

Probably, but this will slow down your build to work around a bug in the build. I recommend fixing the bug instead.

[eddynaka]

@rainersigwald to generate a deterministic build we needed this. https://github.com/clairernovotny/DeterministicBuilds

[rainersigwald]

Ah, thanks! That's no longer needed, but if you want to continue to support building with older SDKs, you should move that line to a .targets file imported after common.targets--the linked doc recommends Directory.Build.targets and in the binlog you sent you don't have an existing late import so I'd go with that too.

[eddynaka]

@rainersigwald , what do you mean by "older SDKs"? Can you give me an example? So I can see if I need to move that to the targets or to remove that.

Thank you again!

[rainersigwald]

@eddynaka That link calls out SDKs <= 3.1.300 (the relevant change was dotnet/msbuild#5101).

[eddynaka]

Ok. Got it. You can close this!
Thank you everyone! :)