Project-system: $(OutDir) unexpected behavior or $(OutDir) is undefined

[AlexeiScherbakov]

I have C# 'Microsoft.NET.Sdk' project in D:\Projects\Asm
Project is configured for multibuild for net40;net45;net47;netstandard2.0
It have <DocumentationFile>$(OutDir)\Asm.xml</DocumentationFile> parameter

Documentation files are generating in output dirs, but also in D:\Asm.xml

When I use:

    <PropertyGroup Condition="'$(OutDir)'!=''">
        <DocumentationFile>$(OutDir)\Asm.xml</DocumentationFile>
    </PropertyGroup>

No documentation files are generated

When project is located in standard location %userprofile%\source\repos\ project cannot be build (because it cannot write to C:\Asm.xml)

Workaround is use <DocumentationFile>bin\$(Configuration)\$(TargetFramework)\Asm.xml</DocumentationFile> but it makes sides effects when project is build not from Visual Studio

[wjk]

@AlexeiScherbakov Have you tried using $(OutputPath)\Asm.xml instead? IIRC $(OutDir) is a vcxproj-ism. It may or may not be defined in a csproj; best practice as I understand it is to use $(OutputPath) instead. (The equivalent of $(IntDir) is $(IntermediateOutputPath), by the way.) Hope this helps!

[AlexeiScherbakov]

$(OutputPath)\Asm.xml , $(IntDir)\Asm.xml ,$(IntermediateOutputPath)\Asm.xml also produces D:\Asm.xml

I also tried $(TargetDir)\Asm.xml

All variables are empty :-(

[Pilchie]

@AlexeiScherbakov does this happen for command line builds as well as from VS?

cc @nguerrera

[AlexeiScherbakov]

If I call msbuild from "Visual Studio 2017 Developer Command Prompt v15.5.2" it also creates D:\Asm.xml for $(OutDir) & $(OutputPath)

[wjk]

@Pilchie @AlexeiScherbakov And now it's happening for me too. ☹️ I'm using the command-line MSBuild included with Visual Studio for Mac, and both $(IntermediateOutputPath) and $(OutputPath) are blank.

VS information:

Visual Studio Community 2017 for Mac
Version 7.3.2 (build 12)
Installation UUID: f4ba95f3-b523-4d1e-a96f-e0510f81d032
Runtime:
    Mono 5.4.1.7 (2017-06/e66d9abbb27) (64-bit)
    GTK+ 2.24.23 (Raleigh theme)

    Package version: 504010007

NuGet
Version: 4.3.1.4445

.NET Core
Runtime: /usr/local/share/dotnet/dotnet
Runtime Version: 2.0.3
SDK: /usr/local/share/dotnet/sdk/2.0.3/Sdks
SDK Version: 2.0.3
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.4.1/lib/mono/msbuild/15.0/bin/Sdks

Xamarin.Profiler
Version: 1.6.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Apple Developer Tools
Xcode 9.2 (13772)
Build 9C40b

Xamarin.Mac
Version: 4.0.0.214 (Visual Studio Community)

Xamarin.iOS
Version: 11.6.1.2 (Visual Studio Community)
Hash: 6857dfcc
Branch: xcode9.2
Build date: 2017-12-04 21:20:41-0500

Xamarin.Android
Version: 8.1.0.25 (Visual Studio Community)
Android SDK: /Users/wjk/Library/Developer/Xamarin/android-sdk-macosx
    Supported Android versions:
        7.1 (API level 25)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 26.0.2
SDK Build Tools Version: 26.0.3

Java SDK: /usr
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Xamarin Inspector
Version: 1.3.2
Hash: 461f09a
Branch: 1.3-release
Build date: Tue, 03 Oct 2017 18:26:57 GMT
Client compatibility: 1

Build Information
Release ID: 703020012
Git revision: 7d0c9d7ad46b125cf4b7bbf9532c0531b6433ce6
Build date: 2017-12-12 14:03:18-05
Xamarin addins: 6dddaa49fbecb2695fcdcd6b712eb269e288518c
Build lane: monodevelop-lion-d15-5

Operating System
Mac OS X 10.13.2
Darwin 17.3.0 Darwin Kernel Version 17.3.0
    Thu Nov  9 18:09:22 PST 2017
    root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

Enabled user installed addins
AddinMaker 1.4.1
EditorConfig Support 0.1
Internet of Things (IoT) development (Preview) 7.1

[Pilchie]

Ping @nguerrera ?

[wjk]

@AlexeiScherbakov I think I've come up with a workaround! Here is a commit containing my exact technique. Apparently, the PrepareForBuild target must have run before the property containing the reference to $(OutputPath) or $(IntermediateOutputPath) is evaluated, or else the property will be blank. As far as I am concerned, this is still a glaring bug.

[nguerrera]

You should use <GenerateDocumentationFile>true</GenerateDocumentationFile> instead of <DocumentationFile>[path]</DocumentationFile> in SDK-based projects and the project system should be updated to use it: https://github.com/dotnet/project-system/issues/368

[Pilchie]

Resolving as a dupe of #368.

[AlexeiScherbakov]

It is not a duplicate of 368. Issue 368 is related to Documentation files. This issue is related to unexpected behavior of variables $(OutDir) & $(OutputPath)
I already post workaround for DocumentationFile in my issue description.

[dariogriffo]

@AlexeiScherbakov you have the workaround (almost) yourself, place this and should work for VS and non-VS builds

<PropertyGroup Condition="'$(OutDir)'==''">
  <OutDir>bin\$(Configuration)\$(TargetFramework)\</OutDir>
</PropertyGroup>

[kamit123]

<GenerateDocumentationFile>true</GenerateDocumentationFile> works for me. It places the xml file in the output directory by default.

[Egor92]

I had the same problem. In fact $(OutDir) has already have slash at the end. So you should write $(OutDir)Asm.xml instead of $(OutDir)\Asm.xml

[darthwalsh]

@Pilchie $(OutputPath) and $(IntermediateOutputPath) are documented properties on the official docs, and it feels wrong to need to reimplement them.

It seems like this issue should be reopened, or the docs should be updated with the workaround code.

[jmarolf]

@nguerrera should this be moved to the sdk?

[nguerrera]

No. There's nothing actionable for SDK that I can see. This is a fundamental to the order of msbuild evaluation. We can't make these properties accessible before we set them based on other properties in the .csproj.

The most common frustration is with the .xml file, which we designed GenerateDocumentationFile=true together as the solution pre-1.0, but the project system still hasn't done its part.

You have to set them yourself earlier if you want to be able to reference them earlier. Classic projects had OutputPath in the .csproj file.

[jmarolf]

@nguerrera I see, so the correct fix is for the project system to somehow define all of the common properties listed here?

[nguerrera]

@jmarolf No, I don't know what that would mean. I don't think there's anything to really "fix" other than #368

[voroninp]

@nguerrera Maybe you are right, and there's nothing to fix, but could you explain why $(OutDir) and $(OutputPath) yield C:\something.xml instead of bin/Debug/Platform/ ?