Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable out of proc TaskHost on .NET Core #5158

Closed
Forgind opened this issue Mar 4, 2020 · 1 comment · Fixed by #6994
Closed

Enable out of proc TaskHost on .NET Core #5158

Forgind opened this issue Mar 4, 2020 · 1 comment · Fixed by #6994
Assignees
Labels
Area: Engine Issues impacting the core execution of targets and tasks. Area: TaskHost .NET Core triaged
Milestone

Comments

@Forgind
Copy link
Member

Forgind commented Mar 4, 2020

Try enabling the test in #5144 on core and running it. It currently breaks with the error:

error MSB4216: Could not run the "ProcessIdTask" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64".  Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files\dotnet\sdk\3.1.200-preview-015002\MSBuild.exe" exists and can be run.
@rainersigwald rainersigwald changed the title Port TaskHost to Core Enable out of proc TaskHost on .NET Core Mar 4, 2020
@rainersigwald rainersigwald added .NET Core Area: Engine Issues impacting the core execution of targets and tasks. labels Mar 4, 2020
@rainersigwald rainersigwald added this to the .NET 5 milestone Mar 4, 2020
@rainersigwald
Copy link
Member

Related feature flags: FEATURE_TASKHOST. NO_MSBUILDTASKHOST should remain off for Core; we won't support .NET 3.5 tasks on Core.

@rainersigwald rainersigwald modified the milestones: .NET 5, 17.0 Jun 15, 2021
@marcpopMSFT marcpopMSFT modified the milestones: 17.0, MSBuild 17.1 Jul 9, 2021
ladipro added a commit to ladipro/msbuild that referenced this issue Sep 2, 2021
@rainersigwald rainersigwald self-assigned this Oct 25, 2021
Forgind pushed a commit that referenced this issue Nov 15, 2021
Fixes #5158

Context
A task author can force any task to run out of process by specifying that it must run with TaskFactory="TaskHostFactory". But we never made this work on .NET Core; it fails with an error like

S:\msbuild\foo.proj(8,5): error MSB4216: Could not run the "Message" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64".  Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "S:\msbuild\.dotnet\sdk\6.0.100-rc.1.21458.32\MSBuild.exe" exists and can be run.
That's because the "default" task host runtime was hardcoded to be CLR4 (even when on .NET 6.0+).

Changes Made
Created GetCurrentMSBuildRuntime() and used it; plumbed the new value around and checked for it in a few places. Eliminated FEATURE_TASKHOST since it's on everywhere now. Unified the named-pipe-name computation code (before it was using a different pipe name for taskhost pipes on UNIX).

Testing
Re-enabled tests for this behavior that have been disabled on .NET Core. Extended some to account for the NET runtime.

Specific steps:

* Enable out-of-proc TaskHosts on .NET Core

* Promote FEATURE_TASKHOST to no-flag-needed

This enables taskhost tests on .NET Core. Includes a couple of low-
complexity test fixes.

* Enable checking runtimetype in .tasks file

* Check runtime type in tasks file

* Extend TestRuntimeValuesMatch for net

* Extend RuntimeValuesMatch for net

* Split and shouldly-ify TestMergeRuntimeValues

* Use explicit current runtime/arch in CreatableByTaskFactoryMatchingIdentity

* Unify to NamedPipeUtil.GetPipeNameOrPath
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Engine Issues impacting the core execution of targets and tasks. Area: TaskHost .NET Core triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants