Introduce new verb between compile and publish / Allow users to add functionality between verbs

[cdmihai]

There's a set of build functionality which sits somewhere between compile and publish:

• the logic in the current post compile place-binaries scripts
• setting the right file permissions per OS per file
• sign?
• analyze?
• fxcop?

I suggest we introduce a new build verb between compile and publish that covers this responsibility (possible names: deploy, post-build, pre-publish).

A quick scan of issues that will benefit from this:

• incremental compilation (Don't add NeutralResourcesLanguageAttribute to AssemblyInfo when no embedded resources are used #382): the closer the compile phase is just doing compilation, the better. The place-binaries scripts currently break incremental safety checks
• setting the correct file permissions: dotnet compile - all artifacts dropped are +x #4360
• deciding what to copy to output: dotnet/cli#526
• handling pre / post compile exceptions postcompile/precompile doesn't respect exit code of the command #4538

[davidfowl]

This is what scripts are for. How would this verb work?

[cdmihai]

I think the problem needs to be split in 2:

1. functionality that absolutely has to be there and CLI should implement it in c#, within the new deploy verb (or maybe even a PostRestore verb). For example: copying compiler output, setting the right permissions per OS, etc
2. arbitrary functionality that users want to run after / before the compilation phase. These represent extension points into the CLI and we need to define some kind of model for it. We could:

• define an interface that users have to implement and then deploy picks it up (like ITask in msbuild). This means that we'd have PreBuild / PostRestore style verbs that scan for user provided ITasks (IDotnetVerbs?) and run them
• use an analogy of msbuild's BeforeBuild and AfterBuild targets, In CLI's current model where the unit of execution is the script on PATH that starts with "dotnet-", this would translate into users creating dotnet-prebuild and dotnet-postbuild commands that would aggregate the arbitrary functionality.

Whatever the implementation decision, in the current CLI model these arbitrary scripts that can do anything should not be invoked from within the execution of built-in CLI verbs (restore, build, compile, run, publish, etc) but should be aggregated in special phases that have the explicit semantics of running user provided functionality. If they are not separated from built-in verbs and contained, CLI would be prone to hard to debug crashes since the happy path of each built-in CLI verb would risk being perturbed by the scripts they invoke during their own execution. This problem is not entirely removed by moving the arbitrary user scripts between built-in verbs, but at least it makes things a bit more sane and debugable.

[cdmihai]

I see that issue #4407 discussed problem nr. 2 from my previous post: introducing a generic mechanism which allows users to hook up event listeners (or just script runs) on pre / post dotnet verb execution.

This is different from problem 1. for which we need to create a deploy verb that performs actions which most / all projects need (maybe configurable through project.json or flags).

Having PreCompile and PostCompile scripts tightly wrapping each actual compiler invocation is problematic for reliable incrementality, so we need to offer something better.

Options are a separate "deploy" verb that runs deployment scripts, or a new concept of a PostBuild script that runs after the entire build is done.

If the goal of the CLI is to tease apart pieces of functionality that are logically different, then I feel that a "deploy" verb would be the cleanest approach. But it's also confusing to have "deploy" and "publish" --- what's the difference? That would speak for PostBuild or PrePublish script. If we expect these scripts to be or become somewhat involved, then maybe PostBuild would be best, and one day we might enhance the "build" verb to perform the tasks that PostBuild scripts tend to do, but in a way that supports incrementality. If we expect the scripts to always remain shallow, than a PrePublish script might be better.

[TheRealPiotrP]

The team is actively working on enabling MSBuild and the component affected will be superseded by the new project system, so I am closing this issue.