-
Notifications
You must be signed in to change notification settings - Fork 383
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
Inconsistent copy of transitive assembly references with FastUpToDate build #9417
Comments
@drewnoakes for investigation |
@govert thank you for the detailed repro. That's very helpful. We will take a look asap.
Why use a Reference instead of a ProjectReference? Referencing the output of another project in this way is not supported. For one thing, it hides the build order dependency from the build system. It's possible that the bug here is just a race condition. |
In our actual case, we were just referencing an external library (for which we did not have a project, solution or NuGet package) on its own. But when writing up the repro, I tried picking some random assembly from a NuGet package, but that was harder to explain in the write-up than just to add another project and use its output. (An extra quirk in our case was that the assembly .dll file had been renamed, so the internal assembly name did not match the .dll file name. But that seemed incidental too, and not needed to reproduce the extra copy.) |
I tried it now and referencing a library from a NuGet package in the |
Visual Studio Version
17.9.2
Summary
With the build acceleration option, there are now two build behaviours in Visual Studio - normal MSBuild build and the FastUpToDate build. We have found a case where the FastUpToDate build would copy additional output files where a normal build would not. This happens when a referenced project has a further assembly reference. This extra assembly would not normally be copied to the output of the top level project, but under FastUpToDate there is an extra copy done.
Steps to Reproduce
ConsoleApp1
in a solution namedTestFastUpToDate
(with the solution and project not in the same directory), targeting .NET 8.0.<Reference>
item with its HintPath.ClassLibrary1.csproj
ClassLibrary2.csproj
ConsoleApp1.csproj
C:\Temp\TestFastUpToDate\ConsoleApp1\bin\Debug\net8.0
for my project) to see what files are placed there from the build.Expected Behavior
Building or rebuilding the solution with the full build will behave the same way as a 'FastUpToDate' build.
Actual Behavior
A 'FastUpToDate' build copies an additional file to the output directory, which a rebuild or normal build does not copy.
This is the output from a normal build (Build -> Build Solution) when the output directory of ConsoleApp1 is empty:
Then when pressing
Build -> Build Solution
again, we get this FastUpToDate build:Note in the FastUpToDate build, we have an extra file copy of ClassLibrary2.dll to the output of ConsoleApp1.
This is the inconsistent behaviour between FastUpToDate and normal build.
User Impact
The default setting for build acceleration changed in VS 17.9 (according to the last internal VS check-ins referenced in this issue). For our projects this update turned out to be a surprising and hard-to-track-down breaking change. (Even though the previous comment suggests it changed for "sdk style (.NET core) projects", our sdk style (.NET Framework)" project was affected.) The default changed with no indication in the Visual Studio release notes.
The behavior of the "FastUpToDate" build is different to the normal MSBuild in that additional transitive dependencies are copied to the output, where MSBuild would not copy these files. With build acceleration on, the extra files will be copied to output when either doing "Build" or starting to debug, which both trigger the "FastUpToDate" build and hence the extra copy. When doing a "Rebuild" or building after changes, the real MSBuild build is run, which does not copy the extra files. This is even more confusing, since extra files will remain in the output until manually deleted ("Clean" runs MSBuild, which will not remove the extra files).
Whether the extra files should be there or not is another matter, but having these two incompatible build behaviors is very confusing. In our case these files were not used, but broke things at runtime.
There is an easy workaround for the problem - just disable the build acceleration for the project. In our case we were also able to remove the unneeded assembly references, but that might not always be the case.
The text was updated successfully, but these errors were encountered: