With a nuspec like the following
...
<contentFiles>
<files include="Data\*" copyToOutput="true"/>
</contentFiles>
...
It packs properly, but does not actually set the copyToOutput
to the wanted value.
I will assume that is because the value for include
does not follow the conventions. If that is the case, then I would think nuget pack
should fail.
Disagree that nuget pack should fail. It should issue a warning that the
nuspec contains syntax that will not be extracted by a client properly with
an indicator of which line will not be handled.
Jeff
On Sun, Jan 10, 2016 at 4:57 PM, Mordechai Zuber [email protected]
wrote:
With a nuspec like the following
...
...It packs properly, but does not actually set the copyToOutput to the
wanted value.I will assume that is because the value for include does not follow the
conventions. If that is the case, then I would think nuget pack should
fail.—
Reply to this email directly or view it on GitHub
https://github.com/NuGet/Home/issues/1908.
That works fine for me also.
Will it create the same structure of any/any/* in the client project though? It wasn't clear from the docs and I have code that needs to know the exact path of the files.
I agree with @csharpfritz a warning for incorrect rules would be helpful. The contentFiles section of the nuspec is consumed by the client during restore, not during pack time.
@M-Zuber the package needs to have the structure of <code language>/<tfm>/<files>
already, it isn't created by nuget. The reason your include is failing is because the Data folder does not match that pattern, you need the full path within the nupkg. Ex: any/any/Data/* or *_/_ for everything.
Well now it is not even transferring the files at all.
Here is the whole thing:
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>Mordechai Zuber</authors>
<owners>Mordechai Zuber</owners>
<licenseUrl>https://github.com/TycheOrg/Tyche/blob/master/License.md</licenseUrl>
<projectUrl>https://github.com/TycheOrg/Tyche/</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>A simple util for generating random names usefull for naming releases</description>
<releaseNotes>Initial release of Tyche.</releaseNotes>
<copyright>Copyright 2016</copyright>
<tags>Generator</tags>
<!--This is not transferring any files when installing the package-->
<contentFiles>
<files include="any/any/Data/*" copyToOutput="true" />
</contentFiles>
</metadata>
<files>
<!--This copies the files over, but can't control copyToOutput-->
<!--<file src="any/any/Data/" target="content"></file>-->
<file src=".\bin\Release\Tyche.dll" target="lib\"></file>
</files>
</package>
<contentFiles>
is not a replacement for <files>
Use _files_ to add the items to the nupkg. _contentFiles_ is used by the client when consuming the package to set the msbuild properties in the lock file.
Items inside _metadata_ are used by the client, items outside such as _files_ are used at pack time.
So if I want the contents of Data to be available in the bin after compiling the client I need both _contentFiles_ and _files_ targeted at the same location, correct?
I have tried with the example posted with the only change being uncommenting the file element, but it still does not seem to work :(
@emgarten In that case, the docs are pretty confusing:
These instructions define a technique used in pre-3.0 versions of NuGet that include files in a package. Newer project systems will not add or manage these files in your project. NuGet recommends the newer contentFiles notation, described below.
(https://docs.nuget.org/create/nuspec-reference#content-files)
This makes it sound like <contentFiles>
_is_ the replacement for <files>
. Further, the docs say that <contentFiles>
has a copyToOutput
attribute:
If True the content items will be copied to the build output folder
(https://docs.nuget.org/create/nuspec-reference#contentfiles-with-visual-studio-2015-update-1-and-later)
That sounds an awful lot like what the pre-3.0 <files>
element did...
Now that I'm reading this with your comment in mind, I think I see the intent. Whereas <files>
causes (pre-3.0) NuGet to perform the copy operation from the package to the target folder, the <contentFiles>
element just tells Visual Studio to reference some things and _it_ will perform the copy operation (if copyToOutput
is set). Is that about right?
I know there's been some talk about how NuGet should handle content packages going forward (and possibly rethinking this approach). Do you know which issue is the one for discussing that (I seem to have lost track)?
Looks like #627, #1523, and #1792 are all related
@daveaglick we are going to update to documents, the process has been stalled a bit because of other higher priority work, but we are not forgetting about it.
To make it clear:
Files - Have nothing to do with content, it is the way you tell packaging to add files into the package
ContentFiles - Defines how to treat files that are already in the package.
@M-Zuber Are the files showing up in the nupkg?
They are showing up in the nupkg, and are getting installed to the project directory of the client.
But - the attributes are not being honoured.
Are you on update 1?
@M-Zuber content\any\any\Data\
should be contentFiles\any\any\Data\
that's why they aren't getting picked.
@yishaigalatzer yes.
@emgarten If I change the file
element to have a target of contentFiles
then they don't show up in the client at all.
Even if I add content
to the beginning of the path in the contentFiles
element, it still does not pass along the attributes.
@M-Zuber are you using this with a UWP (project.json based) project?
Update 1 yes, uwp no
@M-Zuber the files are not supposed to show up in the solution tree. But they are included in your project.
@emgarten we really need the docs out.
Project.json -> contentFiles
packages.config -> content
The contentFiles section of the nuspec is also not used for packages.config/content. To change the copyToOutput property on a file from that folder you would need an install.ps1 script.
So since its not using a project.json then contentFiles
does not help me at all, and I should use a install.ps1
which will be deprecated?
I don't mean to sound snarky, just want to have it clear to know if it might not be easier to include the content within the code file itself
@M-Zuber that's correct. project.json projects can be restored/updated outside of Visual Studio where only contentFiles can be used. Project.json will not use install.ps1 or content, only contentFiles.
As my use case was minimal enough, I simply included the needed data in the code file.
Feel free to close the issue, and thank you for the help and responsiveness
Kindly end the thread by either specifying the working details to extract 'content' from nuget into ASP.NET project or by redirecting to a related link. Thank you.
Looks like, this is still an issue. Is there any plan to resolve this issue in near future?
I'm getting this issue also
@sharifmamun @hisuwh the problem here was that the package was authored incorrectly. Please read the current docs on contentFiles and double check that your packages are authored correctly.
There are currently no known bugs or issues with this setting for contentFiles, if you encounter one please open a new issue so that it can be investigated.
Most helpful comment
@daveaglick we are going to update to documents, the process has been stalled a bit because of other higher priority work, but we are not forgetting about it.
To make it clear:
Files - Have nothing to do with content, it is the way you tell packaging to add files into the package
ContentFiles - Defines how to treat files that are already in the package.