Analyzer: Task built in current build referenced without TaskHostFactory
- 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.