When I build an ASP.NET Core project it copies to the output directory only its own .pdb files and all .dlls of any installed NuGet packages. However, it does not copy their .pdb files. I have to select them manually from the %UserProfile%\.nuget\packages directory.
I was wondering whether there is an option to enable NuGet package .pdb to be copied to the output directory?
The new way of doing this is, increasingly, to use SourceLink, which allows source code to be downloaded on demand while debugging.
NOTE: At the time of this writing there are still missing features, as pointed out by Martin Ullrich.
NuGet Symbols Packages and Symbols Servers
Traditionally, there were no .pdb files in NuGet .nupkg files.
Instead, the .pdb files were put into NuGet symbol packages (ending in .symbols.nupkg).
They can then be hosted on symbol servers (or the local file system), which can in turn be used by the Visual Studio IDE by configuring it accordingly. See also Specify symbol (.pdb) and source files in the Visual Studio debugger.
Do note that not all NuGet package publishers create symbols packages or use SourceLink - if you need to debug an open source library that doesn't have any, perhaps you should consider contributing them.
Related
I am still confused about how nuget works. I git clone a C# .sln project and from console, and I ran this nuget command:
nuget restore my_project.sln
it came to my attention that it generates two packages containing all dependencies required by my_project.
One package is located under my_project/src/packages, the other c:/users/my_user_name/.nuget/packages. While the file structures are a little different the DLL files in both packages are identical.
That confused me. Why two packages are generated by default? Where exactly does Visual studio look up for the project's dependencies?
More important, which config file should I update in order to only keep a copy of the dependencies and how can I specify the location in my file system for the packages?
Recent versions of NuGet support package references in project files.
This format will restore packages on demand, using your %USERPROFILE%.nuget folder as a cache. And your solution folder won't be "polluted" by a packages folder with binaries that you probably don't want to commit to source control.
VS2017 allows you to select "PackageReferences" or the older "Packages.Config" format when you create new projects (Tools/Options/NuGetPackageManager/General).
You probably have some projects in your solution that use the older "Packages.config" format, which stores in the packages folder in the solution directory, and newer "PackageReferences" format.
To convert the older projects to the new format, I believe you need to remove all packages from the project, then add them back again. They will be added using the default format you selected, with a prompt for confirmation if you selected "Allow format selection on first package install".
I have generated some nuget packages containing .pdbs with the following:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
I have verified the .pdbs are within the .nupkg generated in the lib/*/ folder next to the dll's.
However, when I consume these nuget packages in Visual Studio 2017, it only extracts the .dll's and not the .pdb's. Leaving me unable to debug into the package.
What am I doing incorrectly?
Since you can make sure the .nupkg contains the .pdb file. please make sure both the projects are in debug mode.
Consuming a nuget package locally sometimes has some difference from installing it from nuget.org. The .pdb source won't be found in solution. By default, the .pdb will locate under path like :C:\Users\xxx\.nuget\packages\PackageName\xxx.
Update:
If the nuget package project and the project which consumes it is on the same machine. The AllowedOutputExtensionsInPackageBuildOutputFolder property is enough. Since you have source files on same machine, and the debug engine can easily find it so that you can step into it.
But if for a scenario like this: You developed the nuget package. And share it to other team members. To make them can Step into you should embed the xx.cs files into the .nupkg.
Under this circumstances, the AllowedOutputExtensionsInPackageBuildOutputFolder may not work. I can't find a way to embed source files using it. You may need to use a nuget pack command like this issue. Actually, the way Stephan packed the project is correct. I've checked it work and will embed the source files and .dll and .pdb into the .nupkg. Of course, in this way you need to add the path to source files repo by Solution=>Properties=>Debug Source files:
In addition: You can add the nuget pack command in a post-build event, so that every time you build a project successfully, it will package for you.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.
I created a brand new NuGet package for internal use
it is:
private, not published on the NuGet repo
compiled in release mode
However, I'm able to step into the provided API! How can it be?
NOTE:
I moved away the actual source code. The project which is using the package doesn't "see" the package source code
By default, Release builds produce PDB files. Among other information, these PDB files contain locations of source files.
When you step through your code, Visual Studio loads the PDB file, from there it extracts full paths to source files, and as long as it can access them (which it can, provided that you've built your NuGet package locally), you get to step though library code.
just dont publish the pdb file :)
PS: if your VS knows the path to the sources from your Nuget Package, he will still be able on your PC to do a Step by Step debug.
I have several WCF and WebAPI services as well as MVC websites in a visual studio solution. Currently, we are creating WebDeploy packages for these services and websites to deploy to IIS. I'm starting to look into Octopus Deploy for deploying our services and websites instead of WebDeploy. However, Octopus Deploy uses Nuget packages to deploy.
I'm trying to figure out how I can easily create a Nuget package that contains all the files that would normally be published into a WebDeploy package. This may not be all files in the project directory or the bin directory. I found this blog post describing how to package a csproj into a Nuget package during the build, but I found that the resulting package didn't contain any of my dependency dll's. I realize I could write a nuspec for each of these projects manually and include exactly the files I want, but I'm looking for a more automatic way as this would create more maintenance when my project changes.
Does anyone out there know a good way to generate a nuspec or Nuget package that contains only the files needed to run the application, similar to the way publishing to a WebDeploy package only includes the files it needs?
Octopus Deploy has a CLI called "Octo.exe" that can package up your application into a NUPKG.
You will need to install Octopus Tools which you can download from https://octopus.com/downloads
Please see http://docs.octopusdeploy.com/display/OD/Using+Octo.exe for the documentation and how to use it.
A good example to use Octo.exe is part of a Continuous Integration pipeline when the build has successfully passed you call it to package the application and send it to the Octopus server.
After some playing around with Visual Studio, MSBuild, and TeamCity, I discovered a method that works for me. My issues was that I did not want to package up all the files in my project directory, only those that are necessary to run the application. WebDeploy handles this quite nicely as one of the options when publishing. I already have settings in my csproj file that will create a WebDeploy package on build, but this is a zip file and I don't want the zip file in my Nuget package.
I found 2 ways to deal with this:
In TeamCity, I set up a new Build Configuration that will package any nuspec files I have and publish the resulting Nuget packages to my Octopus Deploy Nuget feed. I figured out that I can use the existing WebDeploy package that gets created by my CI build configuration as an artifact dependency and TeamCity can actually unpack the zip file when grabbing the artifacts as part of that dependency. Then my nuspec file references the entire folder structure that was extracted from the zip file and packages it into a Nupak.
I was able to modify my csproj settings to use a specific publish profile I generated in Visual Studio that would perform a WebDeploy package to file system. This would result in the same folder structure as is in the zip file from #1, but simply copied to a directory. Then my Nuget build configuration could simply grab those dependencies and package them the same way as in #1.
I decided to go with option #1 as it would require minimal changes to my existing csproj and CI build configuration, and it would not break our current method of deploying using WebDeploy.
We have a .csproj that is being worked on by a number of people.
Unfortunately nuget has installed its 'packages' in different locations on each users machine, meaning when another user does an SVN 'update', their project wont compile because the .csproj file's 'hintpath' element is pointing to the dll in a different location.
Are there any other solutions to this?
Use NuGet packages restore feature and don't commit packages to source control.
This allows NuGet client application to download packages on demand. Downloaded packages will be located in solution folder, so, references to packages content will work at any machines.