To generate a NuGet package I'm currently using the command:
nuget pack project.csproj -Prop Configuration=Release
which I expected would package up the files in the bin\Release folder, i.e. the result of building the project. This folder has several MB of assemblies, however the nupkg file that gets created is only 7kb, which doesn't seem to include any of these files.
I'm running the nuget command from TeamCity so I'm trying to avoid manually editing a nuspec file.
What is the best way to package a project like this using NuGet?
TeamCity 7.0 is finally here and it has its own NuGet server built in.
You can simply ask it to take care of your packages whether you want to publish it locally or/and to nuget.org
TeamCity and NuGet
Related
I have a .NET project targeting .NET Standard 2.0. When compiled, this project yields an assembly in the ./bin/Debug/netstandard2.0 directory. I want to package this assembly into a NuGet package. However, I do not want to include the source code. In an attempt to do this, I currently am running the following from the command line:
dotnet build MyProject.csproj
dotnet pack --configuration Debug MyProject.csproj
dotnet nuget push bin/Debug/MyProject.1.0.0.nupkg --source https://nuget.pkg.github.com/my-organization --api-key [personal-access-token] --skip-duplicate --no-symbols true
The commands listed above successfully publish a NuGet package to my package registry. I can also successfully install this package via Visual Studio. However, when I attempt to compile the code, I get an error that says the namespace in the package cannot be found. I can see the package listed under the "dependencies/packages" node in Visual Studio. However, I cannot (or don't know how to) explore which namespaces are actually in it. But, when I right-click on it, and choose "Open Folder in File Explorer", I see the source code. I also see a *.nupkg file, a *.nupkg.sha512 file, and a .nupkg.metadata file.
My question is, how do I publish my NuGet package such that the source code is not included?
The dotnet pack would pack the code into a NuGet package. We recommend you use nuget.exe tool with .nuspec file, it could only pack your generated files.
Is it possible, as part of a CI process for NuGet package creation, to install a newly created package to a project, residing in the repository? So that the installation can be tested.
It's easy to do using Visual Studio UI, but how to do it on a newly created azure pipeline worker automatically?
Install NuGet package on the project in Azure Pipeline
I am afraid it is impossible to install NuGet package on the project in Azure Pipeline.
Because NuGet CLI install command line just Installs a package into the current project but does not modify projects or reference files (packages.config).:
It is like the command line nuget restore, just download the packages not install it.
To install the package to the project, we need modify the project file via access to visual studio objects:
https://github.com/NuGet/Home/issues/1512
So it should be impossible to install NuGet packages out of Visual Studio, check my another thread for some details.
Besides, we also do not recommend to install NuGet package in Azure Pipeline. If we install a newly created package to a project automatically, it will use the scripts to modify our Repos, which is not recommended and safe.
Personally, the correct process is:
Create the new package in the Azure pipeline.
Publish the new package to the Artifacts or any other nuget feed.
Install/Update the new package to the project with Visual Studio and test it.
Update the new package version to the Repos.
Hope this helps.
The NuGet.Client repo has a bunch of tests that install packages into test projects and assert various things. I know of a whole lot of PackageReference tests, but can't remember any packages.config tests. Using the .NET CLI it's easy to script a lot of it, but depending on what you want to do, you might need to write some code to manipulate XML files.
Here's a bunch of useful commands totally written from memory and therefore might not work as is, but it'll get you started:
# create a new .NET Core console app. You'll need to edit the csproj to test different frameworks
dotnet new console
# create nuget.config file
dotnet new nugetconfig
# add a local folder as a package source
nuget sources add -configfile nuget.config -name local -source ..\newPackages
# set the global packages folder to a empty/temporary directory, so the test package
# doesn't pollute the agent's global packages folder
nuget config set -configfile nuget.config globalPackagesFolder gpf
# add the latest version of the package to the project in the current directory.
# use --version to specify a version
dotnet add package MyTestPackage
Since SDK style projects are so short and simple, you may be better off just hardcoding the contents in your code and write them to disk for your tests. It's what we (NuGet.Client) do.
We have plans to eventually move the config options to the dotnet cli so that you won't need to download nuget.exe, but it's really low priority since it's so easy to workaround. nuget.exe works on mono on Linux and Mac, or just hardcode the conents of the config in a string in your test and write it at runtime.
This will only be useful for you if the things you want to test are not impacted by package compatibility issues with PackageReference vs packages.config. However, given the future of .NET is SDK style projects, and SDK style projects don't support packages.config, you can try justifying it by saying it's the future.
I've tried with Nuget Update, Nuget restore, but they are actually not the same and here's why:
I've created a Nuget pkg only to distribute an executable file. When I install the Nuget the executable is added to my project so I can reference it and run it within my application.
Now, I don't want that every developer has to install the Nuget to have the executable in their project, but I just want the .exe to be added when the project is built. And of course, the reference to the package in the config file is present.
If I run Update-Package -Id -reinstall(using the Package Manager of VS) a folder with the .exe is added to the project root, but if I do nuget update or nuget restore (using the nuget CLI) it only re-add the .exe into the packages folder.
The reason why I need to run the nuget CLI is because I'm using TeamCity and I want to add the .exe when the automatic build runs.
I hope it makes sense.
How reproduce VS2017 Package Manager command “Update-Package -reinstall” with Nuget CLI
I am afraid you can NOT do such things with NuGet CLI. That because NuGet CLI does not modify a project file or packages.config. When we modify the project file, we need to do it by NuGet API in Visual Studio, but only package manager console can provide access to visual studio objects:
https://github.com/NuGet/Home/issues/1512
That is the reason why I said the easiest way is using the command line Update-Package -Id -reinstall in your previous thread. Then I also gave you another way to resolve this issue from the root cause, using .targets file to copy the executable file to the the project root, please check my update answer.
Of course, there is another simple idea to resolve this issue, just add a pre-build event in your project to copy the executable file to the the project root:
xcopy /Y "$(SolutionDir)packages\MyToolPackage.1.0.0\Tools\wkhtmltopdf.exe" "$(ProjectDir)"
Hope this helps.
Those files are created during package restore that's why I assume they don't have to be in the repository. Is there further documentation of the purpose of those files which might help to answer the question?
For a .NET Core project the nuget.g.targets and nuget.g.props are generated by a NuGet restore. They are created in the obj folder. So you do not need to have these in version control. Typically files in the obj folder are not included in version control.
Visual Studio will automatically restore these files on opening a solution if they are missing.
If you are using a build server then you can run dotnet restore to restore these files. MSBuild 15 when installed with Visual Studio 2017 can also be used to restore these files by running msbuild /t:Restore for the solution.
The nuget.g.targets and nuget.g.props files define various properties, such as the path to where the packages cache is on your machine. They also include any MSBuild imports that NuGet packages referenced by your project need.
For example, if you have the Microsoft.Net.Test.Sdk NuGet package referenced, the nuget.g.targets and nuget.g.props import MSBuild files that are included in that NuGet package. When using a packages.config file these imports would be added directly into your project file (.csproj).
.targets files are included referenced from the project file, thus need to be in place when the project file is read. If NuGet package restore is done at the start of the building the project then those files do not exist at the point the project file is read.
Hence putting these files into source control so they always exist when project files are loaded.
A different approach is to have a project (which all other projects depend on) that forces NuGet Package Restore for the whole solution (but doesn't itself use any packages). After it has build then all targets files are in place when the project files are in place.
Of course many NuGet packages do not use such files and this is not an issue.
I'm using Visual Studio Team Services to automate the creation of a nuget package. This package has a dependency on another nuget package (Newtonsoft.Json v8.0.3). I have configured a Nuget Packager task as part of the build:
But the generated package doesn't contain the reference to the nuget package:
Running the following script on my local machine to generate the package:
nuget pack myproject.csproj -Symbols -IncludeReferencedProjects -Properties Configuration=Release -OutputDirectory bin/Release
I can see that the dependency is added to the generated package:
What am I missing here? Why the dependencies are not being added to to package that is being generated on the build server?
"IncludeReferencedProjects" is used to add the referenced project to the nuget package, not the referenced nuget packages.
Include referenced projects either as dependencies or as part of the
package. If a referenced project has a corresponding nuspec file that
has the same name as the project, then that referenced project is
added as a dependency. Otherwise, the referenced project is added as
part of the package. Learn more at NuGet.org.
When you create the nuget package for the project which referenced to another nuget package. The nuget package dependency will be added automatically if the nupkg file exists in the packages folder. For your issue, you can add a "NuGet Installer" task in your build definition to restore the nuget package files for your solution. And then when you create the nuget package for your project, the referenced nuget package will be added as dependency.
I have found a solution for my problem, even though I don't understand why the package was not being created properly.
So basically I have 2 builds:
a "generic" build that will compile the entire solution and run unit tests, etc (automatic, triggered on commit)
a build to generate the nuget package (manual)
This problem is on the 2nd build. I was trying to understand what were the differences between creating the package manually on my local machine and creating the package on the build server and I realized that on the build server I was not getting the source code for the solution, only for the project folder and the .nuget folder. Given that I have more than 40 projects in the solution it makes no sense to get the whole source code for the 2nd build, right? But for some reason this is not enough to generate the nuget package properly.
So, the solution to my problem was to get the source code for the following files/folders:
Project folder
.nuget folder (needed when restoring/installing the missing packages)
Solution file (mysolution.sln)