-
Notifications
You must be signed in to change notification settings - Fork 525
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
Comments
Inference happens only in type project.
|
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
|
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)... |
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? |
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.
The text was updated successfully, but these errors were encountered: