Question about Microsoft.NET.Build.Tasks references in preview SDKs

[daveaglick]

I noticed the preview SDK doesn't include the assemblies that Microsoft.NET.Build.Tasks.dll depends on in the tools folder any more. At least they're not there in 2.1.300-preview1-008174, though it does look like they were there in 2.1.200-preview-007474.

I also noticed the target for the SDK tools in 2.1.300-preview1-008174 switched to netcoreapp2.0 from netcoreapp1.0 which might have something to do with it.

I curious, but also this is causing some problems for me. When building with the MSBuild APIs, builds are failing whenever the preview is installed with:

C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018: The "ReportAssetsLogMessages" task failed unexpectedly.
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.Common, Version=4.7.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018: File name: 'NuGet.Common, Version=4.7.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.NET.Build.Tasks.LockFileCache.LoadLockFile
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.NET.Build.Tasks.LockFileCache.GetLockFile
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ReportAssetsLogMessages.get_LockFile
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ReportAssetsLogMessages.ExecuteCore()
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute()
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() in E:\A\_work\82\s\src\Build\BackEnd\TaskExecutionHost\TaskExecutionHost.cs:line 631
    C:\Program Files\dotnet\sdk\2.1.300-preview1-008174\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(337,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext() in E:\A\_work\82\s\src\Build\BackEnd\Components\RequestBuilder\TaskBuilder.cs:line 787

I suspect that's because Microsoft.NET.Build.Tasks.dll can no longer find NuGet.Common.dll next to it. Builds do succeed when not using the MSBuild API and instead using dotnet build or VS directly, which makes me wonder if there's an extra MSBuild property or something I should be setting.

[livarcocc]

When the CLI runs a build, we set MSBuildExtensionsPath to the location of the msbuild.dll (which for now, happens to be under the same place as dotnet.dll.

I believe that's what you are missing now that the NuGet assemblies are no longer next to the tasks dll.

By the way, you should take a dependency on the layout of the SDK files, as that can change at any time.

[daveaglick]

I've got that one covered (though I have to set it myself before calling the MSBuild APIs):

I personally haven't taken a dependency on the SDK layout, but it's possible that the MSBuild APIs have. At a minimum, it appears that the Microsoft.NET.Build.Tasks.dll assembly is looking for it's NuGet.Core.dll dependency and can't find it.

[daveaglick]

FWIW, here's the Microsoft.NET.Build.Tasks.dll references that can't be found:

Though obviously they exist somewhere because running dotnet build works fine with the preview. I guess I'm curious at this point how that works? When a task from this assembly is run, how does MSBuild normally locate the task's references (does MSBuild have a custom assembly resolver)? I did find versions of these references alongside MSBuild.dll in the root of the SDK - I assume those are the ones that normally get picked up from a CLI/VS build (perhaps the application base is set there so normal assembly loading finds them)?

[daveaglick]

I've compared the binary log output from a working build (using dotnet build) and a failing build (using the MSBuild API) of the same project and there weren't many differences. I think I'm getting a handle on what's going on here (sorry for the length, but wanted to be detailed for my own future reference if nothing else):

• References for task assemblies are resolved using normal assembly probing (I.e., looking in the application base, it's subdirectories, and the directory of the referencing assembly).
• When running MSBuild directly via dotnet build or VS the application base is set to the location where MSBuild resides (which for all the SDKs I have appears to be the root of the SDK).
• The assemblies that Microsoft.NET.Build.Tasks.dll references are contained in the root folder of the SDK alongside the MSBuild.dll file for every SDK I have, but more importantly that's also the application base where assemblies are probed for CLI/VS builds.
• The assemblies that Microsoft.NET.Build.Tasks.dll references are also included alongside the Microsoft.NET.Build.Tasks.dll assembly for all but the most recent previews. This puts them in the assembly probing path if references can't be found in the application base.

So this all works fine when building from CLI/VS and the assemblies alongside Microsoft.NET.Build.Tasks.dll are never selected for load because the ones in the root of the SDK alongside MSBuild.dll are found first. However, the previews break when attempting to build via the MSBuild APIs:

• The MSBuild API (NuGet packages Microsoft.Build.*) runs in-process with the consuming application.
• That means the application base is set to that of the caller and not the directory where MSBuild.dll is located.
• When the in-process MSBuild API attempts to locate referenced assemblies for tasks, it probes the assembly base which is no longer pointing to the root of the SDK folder where those references live. Since it can't find them there, it probes the location of the referencing assembly.
• Up until the recent previews, those referenced assemblies also existed alongside the Microsoft.NET.Build.Tasks.dll assembly so the in-process MSBuild API could find them and load them. Now they don't so assembly loading fails and those tasks fail.

No idea if I've got this correct - could use a sanity check. If this actually is what's going on, it suggests that if the preview ships as-is, the MSBuild APIs will no longer work. I'd consider that a regression and a bug - though I don't know if it belongs in the SDK or with MSBuild.

[livarcocc]

It should be possible to tell msbuild where to load these assemblies from. @rainersigwald any ideas?

I would rather not force the .NET Core SDK to carry duplicate assemblies as much as possible, specially considering that the dotnet/sdk and dotnet/cli will be effectively the same repo sooner rather than later.

[chaami]

Hi,
I have a bonus question:
I am trying to build an older MVC applications build through the dotnet build (or dotnet msbuild) for the matter.
From what I can seem the build works fine on Visual Studio thanks to the import of Microsoft.WebApplication.targets.
This import leverages the MSBuildExtensionsPath property to compute a path to these targets.
Thanks to your comment, I now understand why the path is completely out in space... However, how is this supposed to work now ? Have I missed a piece of documentation somewhere ?
Hard Setting the path for the import fails anyways on a The "Microsoft.Build.Tasks.AspNetCompiler" task could not be loaded.
I suspect that a dependency fails to be loaded for the same reasons that @daveaglick initially.
Any insight is welcome !

When the CLI runs a build, we set MSBuildExtensionsPath to the location of the msbuild.dll (which for now, happens to be under the same place as dotnet.dll.

I believe that's what you are missing now that the NuGet assemblies are no longer next to the tasks dll.

By the way, you should take a dependency on the layout of the SDK files, as that can change at any time.

[Piedone]

Did you figure this out @chaami? Same thing here. MVC view builds break via dotnet build due to this.

[chaami]

Hi @Piedone ,
The only way out of this mess was switching to the new project format.
Somehow this made the dotnet build command do the right thing...
I guess there is something broken while handling the legacy csproj format...
To be honest I didn't check that the AspNet pages are compiled through those builds, but my understanding is that's automatic in the dotnet publish...
Good luck ;-)

[Piedone]

I see, thanks! I did consider migrating to the new project format but it seems we can't just do it currently due to completely unrelated reasons.