Sdk: Blocking issues for the conversion of CLI to MSBuild

[eerhardt]

This issue is meant for tracking all of our external blocking issues that are preventing the CLI to work on MSBuild.

• [x] https://github.com/NuGet/Home/issues/3102 - dotnet restore doesn't install custom MSBuild targets
• [x] https://github.com/NuGet/Home/issues/3117 - Convert NuGet.BuildTasks to .NET Core (and create a NuGet package for CLI to consume them)
• [x] https://github.com/NuGet/Home/issues/3136 - ResolveNuGetPackageAssets doesn't handle RIDs correctly
• [x] https://github.com/dotnet/roslyn-project-system/issues/296 - Need to split up ResolveNuGetPackageAssets in MSBuild
• [x] https://github.com/dotnet/roslyn/issues/9640 - Publish a portable tasks+targets nuget package for the compiler build task and use it in the toolset
• [x] https://github.com/dotnet/roslyn/issues/12650 - Create a NuGet package containing CSharp.targets that can build on .NET Core
• [x] https://github.com/Microsoft/msbuild/issues/774 - .nuget.props/.targets are not loaded on .net core
• [x] https://github.com/Microsoft/msbuild/issues/692 - create NuGet packages for MSBuild assets
• [x] https://github.com/Microsoft/msbuild/issues/720 - csc.exe needs a "host" for cross-plat MSBuild. MSBuild should just use the host it is running under
• [x] https://github.com/Microsoft/msbuild/issues/658 - custom Tasks loading dependencies
• [x] https://github.com/Microsoft/msbuild/issues/784 - generic loading .props and .targets files next to the .csproj file (non-NuGet specific)
• [x] https://github.com/Microsoft/msbuild/issues/970 - Excludes against Includes with globs don't work on OS X
• [x] https://github.com/NuGet/Home/issues/3462 - ToolsRef design

Non-blocking issues, but needed for shipping:

• [ ] https://github.com/dotnet/roslyn/issues/12167 - Csc.exe without -nologo requires Microsoft.CodeAnalysis.dll in BaseDirectory
• [ ] https://github.com/Microsoft/msbuild/issues/750 - Native image cannot be loaded multiple times
• [x] https://github.com/Microsoft/msbuild/issues/872 - msbuild.exe.config needs to be packaged

[Sarabeth-Jaffe-Microsoft]

Hi @eerhardt thanks for opening this issue. Should help us stay organized to unblock you guys.

[anurse]

Can we consider https://github.com/Microsoft/msbuild/issues/658 as blocking this? I don't think we can consider the CLI capable of launching MSBuild scripts if custom task dependencies don't work :)

[eerhardt]

@anurse - I tend to agree. That is a serious issue that most custom tasks are going to hit.

[tmeschter]

@anurse @eerhardt FYI I've marked dotnet/cli#658 as complete.

[brthor]

👀

[borgdylan]

Will this be using the .NET Core version of MSBuild only? I have a use case where .NET CLI calls my dotnet-compile-dnc process that runs on mono (my compiler is not ported to .NET Core at the moment). In that case I will be forced to port the compiler to .NET Core which may hit issues like unavailable APIs.

[anurse]

Even if it only uses the .NET Core version of MSBuild (I don't know either way if there are plans to allow other versions of MSBuild to be used), you would definitely be able to invoke a mono-based compiler. MSBuild just shells out to compiler processes so you'd just need to be build a .NET Core MSBuild task that invokes your mono-hosted compiler.

[borgdylan]

Would it support error redirect?

[borgdylan]

I am asking as current I support mono's xbuild by hosting the compiler in process inside a task.

[anurse]

I'd caution against hosting the compiler in-process in MSBuild since it puts you on the hook for figuring out all the isolation. csc is hosted completely out-of-process in MSBuild, but there is an in-proc Csc MSBuild task that invokes csc.exe, providing the necessary parameters, reads the output of the compilation and generates the necessary MSBuild data (errors, items, properties etc.)

I do know that by default, if you write to stderr and use the MSBuild Exec task, it should capture those messages as errors. Returning a non-zero exit code is interpreted as a failing task.

Anyway, to the topic at hand, I don't know the plans for allowing the use of other MSBuild variants (Core/Desktop/Mono) in dotnet build but either way, architecting tasks around invoking exes would give you the most flexibility since you can launch any kind of exe you need :).

[borgdylan]

Thats is a good idea. After all it hows the CLI works today.

[tuespetre]

Would anyone from the ASP.NET team be willing/able to share a rough concept of what dotnet-* tools are going to look like after the move to MSBuild?

[eerhardt]

All of the blocking issues in this list have been checked off. This can now be closed.