I setup an internal NuGet server to host internal dll packages. The setup went smoothly. The spec and nupkg were created successfully. However, when I launch a test project and attempt to install it from Manage NuGet Packages it fails.
The internal package shows up under Manage NuGet Packages with an install button. I hit install but it does nothing. I check my references folder and saw nothing added.
If I check the Manage NuGet Packages at solution level, it has a green check mark indicate that it's installed but doesn't give me a Manage option to see which project it was installed to.
My issue is somewhat similar to this post below. The only difference is that I don't have sub folders for my library. I just have 1 dll and I'm putting the nupkg file directly under the Packages folder.
NuGet package fails to install
I'm not sure what I did wrong. Any suggestions?
Thanks to #MattWard for mentioned that the package got installed at the solution level. I went back to the official documentation here: https://docs.nuget.org/create/creating-and-publishing-a-package to review the differences with creating solution level package vs project level package and most important of all is the nuget naming convention when creating packages (the lib, content, etc. folder). I re-package my dll again with the naming convention and it works!
Related
In the project I've been using some custom NuGet sources. Apparently some of them are no longer available but I do have the newer (and only newer) versions of the packages on the other (still working) server. Is there a way to restore the packages directly to the newest versions without manually replacing all the references in the .csproj and packages.config files?
I've tried running Updade-Package -Reinstall but I only get the following error message:
Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.
If some packages you use (and still want to use) are no longer available, I suggest you to make a backup of them.
Find the Nuget cache on your server. On Windows this is located at
%userprofile%.nuget\packages
Spot the packages (and version) you want to backup and copy the .nupkg files in their respective folders.
Then you have two choices:
Create a private Nuget feed
Create a local Nuget feed on your development machine
The 1st option has the advantage to be a single source that can be used on any machine you want (development machine, build server...etc) but you will have more set-up, especially for the authentication/authorization (because it's a private feed)
For the 2nd option: Simply create a C:/Nuget folder and put any .nupkg you want.
Then in Visual Studio go to:
Tools -> Nuget Package Manager -> Package Manager Settings -> Package Sources
Click on the green + button to add a new source, simply give it the name Local and browse to your C:/Nuget to set the source.
From now on when you want to restore your Nuget packages, Visual Studio will first look into the nuget.org feed and if it doesn't find the referenced packages, will then look into your Local feed and cache the installed package to the %userprofile%.nuget\packages of your machine.
I hope that answer to your question, I was not quite sure about what you asked and your knowledge about Nuget.
UPDATE:
I think I understand your question better now.
First of all, I think your misunderstand the Update-Package -Reinstall command. It will reinstall the packages with the SAME version as already referenced but simply reinstalling them. It's a useful command for example when you change the target framework of your project. Then you can reinstall the same versions of the packages and they will retarget this .NET Framework version.
So if a nuget restore isn't working then Update-Package -Reinstall will obviously fail too.
With Nuget, when something isn't working, you shouldn't insist but instead, find the tweak that will make it working again. I can't count how many times I went to the different caches to delete some cached packages.
I think you should try to use nuget restore and see what packages are causing issues, then uninstall these packages (this will just remove the reference from the .csproj and packages.config if they aren't installed in the project yet), then you can finally install the newest version of these packages.
I am running a private Nuget Server locally on IIS.
I am creating packages and uploading them all via commadline using nuget.exe (Later on I have to put this on build server, hence the command line). However there is one issue I am stuck at.
I am trying to declare dependencies. I generate the nuspec file in the folder where the .csproj file is there. Then I manually edit the nuspec file to add this under the metadata tag:
<metadata>
<dependencies>
<group targetFramework=".NETFramework4.5">
<dependency id="DemoProject" version="2.0.0.0" />
</group>
</dependencies>
</metadata>
DemoProject, version 2.0.0.0 is present on the Nuget Server.
The project I am creating package for, MyProj.csproj does not have the reference to the DemoProject added to it via Visual Studio. It is just at the packing time I want to create the dependency. It sounds strange but is needed for some initial validation.
Then I run pack command:
"C:\nuget\NuGet.exe" pack MyProj.csproj -IncludeReferencedProjects -Prop Configuration=Release
Then I push it to NuGet server using command line.
When I do an install via command line, then only MyProj package is present at the install location.
When I use Nuget Package Explorer and create a package, I can use the Package Dependency Editor to specify the dependency. It asks for the URL of my local Nuget Server and then adds the dependency. And when I install that package, it works !!
There seem to be no difference in the generated nuspec file in both the cases.
Obviously Nuget Package manager is doing something which I am missing out on.
Any hints?
More details: When I create a lib folder in the Package manager console and put my dll manually, lib->net45->MyProj.dll, then when I install the package thus created also "does not" install the dependency. Back to reading documentation again.
I know this doesn't directly answer your question but I had an issue with NuGet dependencies and my solution may possibly provide a hint.
DLL#1 was had no NuGet Dependencies. Pushed that to my private repo.
DLL#2 referenced DLL#1 NuGet package. Pushed that to my private repo.
All fine and dandy except from the Application project when I go to "Manage NuGet Packages...", the NuGet Package for DLL#2 is listed on the Browse tab but it shows no dependencies. I was forced to install both DLL#1 AND DLL#2 nuget packages. I desired to install DLL#2 nuget package and get DLL#1 automatically.
The way I fixed this was uninstalling all NuGet packages from DLL#2 solution.
Then going to Tools > Options > NuGet Package Manager > General. Then set the Default package management format to Packages.config and then unchecking the option "Allow format selection on first package install".
Then i installed all the needed NuGet packages. Now when i pack it up and push it up to the server, it shows the proper dependencies when going to "Manage NuGet Packages...".
nuget pack doesn't see the dependencies because its looking for them in the \packages folder. That folder didn't exist because I was using PackageReference for package management.
All worked after switching to Packages.config for package management.
I know the problem I had wasn't the same as yours but if you're not using Packages.config for package management, perhaps its related.
Late answer but the issue with this nuspec is <group targetFramework=".NETFramework4.5">. I feel confident that ".NETFramework4.5" is an invalid targetFramework. A full list of the available Target Frameworks is here.
When working with the Dependency section, you may not need to use the group tag. Any users who encounter similar errors would do well to read through that section. They have samples of proper usage.
According to this question:
using nuget.exe commandline to install dependency
The command line NuGet tool does not follow dependencies intentionally. While I could understand this as the default behavior, it seems odd to me that there is no choice to have the tool follow the dependencies. Is anyone aware of the reasoning behind this?
That answer is specific to running nuget install packages.config.
When specifying packages.config, only explicitly listed packages are installed.
However, if you try installing a specific package: nuget install My.Package.Id then NuGet will install the package and any dependencies.
EDIT Additional info as to why there's a distinction.
nuget install should really be called nuget download. It doesn't really install in the traditional sense. That is, it doesn't add references to your project files, it doesn't run install.ps1, it doesn't update packages.config, etc. You need to either use the NuGet GUI or Package Manager console to get a true install.
Since the true install updates packages.config, this file already includes all the dependencies that were installed. So specifying the file means, I want to download these specific packages. NuGet doesn't need to think about it since it's basically pre-calculated.
If you want to install/download multiple packages and have NuGet follow dependencies, just create a batch file and issue multiple commands:
nuget install My.Package.Id
nuget install Another.Package.Id
This will cause NuGet to fetch the package an any dependencies it may have.
Hope this clarifies things.
I'm investigating using NuGet internally to share an assembly used across multiple solutions. Despite the documentation making it look simple, I'm just getting a faceful of problems. I have two questions at this stage:
1) When I create the package, NuGet reports it as having 'no dependencies'. In fact, the assembly's project has quite a few dependencies on other (official) NuGet packages. I assumed that NuGet would spot this. Is there something I need to do so that NuGet knows my assembly itself has NuGet dependencies?
2) When I attempt to add the package to a project in another solution, it doesn't actually add the dll to the project (i.e. in the project's References). The package manager GUI lists the package in the installed list, but doesn't show a 'Manage' button, as it does for other packages. Instead, it just shows a 'Uninstall' button. So it's as if the overall solution is now aware of my package, but I can't add it as a reference to any projects, which is obviously of no use. This happens regardless of whether I install using the GUI or the command line. Does anyone know why this might be happening?
Thanks in advance.
For issue 1, if you are using nuget.exe pack and your project installed certain packages, these packages will be added as dependencies. If the packages are installed to another project that the main project is referencing, do nuget.exe pack -includereferencedprojects. For more information, please refer to http://docs.nuget.org/docs/reference/command-line-reference#Pack_Command_Examples.
For issue 2, you have probably installed a solution-level package, which does not have Content or Lib folder inside. If you install a project-level package, you should be able to see the manage button.
Hope this helps.
I've added several Nuget packages to my multi-project solution with no issues. However, when I add this package -- ews.x64 (Exchange Web Services API) -- Nuget does not allow me to add it to any particular project.
The packages subfolder is created normally:
D:\TFSSource\Exchange\Utilities\Src\ExchangePurge\packages\EWS.x64.1.2
but when you attempt to manage the solution's installed packages, the "Manage Nuget Packages" dialog only offers an Uninstall button for this particular package. All the other packages have the Manage button allowing them to be added to the individual projects.
Also interesting is the fact that this package appears in a packages.config file under a newly created solution folder called .nuget? Any ideas what might be causing this?
Looks like this is a solution-level package, a package that doesn't have project specific content or libraries. The package is probably installed correctly and available to all projects at once.
source:NuGet FAQ