'dotnet pack -o .' places NuGet packages in project folder

[jvandertil]

Steps to reproduce

dotnet pack -o . src\project\project.csproj

Expected behavior

NuGet packages are placed in current folder as specified with -o .
This worked properly using preview2 tooling (1.0.0-preview2-003131) and project.json.

Actual behavior

NuGet packages are placed in src\project.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
Version: 1.0.0-preview3-004056
Commit SHA-1 hash: ccc4968

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64

[TheRealPiotrP]

@rainersigwald @rrelyea it seems like . is being interpreted relative to the project root and not the PWD. This seems like a broken experience since it is natural to assume that relative paths are relative to the PWD. Thoughts on this?

[rainersigwald]

@piotrpMSFT how are you passing the cli argument down into MSBuild?

Paths in projects are relative to the project, because the CWD can change arbitrarily but you wouldn't want to be referring to different files (say if you built the same project as msbuild something.proj and then again as msbuild ..\..\some\other\thing\something.proj).

So if (as I suspect) you're setting a property to the value . and then reading it in the project file, it'd be proj-relative. I think the fix is to canonicalize the path in the CLI before sending it to MSBuild.

[TheRealPiotrP]

@rainersigwald this means that the issue will repro for folks using MSBuild directly and not via CLI. Wouldn't this be more scalable if . were interpreted early on by e.g. the SDK? I do get the concern that it's just another property to MSBuild until interpreted by a target/prop.

@nguerrera @dsplaisted thoughts?

[nguerrera]

@piotrpMSFT AFAICT, msbuild actually changes the CWD to the project dir, so I don't know how the SDK can do anything about this.

<Project>
  <Target Name="Build">
     <Exec Command="cd" />
  </Target>
</Project>

D:\>msbuild d:\temp\test.proj /v:m /nologo
  d:\temp

[rainersigwald]

We do offer the magic property $(MSBuildStartupDirectory) . . . the SDK could use that. Maybe something like $(System.IO.Path::Combine($(MSBuildStartupDirectory), $(PropertyThatGetsPassedIn)), which would allow a fully-qualified passed-in path to override?

[nguerrera]

Then we also have to repeat and give TreatAsLocal to every directory that could get passed in (there are many). Sounds messy. I'd say that if you invoke directly via msbuild then things should work as they always have. The CLI, acting as an abstraction over msbuild, can have different behaviour.

[TheRealPiotrP]

If we're not going to address this in the SDK then I think CLI should be consistent with other products. This is a migration pain in the short term, but offering differing behavior will lead to long-term issues. It's unfortunate that the migration tool can't capture these sorts of scenarios, however.

@blackdwarf I'd love to hear your thoughts on this.

I think the POR recommendation is that @jvandertil updates the script from:

dotnet pack -o . src\project\project.csproj

to

dotnet pack -o ..\..\ src\project\project.csproj

so it matches the equivalent msbuild call:

dotnet msbuild src\project\project.csproj /p:OutputPath="..\..\"

It seems ugly in this scenario but I think consistency is more important than beauty when dealing with relative paths...

[jvandertil]

Considering this is preview tooling, I can live with adjusting my script for the time being. But I would greatly prefer that the 'dotnet pack -o' works as I expected in the original report.

[nguerrera]

I think it makes sense for direct msbuild invocation and dotnet.exe invocation to differ here. In the msbuild case, there is an explicit /p argument, and so it seems reasonable that this works as it always has. But the help for dotnet -o says:

  -o|--output <OUTPUT_DIR>            Directory in which to place outputs

From that alone, it is more surprising that -o . does what it currently does.

[blackdwarf]

I don't know if I would actually say that what is proposed above (in @piotrpMSFT answer) is acceptable as a long-term solution (it is fine as an unblocking mechanism for @jvandertil for now). Though I understand the MSBuild specifics and the potential challenges in changing them, I would say that I expect the CLI to behave properly w.r.t to the current directory, that is, the . should resolve to the current working directory rather than the project's directory.

I guess I would +1 what @nguerrera said above as well.

[TheRealPiotrP]

Moved to RTM milestone. I'd still love to see consistent behavior across the product suite, but am glad we have consensus on what should happen in CLI.

[eerhardt]

I just hit this as well with dotnet publish -o. My opinion is the CLI should be taking relative paths and making them into full paths relative to the current working directory, then passing that into MSBuild.

Every command-line application I am familiar with uses paths relative to the current working directory. Not relative to some arbitrary file it is operating on.

One last thing, if we ship 1.0 like this, it will be a breaking change to fix it the right way afterwards.

[ViktorHofer]

Totally agree that the path should be the CWD. Everything else would not make sense. I also just noticed that weird behaviour and now have to work with absolute paths in my powershell script which invokes dotnet pack to pack multiple projects at once.

[cwe1ss]

Could you add stuff like this to e.g. https://docs.microsoft.com/en-us/dotnet/articles/core/migration/ or could you create something like aspnet/Announcements where you post breaking changes (as they come up)? Right now, everyone just has to trial&error his build script which is a bit annoying 😢

EDIT: Just found this page. It would be great if this issue could be documented there https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md

[livarcocc]

We should make the output dir and other directories passed as special arguments to the CLI relative to the PWD.

https://github.com/dotnet/cli/issues/5996 is another one of these.

Let's consolidate all these changes in one and track it here.

[jchannon]

Spotted similar issues. I have a csproj located at ./init/setup/src

When I run:

mkdir -p publish
dotnet publish --configuration Release --framework netcoreapp1.1 --runtime centos.7-x64 --output ./publish ./init/setup/src

The projects is outputted to ./init/setup/src/publish which is wrong IMO

[natemcmaster]

+1 - hit this issue again. Although it would be a breaking change, I think this is still worth doing.

FWIW I'd be willing to be changing relative paths handling won't break everyone, as many people who hit this bug have worked around it by passing in absolute paths to --output. Absolute path behavior would not change.

[derekgreer]

+1

Any command providing an output parameter should always interpret relative paths to be relative to the CWD.