Build failure related to dependencies in a mixed solution

[sharwell]

After converting a subset of projects from legacy project system to new in antlr/antlrcs@4b0ae50, I found that the build failed due to a file access error until I turned off parallel builds (removed /m) in antlr/antlrcs@407a344. I'm guessing this is caused by a failure to properly track dependencies when the build contains both legacy and new projects.

I was not able to reproduce this locally in Visual Studio, but the AppVeyor build was consistently failing with the /m flag.

[rainersigwald]

What version of VS/msbuild, and was the file that caused the error referenced by a non-SDK project?

(I suspect that this is related to dotnet/sdk#1453)

I also don't understand what you mean by

I'm guessing this is caused by a failure to properly track dependencies when the build contains both legacy and new projects.

Can you clarify?

[Tasteful]

@rainersigwald I got the same error today and it is only happening when running msbuild from command line.

My structure (simplified, original solution is 45 projects)

• Project A - legacy project format, TFM net461
• Project B - legacy project format, TFM net461 Reference project A
• Project C - new project format, TFM net461;netstandard1.6
• Project D - new project format, TFM net461 Reference project A and C

CSC : error CS0009: Metadata file 'C:\tfs\Company\Src\Project.A\bin\Release\Project.A.dll' could not be opened -- The process cannot access the file 'C:\tfs\Company\Src\Project.A\bin\Release\Project.A.dll' because it is being used by another process. [C:\tfs\Company\Src\Project.D\Project.D.csproj]

The error is reproducable in both dev and build server environment for my solution.

Dev environment

• Visual Studio 2017 (15.3 Preview 7) Enterprise
• Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework

Build server

• Visual Studio Build Tools 2017 (15.2)
• Microsoft (R) Build Engine version 15.1.1012.6693

Do you wish me to send link to msbuild.log file by mail to you? (will not attach it here because I don't know if log file contains sensitive information)

[johnkoerner]

I believe I am also seeing this behavior. I too am moving from the old project file format to the new project file format in a large solution. My theory on what is happening is that the different project file formats specify different build properties (i.e. TargetFramework vs TargetFrameworkVersion) and MSBUILD treats them as different builds. You then can run into concurrency problems in the build if the two builds of the same project happen at the same time. I asked this question on StackOverflow and my theory is based on this answer

Is my understanding of what is going on correct? I'd be open to ideas of how to work around this that don't involve turning off concurrency or having to convert everything to the new file format.

[johnkoerner]

@rainersigwald I can reliably reproduce this issue in a small demonstration solution: https://github.com/johnkoerner/MsBuildConcurrencyProblems

This has 2 C# apps each using different types of csproj files and one C++ CLI library that is used by both. The reason I used a C++ CLI library is that it tends to take longer to build and increases the likelihood of problems happening. (And that is the setup that is causing problems on one of my solutions).

[rainersigwald]

@johnkoerner nice repro! I'll send a PR with the fix.

Workaround

Add the metadata GlobalPropertiesToRemove=TargetFramework to your ProjectReference items in multitargeted projects.

For example,

diff --git a/C.DualTargetLibrary/C.DualTargetLibrary.csproj b/C.DualTargetLibrary/C.DualTargetLibrary.csproj
index d2ae080..09e9603 100644
--- a/C.DualTargetLibrary/C.DualTargetLibrary.csproj
+++ b/C.DualTargetLibrary/C.DualTargetLibrary.csproj
@@ -5,7 +5,7 @@
   </PropertyGroup>
 
   <ItemGroup Condition="'$(TargetFramework)'=='net471'">
-    <ProjectReference Include="..\B.CppCLILibrary\B.CppCLILibrary.vcxproj" />
+    <ProjectReference Include="..\B.CppCLILibrary\B.CppCLILibrary.vcxproj" GlobalPropertiesToRemove="TargetFramework" />
   </ItemGroup>
 
 </Project>

[rainersigwald]

I do not reproduce this on 15.7 + .NET Core SDK 2.1.300-rc1 using @Tasteful or @sharwell's repro steps, so I think @johnkoerner's .vcxproj repro is all that remains. If you think otherwise, I'd love to see a repro case.