I can repro this as I'm getting lots of "The assembly has already been processed by Fody." warnings, but the produced binlog file does not contain those warnings.

At which stage are you getting the warnings? Right at the beginning or rather in the middle?

a git clean -xdf and build.ps1 shows it's at the second (dotnet run) stage. Looks like the following command produces them:

C:\Dev\Temp\nuke.nuke\temp\dotnet-win\dotnet.exe build C:\Dev\Temp\nuke\nuke-common.sln --configuration Debug --no-restore --verbosity Minimal

I checked again:

With build.ps1 I get them twice. Once from build.ps1 and once from the Compile target.

With build.ps1 Clean Compile I get them only from build.ps1. So it has something to do with existing artifacts.

Note that calling build.sh/ps1 will first compile all projects as part of compiling _build.csproj. After that, the _build.csproj will initiate another compilation. That's just what you end up when you do dogfooding :) Both produced warnings at some point.

Looks like this is the root cause. When you trigger multiple compilations, you should set a property per compilation - like the MAUI build does with $(_ComputeFilesToPublishForRuntimeIdentifiers) - so you can distinguish the build stages and switch of unneeded tasks, like e.g. Fody.

But that would trigger an unnecessary recompile I suppose. 🙁

The weaving task shouldn't be triggered on the second build if csc didn't run. Hooking Fody to TargetsTriggeredByCompilation looks like a good solution we could try, but that's not exactly a small change, we may risk regressions. 😅

OTOH this thing seems like it's purpose-built for Fody, so maybe we should try...

Sounds promising - is there any official documentation?
Since which MSBuild version is this available?

Seems to depend on the project type:
dotnet/fsharp#12100

Of course there isn't any doc. 😅

You're right: we need to take care about the compatibility. The code was already present in 2015 for C#: dotnet/roslyn@aa8d4ae (I didn't dig deeper to find when it was actually introduced) but F# is a concern though as it only has this feature since 2021.

Is there any way to apply a workaround from my codebase?

Sorry, we currently don't provide a warning code you could silence. 😕

Adding a code wouldn't be enough though: Fody's task would also need to take $(NoWarn) as an input in order to filter its warnings.

Afaik, MSBuild handles the warning suppression. You'd just need to use the MSBuild logger.

You're right, I didn't know $(NoWarn) is special.

The following project doesn't display any warning:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
	<NoWarn>$(NoWarn);LOL</NoWarn>
  </PropertyGroup>

  <Target Name="Lol" AfterTargets="Build">
    <Warning Code="LOL" Text="Hello" />
  </Target>

</Project>

It was introduced by dotnet/msbuild#5671 (the underlying magic property is actually MSBuildWarningsNotAsErrors)

Confused :) Is this workaround (my side) related?

Well I was saying we could add error codes to Fody messages on our end, and that would require less work than I initially thought to silence Fody warnings.

That would be a temporary "solution". I still intend to take a closer look at this issue when I'll have some time.

@matkoch can you try https://www.nuget.org/packages/Fody/6.6.5-beta2 ?

seems to work well!

@tom-englert any idea when this could be released?

@matkoch 6.7.0 is now available 😃

Danke dir Tom! :)