Tools 1.0.0-msbuild3-final does not work when BaseIntermediateOutputPath is set

[caleblloyd]

I have changed the locations of the bin and obj folders in my application:

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <BaseIntermediateOutputPath>..\..\obj\App</BaseIntermediateOutputPath>
    <BaseOutputPath>..\..\bin\App</BaseOutputPath>
  </PropertyGroup>

ERROR 1

$ dotnet ef migrations add initial -v
Using project '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj'.
Using startup project '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj'.
Writing '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/obj/App.csproj.EntityFrameworkCore.targets'...
System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/obj/App.csproj.EntityFrameworkCore.targets'.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Interop.CheckIo[TSafeHandle](TSafeHandle handle, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
   at System.IO.UnixFileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, FileStream parent)
   at System.IO.UnixFileSystem.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, FileStream parent)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at Microsoft.EntityFrameworkCore.Tools.Project.FromFile(String file, String buildExtensionsDir, String framework, String configuration)
   at Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute()
   at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
   at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)

This is because it is sitll looking in <project root>/obj. It should be reading the BaseIntermediateOutputPath though.

ERROR 2

If I create obj in my project root to get past Error 1, the migration creation script hangs indefinitely:

$ mkdir obj
$ dotnet ef migrations add initial -v
Using project '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj'.
Using startup project '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj'.
Writing '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/obj/App.csproj.EntityFrameworkCore.targets'...
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=/tmp/tmpy2PiZl.tmp /verbosity:quiet /nologo /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=/tmp/tmpr4WUgs.tmp /verbosity:quiet /nologo /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj
dotnet build /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/App.csproj /verbosity:quiet /nologo

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.91
dotnet exec --depsfile /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/App.deps.json --additionalprobingpath /home/caleb/.nuget/packages --runtimeconfig /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/App.runtimeconfig.json /home/caleb/.nuget/packages/microsoft.entityframeworkcore.tools.dotnet/1.0.0-msbuild3-final/tools/netcoreapp1.0/ef.dll migrations add initial --assembly /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/App.dll --startup-assembly /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/App.dll --project-dir /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/ --content-root /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/ --data-dir /home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/ --verbose --root-namespace App
Using assembly 'App'.
Using startup assembly 'App'.
Using application base '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1'.
Using content root '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/'.
Using root namespace 'App'.
Using project directory '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/src/App/'.
Using data directory '/home/caleb/Projects/caleb/dotnet-core-boilerplate/dotnet/bin/App/Debug/netcoreapp1.1/'.
^hangs indefinitely here

FULL RECREATE

git clone git@github.com:caleblloyd/dotnet-core-boilerplate.git
cd dotnet-core-boilerplate/dotnet/
dotnet restore
cd src/App/
dotnet ef migrations add initial -v

VERSION INFO

Operating Systems: Windows 10 x64 and Ubuntu 16.04 x64
Entity Framework Tools Version: Entity Framework Core .NET Command Line Tools 1.0.0-msbuild3-final
Dotnet CLI Version: 1.0.0-rc4-004771

[bricelam]

This is, unfortunately, a limitation in the way we interact with MSBuild. If you customize the MSBuildProjectExtensionsPath or BaseIntermediateOutputPath (its default value) properties, you must specify --msbuildprojectextensionspath for dotnet ef to work properly.

[caleblloyd]

I am trying to run a Docker container that has code mounted into it while also developing inside of an IDE. The IDE keeps running Dotnet Restore and conflicting with the Docker container's Dotnet Restore.

I have to do multiple mounts to exclude the bin and obj folders if they are in the default path, so I thought maybe I'd move them using BaseIntermediateOutputPath. But this causes Entity Framework Tools and dotnet test to not work properly.

Is this a common use case? Does anyone know a solution for it? I'm also going to ask NuGet/Home#4463 if there's any way to make the Host and Docker use a different project.assets.json file, since I can run different build configurations on the Host and Docker (e.g. run dotnet run -c Debug on the Host and run dotnet run -c Docker on Docker)

[bricelam]

Are the conflicts just runtime differences? You can restore for multiple runtimes using RuntimeIdentifiers:

<PropertyGroup>
  <RuntimeIdentifiers>win7-x64;debian.8-x64</RuntimeIdentifiers>
</PropertyGroup>

[caleblloyd]

I tried adding that, but I still get issues. A couple of the nuget related files have filepaths stored in them, which are different on the Host and on the Docker Container.

I've worked out a slightly complicated fix involving symlinking everything except for bin and obj directories that allows me to keep them in place.

[caleblloyd]

I closed the issue as I can workaround if this is how things must be. If you want this as an internal tracking issue feel free to reopen, I'm glad to test it if a solution is on the table at some point in the future.