dotnet / dotnet/msbuild

Analyzer: Task built in current build referenced without TaskHostFactory

Open
#9,197 1 comment 1 reaction 0 assignees View on GitHub
Area: BuildCheck BuildCheck Suggestion Feature: Warning Waves triaged
Dominant language
C#
Stars
5.5k
Forks
1.5k
Avg merge
1d 8h
Merged PRs (30d)
141

Description

It's fairly common for a repo to have need of a custom task to do something. In those cases it's easiest to define the task as a project within the repo and reference it in other projects that use it. But there's a common problem, which is that the default `UsingTask` configuration optimizes for the next build and keeps referenced assemblies in memory, locking their underlying files. This means that it's hard to change the task source code, because if it builds it tries to overwrite the (locked by the previous build) output .dll.

The [pattern to fix this](https://github.com/rainersigwald/build-task-in-solution-demo) is to specify `TaskHostFactory` to run the "private" task in a separate process, which ends (and frees filesystem locks) before the next build. But that's not _obvious_ and if you don't do it you can be frustrated and work around by closing/reopening Visual Studio all the time or running builds with `-nodeReuse:false` (at perf cost).

It would be nice to have a nudge to use `TaskHostFactory`, if you don't. I think we could detect the case by "is the referenced assembly in a `UsingTask` the output of another project in this build?"

(inspired by a conversation with @MichalPavlik about inline-task UX)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.