The output flag interprets paths relative to the project directory #92

Open
opened 2026-01-29 16:29:19 +00:00 by claunia · 2 comments
Owner

Originally created by @AnthonyMastrean on GitHub (Dec 9, 2020).

When I use the output flag on dotnet publish, for example, the path is relative to the current working directory (cwd).

$ dotnet publish -c Release -o out src/Example
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.        

  Determining projects to restore...
  All projects are up-to-date for restore.
  Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\Example.dll
  Example -> C:\Users\anthony\example-project\out\

When I use the output flag on dotnet tarball, for example, the path is relative to the project directory.

$ dotnet tarball -c Release -o out src/Example/Example.csproj
dotnet tarball (0.1.189+6ef34e121b)
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\Example.dll
  Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\publish
  Creating tarball out\Example.0.0.0.tar.gz

It doesn't print that way (I'll open another issue about complete paths), but I can guarantee that path is relative to the project dir, which is unexpected and inconsistent with the dotnet CLI.

C:\Users\anthony\example-project\src\Example\out\Example.0.0.0.tar.gz
Originally created by @AnthonyMastrean on GitHub (Dec 9, 2020). When I use the `output` flag on `dotnet publish`, for example, the path is relative to the current working directory (cwd). ``` $ dotnet publish -c Release -o out src/Example Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... All projects are up-to-date for restore. Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\Example.dll Example -> C:\Users\anthony\example-project\out\ ``` When I use the `output` flag on `dotnet tarball`, for example, the path is relative to the project directory. ``` $ dotnet tarball -c Release -o out src/Example/Example.csproj dotnet tarball (0.1.189+6ef34e121b) Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\Example.dll Example -> C:\Users\anthony\example-project\src\Example\bin\Release\netcoreapp3.1\publish Creating tarball out\Example.0.0.0.tar.gz ``` It doesn't print that way (I'll open another issue about complete paths), but I can guarantee that path is relative to the project dir, which is unexpected and inconsistent with the `dotnet` CLI. ``` C:\Users\anthony\example-project\src\Example\out\Example.0.0.0.tar.gz ```
claunia added the up-for-grabsbug labels 2026-01-29 16:29:19 +00:00
Author
Owner

@qmfrederik commented on GitHub (Dec 9, 2020):

The idea is indeed that these commands are similar to the dotnet CLI in behavior. So that does mean that dotnet tarball -o [path] should interpret path as relative to the working directory (similar to dotnet pack or dotnet publish).

The code that handles this is here: https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/TarballTask.cs#L30 (and similar for the other commands).

Are you interested in creating a PR for this?

@qmfrederik commented on GitHub (Dec 9, 2020): The idea is indeed that these commands are similar to the `dotnet` CLI in behavior. So that does mean that `dotnet tarball -o [path]` should interpret `path` as relative to the working directory (similar to `dotnet pack` or `dotnet publish`). The code that handles this is here: https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/TarballTask.cs#L30 (and similar for the other commands). Are you interested in creating a PR for this?
Author
Owner

@Chris-Mingay commented on GitHub (Aug 17, 2021):

Hi @qmfrederik I am interested in helping with this but I'm not actually sure how I go about using my locally compiled version of dotnet-zip to test what I have coded.

If you're happy to point me in the right direction with that, I'll get things coded and create a pull request.

Thanks

@Chris-Mingay commented on GitHub (Aug 17, 2021): Hi @qmfrederik I am interested in helping with this but I'm not actually sure how I go about using my locally compiled version of `dotnet-zip` to test what I have coded. If you're happy to point me in the right direction with that, I'll get things coded and create a pull request. Thanks
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#92