Build Nuget Package Locally
Orencio Suhag
Local NuGet package feeds are simply hierarchical folder structures on your local network (or even just your own computer) in which you place packages. These feeds can then be used as package sources with all other NuGet operations using the CLI, the Package Manager UI, and the Package Manager Console.
In such cases, use the nuget init command to copy all packages in a folder to the feed as if you ran nuget add on each one individually. For example, the following command copies all packages from c:\packages to a hierarchical tree on \\myserver\packages:
For Visual Studio 2017 and later, the .NET CLI is automatically installed with any .NET Core-related workload. Otherwise, install the .NET Core SDK to get the .NET CLI. The .NET CLI is required for .NET projects that use the SDK-style format (SDK attribute). The default .NET class library template in Visual Studio 2017 and later uses the SDK attribute.
If you're working with a non-SDK-style project, follow the procedures in Create and publish a .NET Framework package (Visual Studio) instead to create and publish the package. For this article, the .NET CLI is recommended. Although you can publish any NuGet package using the NuGet CLI, some of the steps in this article are specific to SDK-style projects and the .NET CLI. The NuGet CLI is used for non-SDK-style projects (typically .NET Framework).
In the resulting list of project templates, select Class Library (with the description, A project for creating a class library that targets .NET or .NET Standard), and then select Next.
If you're unsure which framework to select, the latest is a good choice, and can be easily changed later. For information about which framework to use, see When to target .NET 5.0 or .NET 6.0 vs. .NET Standard.
To ensure the project was created properly, select Build > Build Solution. The DLL is found within the Debug folder (or Release if you build that configuration instead).
(Optional) For this quickstart, you don't need to write any additional code for the NuGet package because the template class library is sufficient to create a package. However, if you'd like some functional code for the package, include the following code:
The Package node appears only for SDK-style projects in Visual Studio. If you're' targeting a non-SDK style project (typically .NET Framework), either migrate the project, or see Create and publish a .NET Framework package for step-by-step instructions.
Give your package a unique Package ID and fill out any other desired properties. For a table that shows how MSBuild properties (SDK-style projects) map to .nuspec file properties, see pack targets. For a description of .nuspec file properties, see the .nuspec file reference. All of these properties go into the .nuspec manifest that Visual Studio creates for the project.
You must give the package an identifier that's unique across nuget.org or whatever host you're using. Otherwise, an error occurs. For this quickstart we recommend including Sample or Test in the name because the publishing step makes the package publicly visible.
This option is available starting in Visual Studio 2017 for projects that use the SDK-style attribute. For earlier Visual Studio versions, you must select Project > Unload Project before you can edit the project file.
If you don't see the Pack command on the menu, your project is probably not an SDK-style project, and you need to use the NuGet CLI. Either migrate the project and use .NET CLI, or see Create and publish a .NET Framework package for step-by-step instructions.
Scoping lets you create separate API keys for different purposes. Each key has an expiration timeframe, and you can scope the key to specific packages or glob patterns. You also scope each key to specific operations: Push new packages and package versions, push only new package versions, or unlist.
Errors from the push command typically indicate the problem. For example, you might have forgotten to update the version number in your project, so you're trying to publish a package that already exists.
You also see errors if your API key is invalid or expired, or if you try to publish a package using an identifier that already exists on the host. Suppose, for example, the identifier AppLogger-test already exists on nuget.org. If you try to publish a package with that identifier, the push command gives the following error:
If you get this error, check that you're using a valid API key that hasn't expired. If you are, the error indicates the package identifier already exists on the host. To fix the error, change the package identifier to be unique, rebuild the project, recreate the .nupkg file, and retry the push command.
When your package successfully publishes, you receive a confirmation email. To see the package you just published, on nuget.org, select your user name at upper right, and then select Manage Packages.
It might take awhile for your package to be indexed and appear in search results where others can find it. During that time, your package appears under Unlisted Packages, and the package page shows the following message:
If you've created a package that isn't useful (such as this sample package that was created with an empty class library), or you decide you don't want the package to be visible, you can unlist the package to hide it from search results:
In this example, the property specifies a file named readme.txt in the project root. Visual Studio displays the contents of that file as plain text immediately after it installs the package. Readme files aren't displayed for packages installed as dependencies. For example, here's the readme for the HtmlAgilityPack package:
Using TFS we are able to compile the core library, publish the resulting NuGet library and then launch the app's build which restores the NuGet reference to the core library. Everything works as expected.
The problem is that when developing the core library + the app we have frequent compiles of the core and cannot wait for the entire core library build to finish in order to update the app's local reference. Moreover we must push complete commits of the core library (so we cannot push one DTO at the time before testing them in the app).
So I was wondering if exists a way in Visual Studio and Nuget to publish/install the core's Nuget library in the local user's .nuget folder in order to let it be visible automatically to the app's project on the next build.
Starting from the answer of Lance Li-MSFT I made some changes for my needs. In fact, locally I do not have nuget.exe installed but only the .Net Core runtime, so I'm using the dotnet pack command instead of nuget.exe pack and dotnet nuget push instead of nuget.exe push. Moreover before pushing locally the updated NuGet package I delete the old package with the same version, else dotnet nuget push will not overwrite the package.
As a side note, I did not have to configure the package source in Visual Studio because the global Nuget cache (at the path %UserProfile%\.nuget\packages) is automatically used as the first place where to search for the NuGet packages.
Before publishing nuget package(nuget push) to one location locally, we should add the path as package source. So we need to set the path of local packages as package source firstly. The content in nuget.config file is corresponding to the Package Source UI in VS, so you have two ways to do it.
My problem is to automatize the nuget push command to the local feed, that in my case should be %userprofile%.nuget\packages. I cannot ask any person in the company to manually copy the core package to the local feed in order to see the changes in the linked app
For .net core library projects, VS have a option to create. the nuget package. You can right-click the project in VS and select Pack button.So you can also define a .bat file for this project to do the nuget push. The process is build the project=>use pack option to easily get nuget package=>run the .bat to automatically push.
First, we have to download the NuGet executable and add it to our PATH to use NuGet CLI comfortably. This will allow you to type nuget in your Command Prompt to run any NuGet script. You can skip to the next chapter if you already have it configured.
Thanks for your post that helped me get to enjoy using my nuget package locally. Just wanted to point out that I needed to make two changes to the Nuget.config file, an entry in the to point to the local NugetPackage and a corresponding entry in the .
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).
If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.
A NuGet package is a fancy way to share compiled code. In practice, a NuGet package is a ZIP file that contains the compiled code, resources used in the code, and a manifest for the package defining important information (such as the version). NuGet packages are a useful mechanism for creating and sharing .NET libraries, and they have become the standard. To use a NuGet package, you simply add a NuGet feed (package repository) and download. To learn more about NuGet packages, Microsoft has some great resources.
4a15465005