Issue with packet pack and multiple paket.template files

[cr7pt0gr4ph7]

I discovered the issue with Paket version 1.16.0, and it is still present in the current version 1.17.0.

Details

When calling packet pack inside a multi-project solution where multiple projects have paket.template, pack selects the wrong .csproj file - see below for an example.

Reproduction steps

Given the following directory layout:

.paket/
  paket.bootstrapper.exe
  paket.exe
bin/
src/
  paket.dependencies
  ProjectA/
    ProjectA.csproj
    paket.template
  ProjectB/
    ProjectB.csproj
    paket.template

When calling:

src\ProjectB> ..\..\.paket.exe pack output . templatefile paket.template

I get the following error (note: this should use ProjectB.dll, and not ProjectA.dll!):

found: C:\<path>\src\paket.dependencies
Parsing C:\<path>\src\paket.dependencies
Loading assembly metadata for C:\<path>\src\ProjectA\..\..\bin\ProjectA.dll
Paket failed with:
        Die Datei "C:\<path>\bin\lib.SD.DefaultImplementations.dll" konnte nicht gefunden werden.
StackTrace:
     bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, S
tring msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolea
n checkHost)
   bei System.IO.File.InternalReadAllBytes(String path, Boolean checkHost)
   bei Paket.PackageMetaData.loadAssemblyId(String buildConfig, ProjectFile projectFile)
   bei Paket.PackageProcess.merged$cont@56(String buildConfig, TemplateFile templateFile, ProjectFile projectFile, OptionalPackagingInfo opt, ProjectCoreInfo md, Unit unitVar)
   bei Paket.PackageProcess.f@1-10(String buildConfig, FSharpOption`1 version, HashSet`1 allTemplateFiles, ProjectFile projectFile, TemplateFile templateFile)
   bei Paket.PackageProcess.Pack(DependenciesFile dependencies, String packageOutputPath, FSharpOption`1 buildConfig, FSharpOption`1 version, FSharpOption`1 releaseNotes, FSharpOption`1 templateFile)
   bei Paket.Program.handler@288-19.Invoke(ArgParseResults`1 results)
   bei Paket.Program.processWithValidation[T](FSharpFunc`2 validateF, FSharpFunc`2 commandF, Command command, String[] args)
   bei Paket.Program.processCommand@71-1.Invoke(Command command, String[] args)
   bei Paket.Program.main()

[forki]

since you already described the repro setting. could you please create a minimal repro? It's much easier if I can just download a repro and fix right away. that would be really helpful.

[cr7pt0gr4ph7]

I forgot my GitHub password, so I currently cannot upload things. Sorry.

[cr7pt0gr4ph7]

The contents of the paket.template files:

type project
id ProjectA

and:

type project
id ProjectB

Everything else is standard C# project setup.

[cr7pt0gr4ph7]

I've uploaded a zip archive at https://github.com/cr7pt0gr4ph7/Paket/releases/download/issues%2Frepro%2F893/Paket_Issue_893.zip.

[cr7pt0gr4ph7]

Fix confirmed. It might might sense to put up some integration tests for the command line interface, using a known input state (i.e. local package repository, known paket.template setup) and comparing it to a known output state.

[forki]

Yep did integration tests a couple of months ago, but removed them because
of bad test infrastructure. We look for volunteers who want to create a
useful integration testing lib.
On Jun 22, 2015 10:50 AM, "Lukas Waslowski" notifications@github.com
wrote:

Fix confirmed. It might might sense to put up some integration tests for
the command line interface, using a known input state (i.e. local package
repository, known paket.template setup) and comparing it to a known
output state.

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