I had a package repository (cache) set to some place on disk, centrally, using the repositoryPath NuGet.config setting.
Then I changed my mind about using that, since the path gets added to the HintPath in the proj file uses a relative path that won't work on colleagues' machines.
Trouble is, now the HintPaths need fixing to ..\packages\etc so I thought I'd just run Update-Package Whatever -Reinstall with the package source in the Package Manage Console set to our TeamCity feed.
That reinstalls them all, sure, but the HintPaths didn't get updated!
Why not?
It did.
I just hadn't saved all! So the diff tool didn't see any changes.
Related
I have build a nuget package at published it to a nuget.server site. But when I try to use the package form the server the .targets file from build folder is not in the file. But if I use the package from a local folder it works as it should. How do I get it to work ?
If i look in the package in the folder on the server it looks ok.
It's not clear to me if you mean using (referencing and restoring) a package, or building (packing) a package.
If the problem is with packing the nupkg, NuGet requires the props and targets files to have specific filenames in specific folders, but if you got it to work at least once, you probably already know that. If this is not the problem with packing, you need to give us more information because not using the correct filename convention is the most common problem and I can't guess what else the problem could be. In particular, if the package is being packed differently on your local machine compared to when it is packed on the server, it means there is something different between how you pack on the two computers, so we need more information about how the build and pack work with your project.
If the problem is with using (restoring) the package, there are a few possibilities. My best guess is that you once had a package without the targets file working correctly, and you restored the package on the server. By design, NuGet packages are immutable which means it's invalid for the contents of a package (same ID and version) to change. This allows NuGet to download the package from a remote feed once, save it in the global package folder (not a cache; they never expire) and the next time NuGet needs to restore the same package (id + version) it uses the one in the global package folder, it does not download again. This means if you once built a bad nupkg and restored it on a machine, then fix the nupkg and kept the same version number, that machine will never get the fixed nupkg. You need to delete it from the global packages folder. I'm not 100% sure, but I think if you have a local file feed and you restore a project that uses packages.config, the nupkg does not get saved in the global packages folder, so doesn't have the same problem. In short, I think the problem is that you changed the nupkg contents once without changing the version number, and one of the machines has the old copy in its global packages folder that it keeps using.
If that's not the problem, the next most likely cause is that the nupkg on the server feed has different contents to the nupkg in the local feed. I've never used NuGet.Server, but some nuget respositories (like nuget.org) do not allow overwriting nupkgs. So, if you pushed a nupkg to your server, fixed a problem in your nupkg without changing the version, then tried to push again, the second push might have failed.
In summary, your question doesn't provide enough information for us to help you, but I wrote about the most common issues above. If it doesn't help, you need to provide us with more information. An example of the problem is the best way to give us enough information to help you.
So I've tried everything that was advised such has updating Nuget, ticking nuget.org in Nuget Packege manager and I still get the error of:
Does anybody know what to do ? Thanks.
It looks like your project path is long enough that when the package is restore, restore the package folder fails because it reached the qualified name length limit. See the NuGet issue for this.
Could you try to move you project to root drive?
Move your project to a shorter path location (a root drive will be much better; Example: D:\) and have a try.
I have found a dll that is provided via Google Code and I couldn't find it in NuGet. I want this package to be available via a NuGet install, because I want to reuse it in several packages and NuGet seems like the perfect way to do this.
https://code.google.com/p/protobuf-remote/downloads/list
Is it possible for me to generate a nupkg out of these dll's and publish it to NuGet.org? What are the legal limitations to this action?
There are a number of other users that have run into this issue. It seems like the common solution is to create an "Unofficial" package and reference that for the time being (until Google publishes their library as a NuGet). Just make sure to very clearly label the package as unofficial. See these examples.
As for the legal ramifications...
Please look through protobuf-remote license and review the distribution and derived works details. Currently the license is GNU Lesser GPL. Sorry, but you'll have to make your own call on if publishing the NuGet package would be permitted under this license. ;)
I would recommend you instead create a local NuGet package source by pointing to a file share. This can be local on your computer or on a network file share.
Also, if you don't want to update every workstation, you can update the NuGet.config file in your project to point to this source and commit that config file in your source control repository for all users to get automatically. Just note that any change to a NuGet.config file requires you to restart Visual Studio.
And FYI, take a look at how you can chain multiple NuGet.config files.
I've created new solution in Visual Studio, enable nuget package restore and got in soluition root .nuget folder which contains the following files needed to make package restore work: NuGet.exe, NuGet.config, NuGet.targets.
But I can't make nuget(as Nuget Visual Studio add-in and \.nuget\NuGet.exe as well) read setting from .\nuget\NuGet.config file - settings are still read from default %appdata%\NuGet\NuGet.config.
What have I tried.
I've tried to look where the path to NuGet.config is specified and haven't found anything like that, and nuget.exe install command that runs during build doesn't have any parameter saying like "take this nuget.config file".
Also I've removed \.nuget\NuGet.config and everything works - packages are restored during Visual Studio build and CI one.
Question.
I've got an impression that \.nuget\NuGet.config isn't used at all.
So essentially the question is: How to make .nuget\NuGet.Config file to be not ignored?
What am I doing wrong and how to do it write?
Thanks and have a nice %time_of_day% :)
Disclaimer
Everything that I've mentioned above is not a problem/issue - current nuget behavior is completely acceptable for me - I'm asking just because I'm curious and confused at the same time
I haven't tried this personally, but here is what the official Nuget 2.1 release notes say:
NuGet.config files are searched for in the following order:
.nuget\nuget.config
Recursive walk from project folder to root
Global nuget.config (%appdata%\NuGet\nuget.config)
The configurations are than applied in the reverse order, meaning that
based on the above ordering, the global nuget.config would be applied
first, followed by the discovered nuget.config files from root to
project folder, followed by .nuget
If this doesn't help I'd suggest you write more specifically what you're trying to achieve and which config settings you're changing - knowing more details about the problem may clarify the situation.
Did you point the config file that you want to use as ?
In nuget page example;
nuget config -set repositoryPath=c:\packages -configfile c:\my.config
nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\Config\VisualStudio\14.0\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\NuGetDefaults.Config
I'm new to NuGet -- just started using it and got myself a copy of WatiN.
I'm trying to trim down the size of the folder that was pulled back before I put it into version control. I noticed that WatiN.2.0.50.nupkg is about 12mb. I noticed from this link that the .nupkg is essentially a compressed version of the package contents. Is it OK to delete it, or might doing so cause any issues in the future?
If you delete it we can't update/uninstall since we use that file as a record of what is currently installed. We're looking at a feature that would allow people to restore the packages from packages.config so you could avoid putting packages in source control altogether. More info here http://nuget.codeplex.com/workitem/165