See this comment: a29b9f6#commitcomment-7945050

any ideas how to fix this?

It looks like they don't set the WorkingDirectory, but instead compute the explicit path to the packages.config:

    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>

and then pass $(PackagesConfig) ro the command along with SolutionDir (actually $(PaddedSolutionDir) )

    <RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)"  $(NonInteractiveSwitch) $(RequireConsentSwitch) -solutionDir $(PaddedSolutionDir)</RestoreCommand>

Is there an OSS project where I can reproduce?

I ran into this as well. My local fix to paket.targets was to use MSBuildThisFileDirectory. Note that it does include a trailing slash, so I adjusted a couple references. That property has been available since MSBuild 4.

    <PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
        <!-- Windows specific commands -->
        <!--<PaketToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".paket"))</PaketToolsPath>-->
        <PaketToolsPath>$(MSBuildThisFileDirectory)</PaketToolsPath>
    </PropertyGroup>

Could you please send me your paket.targets?
On Sep 29, 2014 7:20 AM, "Cameron Taggart" [email protected] wrote:

I ran into this as well. My local fix to paket.targets was to use
MSBuildThisFileDirectory. Note that it does include a trailing slash, so
I adjusted a couple references. That property has been available since
MSBuild 4.

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <!--<PaketToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".paket"))</PaketToolsPath>-->
    <PaketToolsPath>$(MSBuildThisFileDirectory)</PaketToolsPath>
</PropertyGroup>

—
Reply to this email directly or view it on GitHub
#172 (comment).

https://gist.github.com/ctaggart/77706d81703f241dd1c7

@ctaggart thanks. I modified it a bit. Could please check?
@dsyme you can download a fixed paket.targets from https://github.com/fsprojects/Paket/releases/latest

Hello
I had difficulties to reproduce the bug (had to patch fsproj to use F# 3.1)
But I think the current fix is too restrictive.
It would be better to dynamically find the location of .paket folder to guess the SolutionDir with :

<SolutionDir>$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), .paket))</SolutionDir>

ded'

cool.

any chance to submit this as PR? would help us a lot.

To put it shortly : the fix in paket.targets is OK. And paket.targets import in projects is OK while we have one .paket dir per solution directory (SolutionDir must be defined relatively to $(MSBuildProjectDirectory) to be able to build projects directly).

But if we are in the large repository (like mine at work) with 1500 projects and where solutions are automatically generated, in this case we might need one .paket dir at the root of the repo (not at the solution level). Then it would be better to use GetDirectoryNameOfFileAbove for paket.targets imports in projects. This would work for current cases (one solution in repo root) and my large case (many solutions, one .paket dir in repo root).
I've started dev and tests, but I miss time. Anyway I don't think this is critical right now.
And maybe you want to keep one .paket dir per solution ?

I think we actually want one .paket folder per repo.

I'd also love to see a "one paket install per solution build". AFAIK we
install in every project build.
On Sep 30, 2014 8:42 AM, "Vianney P." [email protected] wrote:

To put it shortly : the fix in paket.targets is OK. And paket.targets
import in projects is OK while we have one .paket dir per solution
directory (SolutionDir must be defined relatively to
$(MSBuildProjectDirectory) to be able to build projects directly).

But if we are in the large repository (like mine at work) with 1500
projects and where solutions are automatically generated, in this case we
might need one .paket dir at the root of the repo (not at the solution
level). Then it would be better to use GetDirectoryNameOfFileAbove for
paket.targets imports in projects. This would work for current cases (one
solution in repo root) and my large case (many solutions, one .paket dir in
repo root).
I've started dev and tests, but I miss time. Anyway I don't think this is
critical right now.
And maybe you want to keep one .paket dir per solution ?

—
Reply to this email directly or view it on GitHub
#172 (comment).

Ok I will try to push a PR then
On Sep 30, 2014 8:49 AM, "Steffen Forkmann" [email protected]
wrote:

I think we actually want one .paket folder per repo.

I'd also love to see a "one paket install per solution build". AFAIK we
install in every project build.
On Sep 30, 2014 8:42 AM, "Vianney P." [email protected] wrote:

To put it shortly : the fix in paket.targets is OK. And paket.targets
import in projects is OK while we have one .paket dir per solution
directory (SolutionDir must be defined relatively to
$(MSBuildProjectDirectory) to be able to build projects directly).

But if we are in the large repository (like mine at work) with 1500
projects and where solutions are automatically generated, in this case
we
might need one .paket dir at the root of the repo (not at the solution
level). Then it would be better to use GetDirectoryNameOfFileAbove for
paket.targets imports in projects. This would work for current cases
(one
solution in repo root) and my large case (many solutions, one .paket dir
in
repo root).
I've started dev and tests, but I miss time. Anyway I don't think this
is
critical right now.
And maybe you want to keep one .paket dir per solution ?

—
Reply to this email directly or view it on GitHub
#172 (comment).

—
Reply to this email directly or view it on GitHub
#172 (comment).