dotnet / dotnet/project-system
Visual Studio Build Acceleration not respecting "Copy Local" setting on dependencies.
- Dominant language
- C#
- Stars
- 1k
- Forks
- 415
- PR merge metrics
- No merged PRs in 30d
Description
## 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.
Contributor guide
Assessment
This issue has not been assessed yet.