I have a pretty simple application with some NuGet references and it works fine locally. I have not committed the packages folder of course, just the config. When I have TeamCity build the solution, I originally got the error that I needed to enable Nuget Package Restore so I did.
Now when I build I get the message
The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568.
Makes sense, but I get this error no matter how many times I build it. It continually fails. Am I missing something here?
Run the NuGet package restore before you build the solution.
Team City should have a NuGet Installer step which will restore the NuGet packages. Add this to your build steps before the compilation of the solution.
You an also do this yourself with a build step which runs:
NuGet.exe restore YourSolution.sln
However Team City's built in NuGet build step allows you to configure other things, such as private NuGet repository urls, easier than creating your own build step from scratch.
Related
In my company, NuGet packages are coming from different sources:
nuget.org (http://api.nuget.org/v3/index.json)
Microsoft Visual Studio Offline Packages (C:\Program files (x86)...\NuGetPackages)
Company_NuGetFeet#local (https://Company.pkgs.visualstudio.com/_packages/.../nuget/v2)
Supervision (some http://10.1.3.xxx/nuget site)
When I start up Visual Studio, I get logged in automatically (at the above right corner, I can see my login settings).
I have access to some NuGet packages and there are some where I don't have access to:
Company.Something.UA : OK
ControlzEx : OK
DevExpress.Chartsv18.2_Core : NOK
I have been doing NuGet restore in lots of ways: normal commandline, developer prompt, using the standard NuGet.exe, using the latest NuGet.exe, from within the company network, from outside the company network, ..., it does not make any difference.
In order to pinpoint the problem, I was thinking of restoring a single NuGet package, which should come from one specific package source, but what is that source?
When checking the properties of NuGet packages (being OK or not), the package source is not mentioned.
So I would like to do:
NuGet.exe restore DevExpress.Chartsv18.2_Core DevExpress..._Core_Package_Source
How can I do that?
How can I know from which package source I need to download a specific NuGet package?
There is no link. Package restore searches all sources in nuget.config (either system-defined or project-defined) for a package, in the order those sources are specified, and installs the first matching package it finds.
What you're really asking is "how do I install a package from a specific source", and you can do that with dotnet restore. Note that NuGet.exe is legacy and deprecated; its package restore functionality is integrated into the dotnet tool and improved there.
> dotnet restore MyPackage -s NugetSourceName
There is no way to know which source a package is available in without browsing it, but as stated above it shouldn't matter; package restore will figure it out.
Now (with .NET 6 tooling) you do have a way to pin packages (patterns) to specific package sources. The feature is called "Package Source Mapping":
https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping
https://www.youtube.com/watch?v=G6P38Dn69Ro
https://devblogs.microsoft.com/nuget/introducing-package-source-mapping/
I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project：
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.
I am on a Mac using .net core 2.0 and Jetbrains Rider. I have a network folder where I publish my private nuget packages.
nuget push <packagePath> -source <localNugetPath>
I delete a package from the local folder.
nuget delete <packageID> <packageVersion> [options]
This deleted the nuget package from the network folder but yet it still shows in Rider as an options.
nuget list [search terms] [options]
The above nuget list command will also show the package. How do I permanently get ride of the package?
NuGet does not allow for package delete and instead relies on unlisting the packages. This means:
This unlisted version is not shown in new searches and hence will not get auto resolved to, in new projects.
However, existing projects that have references to this unlisted version continue to work as before. (And that's one of the reasons for not allowing delete - so that existing projects do not break)
The package can shows because it cached. To clean all cache use command:
nuget locals all -clear
I have a project that consumes a NuGet package from a private NuGet feed. I also have a source code of that package in a separate project/solution. When I work on the project I want to be able to, temporarily add the mentioned source code of the package to the solution, so i can work on changes in both the project and nuget package simultaneously.
In Visual Studio 2015, with dotnet core and project.json/global.json I could add the NuGet package to the project and then modify the global.json to include the source from the disk.
global.json:
{
"projects" : [ "src", "../<path_to_external_source>/src" ]
}
That would, temporarily, change the reference to the project on disk. Before pushing to the build server, I'd just remove one line from global.json and remove projects from solution.
In Visual Studio 2017 and csproj based dotnet core I cant't seem to get that functionality. I have to remove the nuget package, add source code manually through "add/existing project" to solution, then manually add reference instead removed NuGet references. Then reverse all that before pushing to build server.
It's especially problematic when solution has several projects consuming the NuGet package, and I need to go thorugh that process with every one of them.
Is there a way to reproduce the functionality of global.json in VS17?
We have moved a legacy web site to git in TFS, and anytime the project is cloned nugget restores the packages per the package.config, and adds them to the packages folder. The subsequent build fails due to not being able to find the assemblies added through the nuget restore.
If you do a update-package -reinstall and the project builds successfully. Is this expected behavior or do I have a setup issue? The previous repo had the packages being checked in to eliminate this issue but I'd like to avoid that.
Is this expected behavior or do I have a setup issue?
Yes, this is expected behavior for NuGet, so do not worry that it is a setup problem.
NuGet Restore only restores files in the packages directory (\packages folder ), but does not restore files inside your project or otherwise modify your project. For example, if a package has added some reference DLLs or other files in your project, if you delete any of these files, they will not be re-added when restoring this package. This may cause the your project to not be able to find the missing dependencies when building.
Besides, the expected result is that the references should be used normally without broken after restore packages. In this case, we will not need to spend extra time using update-package -reinstall command line to uninstall and reinstall packages.
So use the "Update-Package -reinstall" command to force reinstall the package references and content files into project in order to resolve those references that were broken after packages restore.