-
Notifications
You must be signed in to change notification settings - Fork 325
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
Incremental builds are broken when using the Microsoft.NET.Test.Sdk package #3266
Comments
@drognanar this seems like something that would be right up your alley. Would you mind having a look? |
I'm noticing the same issue with 16.11.0. The double copy seems to stem from:
which both contain |
I'm running into this now. Does anyone have a good workaround? |
@shueybubbles We internally assigned this to @drognanar. Artur do you have some update please? The description here seems to be enough to repro find a potential fix. |
Ran into this as well while investigating why our incremental build was broken.
This is because both The shared .dll(s) need to go into their own package(s) and a dependency needs to be added from all packages that depend on it. |
FWIW My workaround is to greatly increase the size of my build by putting the output of every test project in its own subfolder. We run the tests as part of the build, so this double write was blocking test runs due to the file copy being blocked by currently running tests.
|
Ping @drognanar |
Closing via #3722 |
Due to microsoft/vstest#3266 if a unit test is running it can cause the build to fail because the tests all compile to the same folder. This change moves unit test builds into their own per-project folder. It greatly increases the disk space used by the build but eliminates the race condition.
Now that 17.4.1 has a fix for microsoft/vstest#3266 we can stop putting unit test DLL build output in separate subfolders. This should reduce the build size and generate correct code coverage information for unit tests.
Description
When building a test project which references the
Microsoft.NET.Test.Sdk
nuget package, incremental builds are broken because of double writes:Steps to reproduce
Expected behavior
There shouldn't be any double writes observable in the msbuild binary log file (which can be opened with the msbuild log viewer).
Actual behavior
The msbuild binary log viewer shows double writes (see picture above) which causes incremental builds to be broken which means that the affected test library needs to always be fully rebuilt. This is especially noticeable for customers when having many test assemblies which are built (i.e. via a sln file).
Diagnostic logs
Not required as this is about building and not running any tests so the test adapter isn't even invoked.
Environment
Windows, SDK version
6.0.200-preview.21617.4
.cc @nohwnd
The text was updated successfully, but these errors were encountered: