Visual Studio Build Acceleration not respecting "Copy Local" setting on dependencies.

[Maintenance-Partnership-Systems]

Visual Studio Version

17.9.2

Summary

I have a solution with many projects (60+). A large subset set of projects share common dependencies and are dynamically loaded at runtime. As such they are deployed to a sub-folder and the shared dependencies are deployed to the parent folder above (along with the rest of the application DLLs). Their shared dependencies must not be stored in the same folder as it causes problems with the dynamic loading logic.

In order to achieve this I have to suppress the projects pulling in their dependent DLLs, by flagging those dependencies as "Copy Local" "No" and "Copy Local Satellite Assemblies" "No".

This was working fine under VS 17.8. After updating to 17.9 I found all the "Copy Local" settings had vanished and I had to manually reinstate them on some 120 project references.

However, after reinstating them I have encountered this new bug, as follows:

1. If I delete the sub-folder of DLLs and then run the solution, it correctly re-generates the DLLs in the sub-folder, and respects the "Copy Local" settings.
2. If I then close the executable, then re-run it (doing nothing else in the mean time), it then copies all the dependency DLLs - that are flagged as "Copy Local" "No" - into the sub-folder. This causes the dynamic loading logic to throw an exception.
3. If I then exit the program and delete the sub-folder (as in 1. above), running the solution will once again correctly re-generate the sub-folder without the dependency DLLs.
4. There is no Directory.Build.props file anywhere in the solution.
5. If I add a Directory.Build.props file, and in it explicitly set "AccelerateBuildsInVisualStudio" to "false" and "ProduceReferenceAssembly" to "false", then the problem no longer occurs.

My conclusions from this are:

• The build acceleration logic appears to be ignoring "Copy Local" settings when deciding to copy dependencies.
• The default behaviour for build acceleration has changed from "opt in" to "opt out".

Steps to Reproduce

See description above.

Expected Behavior

1. Dependencies flagged as "Copy Local" "No" are never copied to the output folder regardless of build acceleration.
2. Build acceleration is "opt in" as per the documentation (or a nice clear setting is added to the solution or project properties)

Actual Behavior

See above description

User Impact

Severe impact on productivity without the Directory.Build.props workaround in place, as the sub-folder for DLLs has to be manually deleted each time you want to run the app in the debugger.

[adamint]

@drewnoakes for investigation

[drewnoakes]

@Maintenance-Partnership-Systems can you include the build output log for a project that is building incorrectly please? You'll need to turn on verbose up-to-date check logging.

It would also be helpful if you showed how to reproduce this bug. If you can't share your code, could you recreate a small solution, perhaps just with two projects, that shows the situation you're describing?

[Maintenance-Partnership-Systems]

can you include the build output log for a project that is building incorrectly please?

Having fixed it so it now builds correctly, I am reluctant to break it again.

could you recreate a small solution

I'm not having any luck re-creating the behavior with a new solution. The solution in which it occurred is very old - started back in 2013 - so has gone through many updates and iterations, until it is now running under .NET 7.0; so there could be all sorts of legacy settings floating around in there.

I'll poke at it a bit more, and look at whether I can revert out the changes I made to fix the issue, and then re-run it with logging.

[GomezAa-Bently]

I am also facing this issue and have created a repo to showcase the issue I am facing. Please see the readme. Microsoft support investigated my repo and determined that the Build Acceleration preview feature was causing my issue.

https://github.com/GomezAa-Bently/BuildOutputProblem

[drewnoakes]

@GomezAa-Bently thank you very much for the detailed repro. I will take a look. I see you're using a common output folder.

@Maintenance-Partnership-Systems are you using UseCommonOutputDirectory as well?

[Maintenance-Partnership-Systems]

@Maintenance-Partnership-Systems are you using UseCommonOutputDirectory as well?

Yes; I checked in my csproj files and that setting is present and set to "true"

[drewnoakes]

I suspect that's central to the problem here. Thanks for confirming.