Migrate GenerateFileFromTemplate to Microsoft.DotNet.Build.Tasks.Templating

[JunTaoLuo]

Fixes #204. This will need to be backported to 3.1 and 5.0 after approval

[dougbu]

My comments are all nits but I would like to hear from @alexperovich and / or @markwilkie before we merge.

[dougbu]

/fyi @rainersigwald (re dotnet/msbuild#4018) @ericstj (re #204) @ilyas1974 and @ViktorHofer (re tail end of #135)

[dougbu]

@rainersigwald this migrationf from aspnet/BuildTools reminds me of a rather unrelated question: Why is the <JoinItems> task in the .NET SDK and not together with the more general msbuild tasks and targets❔ I'm reminded of the discrepancy when I reach for Remove with MatchOnMetadata (a poorly-documented and limited option) or difficult-to-grok task batching alternatives in projects that don't use that SDK.

[rainersigwald]

Why is the <JoinItems> task in the .NET SDK and not together with the more general msbuild tasks and targets❔

It was needed there first. I am not opposed in principle to "promoting" it.

[ViktorHofer]

Great to see progress on this 👍

Does one task justify an additional assembly and with it package? Why not add it to the Arcade.Sdk project instead?

[ViktorHofer]

That's the implementation that we use in dotnet/runtime: https://github.com/dotnet/runtime/blob/main/src/tasks/installer.tasks/GenerateRunScript.cs which looks simpler. Wouldn't that suffice?

[JunTaoLuo]

@ViktorHofer it was mentioned that this task shouldn't be included in the SDK: #204 (comment) so we decided to create a task package instead. As for comparison between GenerateRunScript.cs, this task is more general and can be used to substitute a user specified set of properties instead of just the specific [[RunCommands]] and [[EchoRunCommands]]

[ViktorHofer]

LGTM. What about tests? :)

[JunTaoLuo]

There were no tests in the original implementation, maybe we should not block on that in this PR and file followup to add tests?

[ViktorHofer]

There were no tests in the original implementation, maybe we should not block on that in this PR and file followup to add tests?

Sure, works for me.

[JunTaoLuo]

Hey all, I've addressed the style guidelines and other feedback.

[dougbu]

/fyi @markwilkie four projects in this repo use a different header:

<!-- Copyright (c)  Microsoft.  All Rights Reserved.  Licensed under the Apache License, Version 2.0.  See License.txt in the project root for license information. -->

They should probably be made consistent.

[dougbu]

This PR has been reviewed though I don't see any s from Core-Eng folks. Unless I hear different before later tonight, I'll merge. Please sing out w/ objections if you have any.

[markwilkie]

While I have no context on the code itself, the intent is good with me. Assuming the right testing has happened, I'm find w/ merging.

[ChadNedzlek]

This "Output" is not correct, it's an input parameter. It's not returned by this task.

[JunTaoLuo]

Looks like we use it as output here: https://github.com/dotnet/aspnetcore/blob/52eff90fbcfca39b7eb58baad597df6a99a542b0/src/ProjectTemplates/GenerateContent.targets#L45-L52.

[JunTaoLuo]

Though I think it may be more correct to set the value to the value escaped by https://github.com/aspnet/BuildTools/blame/main/src/Internal.AspNetCore.BuildTasks/GenerateFileFromTemplate.cs#L55.

We could probably also separate it out into a separate out parameter like ResolvedOutputPath or EscapedOutputPath but so far we haven't run into any issues in our builds due to this being an Output parameter so I would prefer if we don't block on this change and file followup issues to address.

[ChadNedzlek]

This path is never set by this code. Marking it output is incorrect, since it doesn't actually output anything. We should not be checking in new, incorrect, code.

[ViktorHofer]

🎉🎉🎉