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

Incremental builds are broken when using the Microsoft.NET.Test.Sdk package #3266

Closed
ViktorHofer opened this issue Jan 19, 2022 · 8 comments
Closed
Assignees

Comments

@ViktorHofer
Copy link
Member

Description

When building a test project which references the Microsoft.NET.Test.Sdk nuget package, incremental builds are broken because of double writes:

image

Steps to reproduce

dotnet new xunit -n xunittest
cd xunittest
dotnet build
dotnet build /bl

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

@nohwnd
Copy link
Member

nohwnd commented Jan 19, 2022

@drognanar this seems like something that would be right up your alley. Would you mind having a look?

@ktaeleman
Copy link

I'm noticing the same issue with 16.11.0. The double copy seems to stem from:

  • Microsoft.TestPlatform.TestHost's build folder being added to the Content ItemGroup of the test projects
  • The ResolvePackageAssets task adding the lib folder of Microsoft.TestPlatform.ObjectModel due to dependency on Microsoft.NET.Test.Sdk

which both contain Microsoft.TestPlatform.PlatformAbstractions.dll.

@shueybubbles
Copy link

shueybubbles commented Apr 21, 2022

I'm running into this now. Does anyone have a good workaround?
BTW it's not just incremental builds, it's happening on clean multi-targeting builds.
I can share a binlog internally. @nohwnd

@nohwnd
Copy link
Member

nohwnd commented Apr 22, 2022

@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.

@KirillOsenkov
Copy link
Member

Ran into this as well while investigating why our incremental build was broken.

Encountered conflict between 'CopyLocal:/Users/kirill/.nuget/packages/microsoft.testplatform.objectmodel/17.1.0/lib/netcoreapp2.1/Microsoft.TestPlatform.PlatformAbstractions.dll' and 'CopyLocal:/Users/kirill/.nuget/packages/microsoft.testplatform.testhost/17.1.0/lib/netcoreapp2.1/Microsoft.TestPlatform.PlatformAbstractions.dll'.
Choosing 'CopyLocal:/Users/kirill/.nuget/packages/microsoft.testplatform.objectmodel/17.1.0/lib/netcoreapp2.1/Microsoft.TestPlatform.PlatformAbstractions.dll' arbitrarily as both items are copy-local and have equal file and assembly versions.

This is because both Microsoft.TestPlatform.ObjectModel and Microsoft.TestPlatform.TestHost NuGet packages include Microsoft.TestPlatform.PlatformAbstractions.dll.

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.

@shueybubbles
Copy link

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.

<OutputPath>$(OutputPath)\$(MSBuildProjectName)</OutputPath>

@Evangelink
Copy link
Member

Ping @drognanar

@drognanar
Copy link
Member

Closing via #3722

shueybubbles pushed a commit to microsoft/sqlmanagementobjects that referenced this issue Mar 21, 2024
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.
shueybubbles pushed a commit to microsoft/sqlmanagementobjects that referenced this issue Mar 21, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants