"The assembly has already been processed by Fody" in nuke

[ltrzesniewski]

1. Checkout https://github.com/nuke-build/nuke/tree/feature/adaptive-logging
2. Execute build.sh or build.ps1
3. There should be an msbuild.binlog in the root

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.

The suggested property from #1023 did not change anything, but if it's MAUI specific, that explains it.

Originally posted by @matkoch in #895 (comment)

[ltrzesniewski]

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.

[matkoch]

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

[ltrzesniewski]

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

[matkoch]

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.

[tom-englert]

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.

[ltrzesniewski]

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...

[tom-englert]

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

[tom-englert]

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

[ltrzesniewski]

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.

[matkoch]

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

[ltrzesniewski]

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.

[matkoch]

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

[ltrzesniewski]

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)

[matkoch]

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

[ltrzesniewski]

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.