ContainerArchiveOutputPath does not append extension if path doesn't exist

[MattKotsenas]

If I read the docs for ContainerArchiveOutputPath it says:

You can specify either a folder name or a path with a specific file name. If you specify the folder name, the filename generated for the image archive file is named $(ContainerRepository).tar.gz. These archives can contain multiple tags inside them, only as single file is created for all ContainerImageTags.

https://learn.microsoft.com/en-us/dotnet/core/containers/publish-configuration#containerarchiveoutputpath:~:text=You%20can%20specify,all%20ContainerImageTags.

However, if I run a command like this:

dotnet publish .\src\Profiling.Api\Profiling.Api.csproj --configuration release /t:PublishContainer -p ContainerImageTag=1.2.02957.2374-0d4785d8 -p ContainerArchiveOutputPath=C:\projects\profiling-net-api-demo\out\publish

the file I get out is named "publish" with no extension. If I first mkdir out/publish then things work as expected. This doesn't seem to be a regression (or it at least behaves this way is 8.0.308). I think it's understandable to claim that if the directory doesn't exist this is ambiguous with the file name case, however it seems like a footgun to create a file with no extension.

[baronfel]

Totally agree - I think @surayya-MS has hit parts of this with the OCI tarball (I complained about similar) and I think we're going to try and make it less foot-gun-y. Once we do that I can update docs to be more detailed about what to expect as a user in each different input and output scenario.

[surayya-MS]

This happens here because path like ContainerArchiveOutputPath=C:\projects\profiling-net-api-demo\out\publish is not treated as a directory: https://github.com/dotnet/sdk/blob/e2f614015f8ee13678a79d03147c435cc941e856/src/Containers/Microsoft.NET.Build.Containers/LocalDaemons/ArchiveFileRegistry.cs#L18-L28

I agree, it is more intuitive to treat it is a directory if there is no extension. Fixed this in https://github.com/dotnet/sdk/pull/46467

Previously it worked because we were publishing multiple tarballs - one per each arch, and were setting the ContainerArchiveOutputPath ourselves as a .tar.gz file by combining the user provided ContainerArchiveOutputPath with repository name + arch suffix (like -linux-arm64).