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.
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.
My Web2 solution is failing to compile because some of the packages were hosted in a different directory structure to the rest of the solution, and I deleted this structure and the corresponding "packages" folder.
I used Update-Package -reinstall
Hoping that this would fix it... however it still kicks out this error message on build:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props
Now as far as I can tell all the references should be OK, packages.config says:
<package id="Microsoft.Net.Compilers" version="1.0.0" targetFramework="net45" developmentDependency="true" />
And the directory structure exists
--Solution Dir
|-- packages
|--Microsoft.Net.Compilers.1.0.0
I tried updating the package and got version 1.3.2, but the error message remained the same, ie version 1.0.0 was missing.
Theres' clearly some reference to this floating around somewhere - but I don't know where to start looking. I'm assuming the ..\packages in the path indicates its looking for the package in the external directory location (as one up was where the original packages were)
Any ideas?
UPDATE:
I copied the packages folder back to its original location outside the solution directory and .... the issue isn't resolved. So maybe that was never the issue in the first place.
However the error message is still reporting a missing NuGet package that to all appearances is actually there.
This StackOverflow answer got me started on the right track, once I Googled the error message without the ..\ in front of the package location
https://stackoverflow.com/a/32296184/1286358
Then I had to go through and add serveral missing references - presumably because in my hacking attempts to fix the issue I had removed them then not re-referenced them.
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.
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 am trying to read my local solution packages folder using NuGet.Core.
If I create new UnzippedPackageRepository(pathToPackages) and call GetPackages() on it, the result is empty. I am looking at the source of UnzippedPackageRepository and it has:
from file in FileSystem.GetFiles("", "*" + Constants.PackageExtension)
let packageName = Path.GetFileNameWithoutExtension(file)
where FileSystem.DirectoryExists(packageName)
select new UnzippedPackage(FileSystem, packageName)
So it seems to expect *.nupkg for each package in top level?
Anyway, what is right way to read solution package store aside from going through each folder and creating UnzippedPackage manually?
Solved it, solution packages folder is handled by SharedPackageRepository.