Directory.Build.props is ignored in classic. non-SDK project for Service Fabric service

Issue description

I spoke to the Service Fabric team (@ravipal, @dbreshears, @msnider) and they concluded that it's an issue with rather MSBUild than than with Service Fabric tooling.

The issue is that a variable set in Directory.Build.props and used as OutputPath in a project for Service Fabric service is miscalculated. It's one of:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ (when VS is not under admin)
C:\WINDOWS\system32\ (when it is)

The issue doesn't occur in modern, SDK-based project of the exactly same configuration.

Steps to reproduce

Either include a project sample, attach a zipped project, or provide IDE / CLI steps to create the project and repro the behavior. Example of a project sample:

Project file (the most important piece):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputPath>$(InetRoot)\drop\$(ServiceName)</OutputPath>
  </PropertyGroup>
</Project>

and Directory.Build.props content:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <InetRoot>$(MSBuildThisFileDirectory.TrimEnd('\\'))</InetRoot>
  </PropertyGroup>
</Project>

Directory contents:

/
- Directory.Build.props
- TestAgent.sln
- src/
     - TestAgent/
         - TestAgent.csproj
    - TestAgent.Application/
        - TestAgent.Application.sfproj

Fulll content: TestAgent.zip

Command line

Visual Studio (under admin) -> select Service Fabric Project -> F5

Expected behavior

The project is getting built, packaged, deployed to local cluster.

Actual behavior

Could not find a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\drop\TestAgent_VS_ServiceFabric_lock.txt'.

Could not find a part of the path 'C:\WINDOWS\system32\drop\TestAgent_VS_ServiceFabric_lock.txt'.

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Framework

OS info:

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc):

Microsoft Visual Studio Enterprise 2019 Version 16.5.3
VisualStudio.16.Release/16.5.3+30002.166
Microsoft .NET Framework Version 4.8.03752
Installed Version: Enterprise

Microsoft Azure Service Fabric Tools for Visual Studio   16.0
Microsoft Azure Service Fabric Tools for Visual Studio

This is not a bug in MSBuild. The import of Directory.Build.props is defined in Microsoft.Common.props,

https://github.com/microsoft/msbuild/blob/50a8d8348b74eab030681c95efc79c79aff0c1e5/src/Tasks/Microsoft.Common.props#L32

TestAgent.csproj that you shared doesn't import that until the end of the project (through a chain of imports starting with $(MSBuildBinPath)\Microsoft.CSharp.targets). Therefore, the $(INetRoot) property isn't defined at the point in where it is referenced (because properties are defined top-to-bottom in the evaluation).

Older csproj templates skipped the .props import at the top of the file. Newer ones include it, and are generally happier with Directory.Build.props. I was able to change the behavior of your project with this patch:

diff --git a/src/TestAgent/TestAgent.csproj b/src/TestAgent/TestAgent.csproj
index ce62cda..f42b254 100644
--- a/src/TestAgent/TestAgent.csproj
+++ b/src/TestAgent/TestAgent.csproj
@@ -1,5 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
 <Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
   <PropertyGroup>
     <ServiceName>TestAgent</ServiceName>
     <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

dotnet / msbuild