[Question] Can package references be referenced within a Task when running with dotnet build?

[Dresel]

Is it possible to use package references like Microsoft.CodeAnalysis within a Microsoft Build Task running with dotnet build?

I'm using netstandard1.5 for the task library and the following package references:

<PackageReference Include="Microsoft.Build" Version="15.3.0-preview-000117-01" />
<PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.3.0-preview-000117-01" />
<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="2.2.0" />

The consuming project is a netcoreapp1.1. The task fails with an

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.CodeAnalysis, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

exception.

When trying to load the package reference via AssemblyLoadContext.Default.LoadFromAssemblyPath I get

Could not load file or assembly 'Microsoft.CodeAnalysis, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

without any additional information. This does not work when running in a .net core console application either. I tried a second (simpler) package, which can be loaded via LoadFromAssemblyPath in a .net core console application, but still it does not work when running as dotnet build Task.

Both assemblies can be loaded when running in classical net4.6 with Assembly.LoadFile in a console application and when running as Task though.

[rainersigwald]

No, this isn't currently possible. Nothing can read the dependencies of the DLL delivers the task to correlate them with the dependencies of MSBuild itself and have the loader figure out what to load.

What you can do is redistribute the (closure of) dependencies of your task assembly in the same folder as the task, and MSBuild's loader will find them there.

I'm going to close this in favor of #1756 and whatever eventual design comes out of that.