[Broken Build]: Native DLL output deleted on IncrementalClean

[znakeeye]

Issue Description

I have a WPF exe project referencing a Library project which in turn references a Native DLL project. See attached sample project.

When rebuilding the solution, the output folder of the exe project contains all binaries:

MyLib.dll
NativeLib.dll
WpfApp2.dll
WpfApp2.exe

Then, perform any code change in the WpfApp2 project and Build it (F7 on my setup). The NativeLib.dll gets deleted. Using verbose logging, I can see that it incorrectly gets picked up in _CleanOrphanFileWritesInOutput processed by the IncrementalClean target.

Steps to Reproduce

See attached sample project.

SimpleApp.zip

Expected Behavior

Native DLL output should not be deleted when building solution.

Actual Behavior

Native DLL output is deleted when building solution.

In real-world solutions, this causes runtime errors. We have spent many days trying to debug issues that weren't real issues; the build is in fact broken.

Ask us questions

No response

[JaynieBai]

Repro it and binlog msbuild.binlog.txt

[yuehuang010]

Generally, the task/target that copies the NativeLib.dll to the output directory should also append to the "FileWrite" ItemGroup so that the Incremental Clean step won't delete it.

I wonder if this is the bug where building from the IDE and command line has different behavior.

[KalleOlaviNiemitalo]

It's "FileWrites", plural.

Which is not consistent with item types like "Compile" having been named with the singular form, but too late to change now.

[jzabroski]

Note, this is not necessarily the same issue as the one linked above just now.

In this issue, the problem is a Native DLL project.

In my issue, the problem is with nuget package Microsoft.Data.SqlClient.SNI copying Native DLLs from its buildTransitive folder to the build output directory, but subsequently gets deleted by IncrementalClean.

If a member of the nuget team can explain how does nuget normally handle this, I can try to pitch in and fix this. I tried to find the nuget targets that control restore but no success yet. I plan to search everywhere FileWrites is mentioned in my sdk path.

It does seem like there should be a simple item collection that automatically gets added to FileWrites by the Build step, or similar. As a simple thought, the item collection could be called <Runtimes> as we have a <Content> folder already that maps to the nupkg top-level folder \content\. Perhaps this already exists in some other form and I'm simply unaware.

[YuliiaKovalova]

Just to share on my progress on this topic and hopefully hear from you on possible ideas.

For the similarities between first and second build:

Ideally, based on _IsNativeEnvironment property presence, I would add it either to FieWrites or exclude from collection in InrementalClean.
I managed to add C:\Users\ykovalova\Downloads\SimpleApp\SimpleApp\x64\Debug\NativeLib.dll to FileWrites since it's visible in scope of GetCopyToOutputDirectoryItems execution, but I need preserve this path: \WpfApp2\bin\Debug\net6.0-windows\NativeLib.dll , that isn't available when I need it (inside of MSBuild task execution).

Now I am thinking about the ways on either passing \WpfApp2\bin\Debug\net6.0-windows to GetCopyToOutputDirectoryItems target or saving all project info with _IsNativeEnvironment =true and handle it in IncrementalClean.

[yuehuang010]

This looks similar to #9841. As a difference between IDE and cmd line when resolving outputs from the Project Reference. In the IDE, it calls GetTargetsPath target while the cmd line calls Build target. The GetTargetsPath target returns Returns="$(TargetPath)" which includes both managed and native. The Build target returns @(ManagedTargetPath) managed only, in this case, empty.

A simple change to Build target in Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VC\v170\Microsoft.BuildSteps.Targets to Returns="$(TargetPath)" to return NativeLib.dll. But there might unforeseen consequences.

[YuliiaKovalova]

As a temproary workaround, I would suggest neutering the in the box <Target Name="IncrementalClean" /> by putting the empty target to yours Directory.Build.targets .

[fforjan]

@YuliiaKovalova I tried with the workaround and this does not solve the visual studio build (but seems to solve the one in command line) (from issue #9841 )