Inference happens only in type project.
On Jan 19, 2016 9:43 PM, "dcorriveau-omniscient" [email protected]
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.

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

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.

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

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.

Yes. Also content packages that do not contain any binary data at all
On Jan 19, 2016 9:51 PM, "dcorriveau-omniscient" [email protected]
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).

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.

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.

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

@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.

so what's the concrete bug?

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)

can you please create a repro case?