In MSBuild xplat pass through path to msbuild.exe host as a property

[brthor]

This will solve the issue of needing to set an environment variable in the cli when invoking msbuild.exe so the same host can be used to execute csc.exe.

@cdmihai @rainersigwald

[cdmihai]

Can you please detail more?

Are you suggesting that each ToolTask has a way to access the host that MSBuild is run under? I guess there's a couple of ways to do it:

• opt in: ToolTasks choose their own host, and they may choose to use MSBuild's host via some protected field
• opt out: ToolTasks are automatically run under the same host as MSBuild's and they have the option to opt out.
• all the above: Opt in by default. Opt out by cmd line flag: MSBuild --RunTasksInMSBuildHost

[brthor]

@cdmihai

The motivating scenario here is that the Csc tooltask needs to explicitly have the host overridden by the cli when executing under dotnet.exe to prevent a file not found for corerun.exe. In general this seems like it would be common scenario for tools.

With that in mind, I think that your option 2 seems most appropriate. ToolTasks would automatically be run under the host msbuild is being run under with the override gesture being reserved for cases where that isn't appropriate or some customization needs to happen.

[jeffkl]

At some point, csc.exe could become a stand-alone app and not need to run under dotnet.exe. We might need logic to detect if the app that's about to run is a .NET Core assembly before running it under dotnet.exe as well.

@eerhardt also mentioned that Roslyn might be recommending people wrap execution in a batch script like csc.cmd which explicitly runs the app under dotnet.exe.

All that said, I still think we should at least expose the host as a property to tasks. I'm not convinced yet that there is a good way to determine whether or not the app should run under the same host though...

[eerhardt]

This is no longer necessary for the CLI in Visual Studio 15 RC. The Roslyn team recommends to ship "wrapper" csc.cmd and csc.sh files that invoke the managed Csc assembly using the dotnet host executable. The CLI does this, and sets the CscToolExe property to tell the Csc ToolTask to use this wrapper file.

From the perspective of the CLI, this issue can be closed. (I don't have permissions to close issues in this repo.)

[rainersigwald]

Is that the general "how you should run a managed tool in a build" advice, @eerhardt? csc.exe is probably the most important tool but I expect there to be many others in this situation.

[eerhardt]

I'm not sure if that is the general advice. But this is the advice for invoking csc.exe I got from conversations with @agocke.

The generalized approach being employed by the Roslyn team here is for a ToolTask to allow the caller to pass in the path and name to the executable to invoke. This seems like a fine approach in general to me. The caller can and will have more context to where the tool is in their scenario. And if the ToolTask is unable to figure it out, at least it gives the caller an "escape hatch".

[borgdylan]

I agree on using batch files. I happen to have a compiler to only runs on .NET/Mono which cannot be run on .NET Core (even if it supports it as a target) and the batch file method would allow me to use it with the new cross-plat MSBuild.

[rainersigwald]

To be clear @borgdylan, it's a hard requirement that users be able to execute a script or native binary in a ToolTask--that works today and we have no intention of breaking it.

This issue is about making it easier to run .NET Core applications. Right now that requires either modifying the project file or using a wrapper script as the tool (and that wrapper script has no way to determine "the CLI host that is currently running MSBuild" which is probably the most common scenario).

[jeffkl]

So should we consider this solved by way of using batch files? Or should we expose a property that indicates the path to the CLR host?

[jeffkl]

The community has spoken and we're going to leave it up to task authors for now. We'll gladly revisit this if enough people feel like they need support for it.

[VSadov]

Re; aspnet/KestrelHttpServer#1748

Had to propagate dotnet location to run Csc.exe from a task by forcing it to be on the PATH. And had to do that in two environments - regular run and in a docker. Took some time to figure why one fails and not another (was using different PATH env).

It could be more convenient to use a property.