sdk: Setting BaseIntermediateOutputPath breaks netstandard2.0 builds

Setting BaseIntermediateOutputPath breaks netstandard2.0 builds

I have a solution with multiple projects. These import a common properties file (as the first thing in the project file), which set BaseIntermediateOutputPath (along with IntermediateOutputPath and OutputPath) in order to have build artifacts outside the source tree. This has so far worked fine.

However, with the 2.0 SDK, this breaks when targeting netstandard2.0; none of the types from the standard libraries are found. As such, this seems related to #803; however, the same problem does not occur when targeting netcoreapp2.0 (which I would assume to have the same basic setup).

Steps to Reproduce

run: dotnet new classlib
delete the obj folder
edit project file, adding <BaseIntermediateOutputPath>foo\</BaseIntermediateOutputPath> (any value works as long as it’s not obj\)
run: dotnet restore this correctly creates the relevant files in foo\
run: dotnet build lots of CS0518 and CS0246 errors ensue

Partial Workaround

To a certain extent this can be worked around by explicitly adding PackageReference entries for the needed standard library assemblies (e.g. adding System.Runtime 4.3.0 makes the basic classlib sample compile). Note that adding a reference to NETStandard.Library 2.0.0 does not help; that results in a build warning plus the same compilation issues). However, for some new APIs (e.g. SerializableAttribute and ExternalException) it does not seem so obvious to find which packages to reference (the API docs list assemblies, not packages; neither System.Runtime nor System.Runtime.InteropServices provides ExternalException, despite what the docs suggest).

Note that without #1486 I could probably just customize RestoreOutputPath instead (unless there are other files that are created via BaseIOP instead of IOP/ROP/OP).

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 16 (8 by maintainers)

Most upvoted comments

It is generally unsafe to set BaseIntermediateOutputPath in the “main body” of a project.

There are two workarounds at the moment:

Create a Directory.Build.props file at project or solution level that define the variable:

<Project>
  <PropertyGroup>
    <BaseIntermediateOutputPath>$(MSBuildThisFileDirectory)obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
  </PropertyGroup>
</Project>

This file will be automatically imported by all projects in the directory tree early enough to set the property (= imported in the Microsoft.Common.props file before it uses BaseIntermediateOutputPath).

Move from the <Project Sdk=".."> syntax to explicitly importing the Sdk’s props and targets file and set the property early in the project file:

<Project>
  <PropertyGroup>
    <BaseIntermediateOutputPath>some\other\dir\</BaseIntermediateOutputPath>
  </PropertyGroup>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <!-- All your project's other content here -->

  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

+14

dasMulli on Aug 24, 2017

The More You Know

Option 2 worked great!

I’m going to try option 1 out later because that seems like it could be shared better across a solutions projects.

hartmannr76 on Aug 24, 2017

@rraallvv the Configuration property is either set by the project system loading a project or defaulted in the project file itself, so you’d need to add a default for Configuration:

  <PropertyGroup>
    <Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
    <BaseIntermediateOutputPath>$(MSBuildThisFileDirectory)obj\$(Configuration)\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
  </PropertyGroup>

This default would be performed by the time Sdk.props is imported, but in case a Directory.Build.props is used or msbuild properties are placed above the sdk import, they won’t see this default when setting properties.

dasMulli on Feb 12, 2018