Build Acceleration can copy unused assembly reference to output directory

[drewnoakes]

(Originally reported in #9574. Restated here in a more minimal form after some investigation.)

Consider two projects:

Project A

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="MyAssembly.dll" />
  </ItemGroup>

</Project>

Project B

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\ProjectA\ProjectA.csproj" />
  </ItemGroup>
</Project>

class C
{
    void M()
    {
        // Use code from MyAssembly.dll, referenced by ProjectA
        new TypeFromMyAssembly();
    }
}

---

Rebuilding (i.e. without VS's FUTDC) the above ends up with something like (slightly abridged):

ProjectA
  bin
    Debug
      net8.0
        MyAssembly.dll
        ProjectA.dll
ProjectB
  bin
    Debug
      net8.0
        MyAssembly.dll
        ProjectA.dll
        ProjectB.dll

However, if you comment the usage of TypeFromMyAssembly in C.M and rebuild, then MyAssembly.dll is removed from the output directory of Project B.

The build is able to determine whether the referenced assembly is actually used or not, and only copies when it is.

Build Acceleration is not aware when a referenced assembly is unused, and will always try to copy the file to the output directory. This can cause extra files to be present in the output directory when Build Acceleration is enabled.

[julealgon]

Does this affect full rebuilds as well?

My initial understanding of build acceleration was that it was focused on speeding up incremental builds, but this issue leads me to assume that the extra copied DLLs would be copied regardless of whether this is an incremental build or not.

We have a few deployment flows that rely on VisualStudio as the build system and those target SDK-style projects. This is mostly supporting .NET 4.7.2 projects.

I'd like to know if I should disable this setting for all of our projects in this situation to reduce bloat on the final deployment output.

[drewnoakes]

Does this affect full rebuilds as well?

No, rebuilds always call MSBuild (skipping VS's fast up-to-date check, which Build Acceleration is a part of). BA only applies to incremental builds.

The issue here will only impact you if you have projects that reference an assembly (i.e. a DLL on disk, not via NuGet) and then don't use that assembly in any code. I'm working with the assumption that this is somewhat uncommon, especially as it's taken this long to have a report of this.

To verify if this issue impacts you:

• Delete all output files (manually, git clean -xdf, etc...)
• Open the solution in VS
• Enable fast up-to-date check logging at "verbose" level via Tools | Options
• Rebuild the solution
• Perform a build (not rebuild) and monitor the output window

Look for any messages about copying of files.

More information at https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md

[mlancione]

There are scenarios where Types are not directly referenced in code and reflection is used via Activator.CreateInstance() instead. In these scenarios you still want the assembly dll to be copied. Therefore, when using reflection I believe the expectation is that ProjectB's ProjectReference to ProjectA ensures that the dll will be copied and that Build Acceleration still triggers a ProjectB build when ProjectA changes.

[garevaul]

@drewnoakes as you said, this is working fine ::

I started using this in All my projects.
<AccelerateBuildsInVisualStudio>false</AccelerateBuildsInVisualStudio>

And also disabled the Visial Studio Preview feature option 'AccelerateBuildsInVisualStudio'.

I guess it is a feature just to speed up the build process, so it is not a mandatory thing.

But it is a Bug nonetheless.

Regards