Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with packet pack and multiple paket.template files #893

Closed
cr7pt0gr4ph7 opened this issue Jun 22, 2015 · 6 comments
Closed

Issue with packet pack and multiple paket.template files #893

cr7pt0gr4ph7 opened this issue Jun 22, 2015 · 6 comments

Comments

@cr7pt0gr4ph7
Copy link
Contributor

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 [email protected](ArgParseResults`1 results)
   bei Paket.Program.processWithValidation[T](FSharpFunc`2 validateF, FSharpFunc`2 commandF, Command command, String[] args)
   bei [email protected](Command command, String[] args)
   bei Paket.Program.main()
@cr7pt0gr4ph7 cr7pt0gr4ph7 changed the title Issue with packet pack Issue with packet pack and multiple paket.template files Jun 22, 2015
@forki
Copy link
Member

forki commented Jun 22, 2015

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
Copy link
Contributor Author

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

@cr7pt0gr4ph7
Copy link
Contributor Author

The contents of the paket.template files:

type project
id ProjectA

and:

type project
id ProjectB

Everything else is standard C# project setup.

@cr7pt0gr4ph7
Copy link
Contributor Author

@forki forki closed this as completed in bf16d3d Jun 22, 2015
@cr7pt0gr4ph7
Copy link
Contributor Author

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
Copy link
Member

forki commented Jun 22, 2015

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" [email protected]
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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants