Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Acceleration can copy unused assembly reference to output directory #9575

Open
drewnoakes opened this issue Oct 29, 2024 · 2 comments
Open
Labels
Feature-Build-Acceleration Build Acceleration can skip calls to MSBuild within Visual Studio Triage-Approved Reviewed and prioritized
Milestone

Comments

@drewnoakes
Copy link
Member

(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
Copy link

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
Copy link
Member Author

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

@drewnoakes drewnoakes added the Triage-Approved Reviewed and prioritized label Oct 31, 2024
@drewnoakes drewnoakes added this to the Backlog milestone Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature-Build-Acceleration Build Acceleration can skip calls to MSBuild within Visual Studio Triage-Approved Reviewed and prioritized
Projects
None yet
Development

No branches or pull requests

2 participants