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.

https://github.com/dotnet/msbuild/blob/9c46407735ef0afede0c481069acc2ea8704c510/src/Build/Resources/xlf/Strings.xlf#L573-L576

[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 https://github.com/dotnet/msbuild/pull/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 https://github.com/dotnet/msbuild/pull/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!

[rainersigwald]

@stan-sz Are you ok with this only working in dotnet build, and not working in Visual Studio/MSBuild.exe?

[alexrp]

I would also love to see this. I'm currently doing this, which is... not great, for multiple reasons. (It only working in dotnet build would be fine in my case, since these projects are never evaluated/built from anything else, for whatever that's worth.)

[stan-sz]

@stan-sz Are you ok with this only working in dotnet build, and not working in Visual Studio/MSBuild.exe?

Yes

[stan-sz]

@rainersigwald - a kind reminder so this task makes it to the release. Thanks!