fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.02k stars 525 forks source link

Paket pack not handling "SourceDir" correctly in *.csproj file #3258

Open Richard-Wallace opened 6 years ago

Richard-Wallace commented 6 years ago

Description

If the "OutputPath" has $(SolutionDir) for then Paket pack has a DirectoryNotFoundException. It appears to be concatenating the current working directory to the actual output directory, instead of using the true Visual Studio solution directory, and then concatenate the output directory.

Broken:

$(SolutionDir)buildoutput\Debug\

Works:

..\..\buildoutput\Debug\

Repro steps

Please provide the steps required to reproduce the problem

  1. Change the definition of the "OutputPath" to use $(SolutionDir) instead of a relative path to the directory where the solution file actually exists.

  2. Build the solution.

  3. CD to the directory that has the .csproj file and paket.template (type project) and run "paket pack . --version 1.2.3.4 --verbose --template .\paket.template" Then the exception should be thrown. The path to the DLL it is looking to pack should exist under the directory the .csproj file exists but really exists in a directory relative to the actual Visual Studio solution directory.

If possible then please create a git repository with a repro sample or attach a zip to the issue.

Expected behavior

I would expect Paket to determine the directory location of the solution file and use that instead of the directory the "paket pack..." command is being run from as the $(SolutionDir).

Actual behavior

Seeing a DirectoryNotFoundException and the path indicated is expected under the directory the .csproj file exists in and is not looking for the .dll to be included relative to the solution file.

Known workarounds

Manually change the $(SolutionDir) in the OutputPath to a relative path.

Flohack74 commented 5 years ago

I would upvote this one, and additionally I think it would be good to support other env variables as well. Our csproj files for example have set <OutputPath>$(BUILD_OUTPUTPATH)</OutputPath> in all csproj files to allow dynamic output handling depending on certain usecases. The CI will set the variable, and then would call paket pack to generate around 20 nupkg´s from that.

We would love to use paket here since the dynamic dependency detection, we simply cannot rely on manual updates for all nuspec files. But so far we can´t because of our dynamic output path.

So basically paket could scan over the csproj file, and try to substitute what it finds with env variables, if they are defined.

ulfllorenz commented 10 months ago

Just to give this issue some more publicity, I would also like to support this feature request. We have a code base from which we build multiple different products (complex beast with native code etc.) I would not recommend or glorify our build setup, but that is what we have. As a consequence, the normal dotnet workflow with building everything into the same obj/ and bin/ subdirectories simply does not work reliably, we need to change our various output paths to dedicated build directories. And this does not work reliably with SDK-style projects