When you write nuspec file it is possible to use files tag and select some files with exclusion of some unwanted ones. However how I can exclude files that nuget adds automatically?
For example I have a project with with such file:
Schema\Configuration.xsd
nuget decides to add it to package and I cannot get rid of it (from the package).
Related
I am trying to exclude a folder in my project and have added the following lines to the .gitignore:
logs/
tempStorage/
libraries/lib/
The first two are excluded but the last one is still being updated. That folder contains DLLs that are generated by another project in the solution.
I am using Visual Studio 2022. When I rebuild the solution the project target lib updates the DLLs. I don't want to store these in git.
Do I need to do something in git like delete the files?
I have a simple task, I want to install a nuget package to a solution and have it copy files to the folder structure but I don't want to modify the solution or projects in any signifcant way.
Currently I have a solution-level package but I can't seem to get it to copy any files anywhere. All it does currently is add a reference to .nuget\packages.config and a pointer in the solution file. This is fine, I just need it to copy files as well, the <Files> element doesn't seem to be doing it.
Solution-level packages have been deprecated as of NuGet 3 last October.
https://github.com/NuGet/Home/issues/522#issuecomment-98845250
I created a nuget package (let's name it Web.Content) with lots of js, css and other content for my other package (named Web). In nuspec file I had file section
<file src="Content\**\*.*" target="content\Content" />
I made changes in some files from Content folder, then I created a new version of Web.Content package.
I have a project that includes Web and Web.Content packages. After a new version of Web.Content package was created I updated it in my project via nuget. When I try to commit changes of my project, SVN suggests me to commit all content of Web.Comment package.
As I understand, when nuget package was updated all target folder "content\Content" was deleted and copied from package again.
But I need SVN to trace only changes that were made in a couple of files, I don't want to see thousands of changed files because actually changes were made only in some of them.
How can I make nuget copy only changed files? Should I change my nuspec file or should I create some PS script for my package that will override delete'n'copy nuget package update behaviour?
It will be great to have some examples or links.
Tried with NuGet 2.6.40627.9000 and Tortoise SVN 1.7.7.
As far as I understand NuGet copies files during package installation using somу VS API. This API makes SVN think that the file was deleted and a new file was added(probably this happened because VisualSVN or AnkhSVN is installed).
So we decided to do the next steps:
Place our content items in our own folder which name differs from
"Content"(let's name it "fs_content") because the presence of such
folder in package triggers NuGet usual installation behavior, but
we don't need NuGet to install our content in usual way.
Write own install.ps1 script that copies our content files to
destination and put it into Tools package folder.
But after installing such package our content items did not appear where they should appear. My colleague googled some information in NuGet help - "The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off." We placed a dummy file into "Content" folder and Install.ps1 script began to copy our content from "fs_content" folder as we want.
Now SVN determines only changes made in some files correctly.
If you put any files in the Content folder of a Nuget package, during installation these files are:
Copied to the root of the target project and
Included in the project.
Is there any way to make Nuget skip action 2, i.e. to copy them but not include them in the project?
I know I can do this with a Powershell script that goes in and removes the files from the project. But I don't think that's a very robust method.
Can I achieve this without relying on Powershell?
You can try adding your contents directly in the package instead of the "contents" folder.
Files outside "contents" would be ignored by NuGet while trying to add content files.
Then you can do just the copying part using your powershell scr
I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.
I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.
What are some good practices for version controlling created NuGet packages?
I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.
Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the <version>$version$</version> form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.
In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.