MSBuild task for creating Tar files

[stan-sz]

With .Net 7 support for tar apis, is it feasible to create an equivalent of (Un)ZipDirectory tasks for handling .tar files in the upcoming MSBuild release?

[danmoseley]

Cc @carlossanlop fyi

[KalleOlaviNiemitalo]

Would such a task be able to work when MSBuild is run on .NET Framework? System.Formats.Tar doesn't appear to target anything compatible with that.

https://github.com/dotnet/runtime/blob/eecb02807867cad56cd05badddef65e432248b75/src/libraries/System.Formats.Tar/src/System.Formats.Tar.csproj#L3

[danmoseley]

No it would only work on .NET 7 and later. I believe that would mean .NET SDK 7.0.something and later, targeting any version.

[rainersigwald]

We don't yet have any inbox tasks that are .NET (core) only, which might be enough to delay this. But I think it sounds like a reasonable idea.

[KalleOlaviNiemitalo]

If a task that requires .NET is added and a user tries to run it on .NET Framework, I hope it will log an error saying that the task doesn't support .NET Framework, rather than MSB4036.

msbuild/src/Build/Resources/xlf/Strings.xlf

Lines 573 to 576 in 9c46407

	<trans-unit id="MissingTaskError">
	<source>MSB4036: The "{0}" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with &lt;UsingTask&gt; in the project file, or in the *.tasks files located in the "{1}" directory.</source>
	<note>{StrBegin="MSB4036: "}LOCALIZATION: &lt;UsingTask&gt; and "*.tasks" should not be localized.</note>
	</trans-unit>

[rainersigwald]

@KalleOlaviNiemitalo Yes, if the UsingTask is authored correctly (that is, specifies that the task is .NET-only).

[KalleOlaviNiemitalo]

I see, you added support for Runtime="NET" in #6994. It doesn't seem to be documented yet, so I filed https://github.com/MicrosoftDocs/visualstudio-docs/issues/8436.

[baronfel]

This is a great idea, and we should do it.

However, this task would require a .NET 7 Runtime, which brings up an interesting conundrum. That would require MSBuild to update its Target Framework to net7.0, but for support reasons we really really try to keep components that ship in the .NET SDK to Long-Term-Support Target Frameworks. We're having a discussion about the mechanics of this later this week, but in general because of SDK and Visual Studio support cycles and overlaps (or lack thereof) between the two, we try to limit the amount of STS (short-term support)-only features we use in the product to enable us to fallback to run on supported runtimes when the STS stables go out of support.

That would mean that this Task would either need to be conditioned somehow, or wait until we start targeting net8.0 for MSBuild (which would be something like the 17.8 MSBuild/VS version numbers if memory serves).

[benvillalobos]

In that case, blocked on #7790 and should be conditioned. We can add this to the next spring planning and discuss it then. Conditioning out the task should be easy enough.

[stan-sz]

@benvillalobos can this work be scheduled for a minor release still in 7.0 timeframe (before .NET 8.0)?

[rainersigwald]

@stan-sz MSBuild releases on the .NET SDK and Visual Studio cadence, so can add features ~quarterly.

[stan-sz]

A kind reminder about this feature request, @benvillalobos and @rainersigwald. Thanks!