Skip to content

Problems building a single project in a larger solution that imports paket.targets using "msbuild" from the command line #172

Closed
Closed
Problems building a single project in a larger solution that imports paket.targets using "msbuild" from the command line#172
Labels
bug

Description

@dsyme
dsyme
opened on Sep 26, 2014

I have a solution containing two projects in "src\X\X.fsproj" and "src\Y\Y.fsproj". Both import paket.targets in the usual way:

<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>
....
<Import Project="$(SolutionDir).paket\paket.targets" />

If I build the solution everything i fine. However if I do

 cd src\X
 msbuild

then there is an error

 1>RestorePackages:
     "..\..\.paket\paket.exe" install
     The system cannot find the path specified.

I believe that "....\paket.exe" is being run in the SolutionDir, which is "....". This means that we are looking for paket.exe in two directories above the SolutionDir.

Activity

  1. Imagedsyme
    added a commit that references this issue on Sep 26, 2014

    First package restore from within Visual Studio - references #130

    a29b9f6

  2. dsyme commented on Sep 26, 2014

    @dsyme
    dsyme
    on Sep 26, 2014
    ContributorAuthor

    See this comment: a29b9f6#commitcomment-7945050

  3. forki commented on Sep 26, 2014

    @forki
    forki
    on Sep 26, 2014
    Member

    any ideas how to fix this?

  4. dsyme commented on Sep 26, 2014

    @dsyme
    dsyme
    on Sep 26, 2014
    ContributorAuthor

    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>

  5. forki commented on Sep 26, 2014

    @forki
    forki
    on Sep 26, 2014
    Member

    Is there an OSS project where I can reproduce?

  6. Imageforki
    added
    bug
    on Sep 26, 2014

  7. ctaggart commented on Sep 29, 2014

    @ctaggart
    ctaggart
    on Sep 29, 2014
    Contributor

    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>

  8. forki commented on Sep 29, 2014

    @forki
    forki
    on Sep 29, 2014
    Member

    Could you please send me your paket.targets?
    On Sep 29, 2014 7:20 AM, "Cameron Taggart" notifications@github.com 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).

  9. ctaggart commented on Sep 29, 2014

    @ctaggart
    ctaggart
    on Sep 29, 2014
    Contributor

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

  10. Imageforki
    closed this as completedin 656773con Sep 29, 2014

  11. forki commented on Sep 29, 2014

    @forki
    forki
    on Sep 29, 2014
    Member

    @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

  12. dedale commented on Sep 29, 2014

    @dedale
    dedale
    on Sep 29, 2014
    Contributor

    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'

  13. forki commented on Sep 29, 2014

    @forki
    forki
    on Sep 29, 2014
    Member

    cool.

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

  14. dedale commented on Sep 30, 2014

    @dedale
    dedale
    on Sep 30, 2014
    Contributor

    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 ?

  15. forki commented on Sep 30, 2014

    @forki
    forki
    on Sep 30, 2014
    Member

    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." notifications@github.com 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).

  16. dedale commented on Sep 30, 2014

    @dedale
    dedale
    on Sep 30, 2014
    Contributor

    Ok I will try to push a PR then
    On Sep 30, 2014 8:49 AM, "Steffen Forkmann" notifications@github.com
    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." notifications@github.com 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions