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

Question about 'pack' #1414

Closed
dcorriveau-omniscient opened this issue Jan 19, 2016 · 13 comments
Closed

Question about 'pack' #1414

dcorriveau-omniscient opened this issue Jan 19, 2016 · 13 comments

Comments

@dcorriveau-omniscient
Copy link
Contributor

I'm trying to create Nuget packages using Paket and I'm having a few issues. For one project, when I use a template and set it to "project", the output assembly isn't added to the package (maybe I should look at the code to see how it infers what should be the output assembly).

So since it didn't work for me I thought I'd switch to a "file" template. I managed to make it work by specifying the assembly and the info but I'm wondering why can't paket infer the basic info from the AssemblyInfo, just like it does for a "project" template ? For example, why do I need to specify the id, version, etc. ? I'd like to be able to specify the files I want in lib, but I would like paket to use default values from AssemblyInfo if they aren't declared. I'm guessing it's a design choice but I'm not sure why it's working that way ? Also, is there something special about the "copyright" field, since title, id, company, etc. can be inferred from the AssemblyInfo but "AssemblyCopyright" isn't used for the Copyright info ?

Thanks.

@forki
Copy link
Member

forki commented Jan 19, 2016

Inference happens only in type project.
On Jan 19, 2016 9:43 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

I'm trying to create Nuget packages using Paket and I'm having a few
issues For one project, when I use a template and set it to "project", the
output assembly isn't added to the package (maybe I should look at the code
to see how it infers what should be the output assembly)

So since it didn't work for me I thought I'd switch to a "file" template I
managed to make it work by specifying the assembly and the info but I'm
wondering why can't paket infer the basic info from the AssemblyInfo, just
like it does for a "project" template ? For example, why do I need to
specify the id, version, etc ? I'd like to be able to specify the files I
want in lib, but I would like paket to use default values from AssemblyInfo
if they aren't declared I'm guessing it's a design choice but I'm not sure
why it's working that way ? Also, is there something special about the
"copyright" field, since title, id, company, etc can be inferred from the
AssemblyInfo but "AssemblyCopyright" isn't used for the Copyright info ?

Thanks


Reply to this email directly or view it on GitHub
#1414.

@dcorriveau-omniscient
Copy link
Contributor Author

I know, but I'd like to understand the design choice behind that, since that suggests my workflow might not be right.

@forki
Copy link
Member

forki commented Jan 19, 2016

You can pack everytthing into the file type. We cannot know what stuff. Just look at packages like FAKE or the Paket package itself. We only have tools in these - no libs. They might not even be .NET libs.

Even if we have .NET libs in it - which one would we take?

It just no made for that.

@forki
Copy link
Member

forki commented Jan 19, 2016

The interesting question is: why does project type not work. Maybe you ran into a bug.

@dcorriveau-omniscient
Copy link
Contributor Author

Ok so your main usage for a file type are packages that contain misc stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be best suited for me.

@forki
Copy link
Member

forki commented Jan 19, 2016

Yes. Also content packages that do not contain any binary data at all
On Jan 19, 2016 9:51 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

Ok so your main usage for a file type are packages that contain misc
stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be
best suited for me.


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

@pms1969
Copy link
Contributor

pms1969 commented Jan 19, 2016

For me, project types only really work when the paket.template file is named after the csproj. I.e. I have a project called a.csproj with an a.csproj.paket.template file.

Might also just be my useage. Also, you cannot place the template name on the command line. You must call paket either from a super directory with no template specified, or from the directory containing the csproj file, also without specifying the template name.

@dcorriveau-omniscient
Copy link
Contributor Author

Not sure if I fully understand the templatefile argument. I thought it was used to specify a template file so that it would limit the packaging to that project only (the one that corresponds to the template file).

If I don't use that argument, both packages for both projects in the solution are created successfully, otherwise, the package is created but it doesn't contain the dll.

@pms1969
Copy link
Contributor

pms1969 commented Jan 19, 2016

run paket from the project's directory.. I'm not sure I understand it either, but that just works for me.....

@dcorriveau-omniscient
Copy link
Contributor Author

@pms1969 You are right, if I run it from the project directory without the argument it works and generate only that package. If I run it from the project directory with the argument it doesn't work (the package isn't valid)...
Thanks for you help.

@forki
Copy link
Member

forki commented Jan 20, 2016

so what's the concrete bug?

@pms1969
Copy link
Contributor

pms1969 commented Jan 20, 2016

As far as I can tell, if you supply a template name, project types don't pack correctly (i.e. the project output (dll) isn't included)

@forki
Copy link
Member

forki commented Jan 20, 2016

can you please create a repro case?

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

3 participants