I have a set of Nuget Libraries that I compile and modify myself.
I build them without publishing on any Nuget server. (It is not my library)
On the other side, I have a project that use such Nugets, but I wish to debug them...
In the best situation I wish to:
use my local .dll and .pdb
debug by using local .pdb and (updated) source code
I'm looking for the best possible solution, if possible by loading all local symbols,
but I'm not sure it is possible.
Maybe I have to build on my own local Nuget server and use a local Symbol server too, but it looks overkill?
Maybe I have to build on my own local Nuget server and use a local
Symbol server too, but it looks overkill?
As far as l know, when you want to debug a nuget library in a new project, you must add the required nuget.pdb and related xxx.cs source files in the new project.
According to your description, the nuget package is created by yourself which is more easiler to realize it:
1) If you have the nuget.pdb file and the corresponding cs file on the local, you just need to put the PDB file in the output file of the project which references the nuget, and then right-click on the Solution-->Properties-->Common Properties-->Debug Source Files-->to add the folder path which the cs files exist into it.
2) If you do not have the current nuget.pdb file and related cs source files for debugging on the local, you need to include these files in nuget.nupkg when creating the nuget package by using nuget.exe cli with xxx.nuspec, so that these files can be added to the current agent when you install the nuget package.
**Note:**This is the special steps for creating your nuget package:
A) please make sure that you have downloaded the nuget.exe and then set its path to environment variables so that it can be called in CMD. You can refer to this.
B) Open CMD, type cd xxxxxx(the path of the project which contains xxxx.csproj)
C) type nuget spec to generate the xxx.spec file
Then open it and add like these:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
........
</metadata>
<files>
<file src="bin\Debug\ClassLibrary11.pdb" target="lib\target framework version (like net472 or netstandard2.0)" />------ClassLibrary11.pdb is the nuget.pdb
<file src="Class1.cs" target="src" />------Class1.cs is the source file
</files>
</package>
D) then type nuget pack to generate the nuget package which contains these debug files.
E) when you install this nuget package in a new project, please do not forget to clean the nuget cache first. After that, you should add the path of the resource files into Debug Source Files.(the resource files exists in the C:\Users\xxx\.nuget\packages\package name\src or C:\xxxxx\ConsoleApp(project folder)\packages\package name\src)
Edit
F) When you start debugging it, please do not forget to disable Just My Code In Tools-->Options-->Debugging-->General-->uncheck Enable Just My Code.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.
In addition, you can refer to this similar issue.
Related
I have a common project that I build and create a nuget package from, for consumption in my other applications.
The build process for the common project both creates a nuget package, deploys it to our private nuget repo and pushes the symbols to our internal symbol server.
In my "other applications", in this specific case an ASP.NET website, I pull in the nuget package from our repo but when I try to step into code in that assembly it just skips over it. I cleared my local symbol cache and as soon as I start debugging VS pulls in all the symbols from the symbol server so I know that bit is working.
Can anyone help me?
You need to publish Nuget package with symbols and refer to them using the Symbols under Tools->Options->Debugging->Symbols.
See HOW TO DEBUG A .NET CORE NUGET PACKAGE?
Other members also asked the similar issue before:
How to debug code in a nuget package created by me
Update:
Since you want to step into code in the assembly, you still need to provide the source code file in the NuGet package alongside the dll.
As we know:
A symbol is a file containing metadata that represent the link between
your original source code and the machine code that has been
translated by a compiler.
In the Microsoft world, a symbol is represented by a .PDB (Program DataBase) file. It is the heart of the debugging process because thanks to these metadata, the debugging tools are able to correlate the instructions executing in the application to the original source code and providing features like breakpoint or variable watchers.
So if you only provide the dll and .pdb file, you still not step into the code, you also need provide the source code, then add the source code to the Debug Source Files for the solution that references the package:
More detail on providing the source code:
If you're currently packaging without a Nuspec, you'll need to create a Nuspec, then add the pdb to the list of files in the lib folder and source file in the src folder. "NuGet spec" may be a useful command for generating the initial spec as defined in NuGet docs. Below is my .nuspec file, you can check it:
<?xml version="1.0"?>
<package >
<metadata>
<id>MyTestPackage</id>
<version>1.0.3</version>
<authors>Admin</authors>
<owners>Admin</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package description</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2017</copyright>
<tags>Tag1 Tag2</tags>
</metadata>
<files>
<file src="bin\Debug\MyTestPackage.dll" target="lib\Net46" />
<file src="bin\Debug\MyTestPackage.pdb" target="lib\Net46" />
<file src="Class1.cs" target="src" />
</files>
</package>
More detail on add the source code to the Debug Source Files:
When you have a solution open, right click on Solution, select Properties...Common Properties...Debug Source Files, and add the root source directory for the relevant binary reference:
We have the following project structure in a solution:
.\Project2
.\Project1
Project2 is dependent on Project1. Project1 is shared across multiple projects. I added the nuget packages (Roslyn for example) for Project1 when it was part of this solution. The problem we are having if either we try to compile Project1 by itself or compile it when its in an entirely another app it fails:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ../../Project2/packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props.
If i open the project file in a text editor it has the following statments in the project file:
<Import Project="..\..\Project2\packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\Secured Account Access\Member\packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props')" />
If of course removed all the nuget references and then just opened the individual project and added the nuget references. Which fixed when i was trying to compile the project by itself and broke it when it was part of the solution because VS will no longer restore the packages for Project1 while its in the solution.
I'm not sure why VS/Nuget works this way. Why not always have a package folder for each project? Disk Space savings (which would be absolutely nothing)? You should never have references that look like the following:
../../Project2/Packages/MyNugetDepedency.dll
Is there any way to get around this and have everything just work.
The packages folder is determined by the solution the project is contained in by default. You can override the default packages directory by specifying the repositoryPath in a NuGet.Config file.
<configuration>
<config>
<add key="repositoryPath" value="../MyPackages" />
</config>
</configuration>
To have multiple solutions all share the same packages directory you can create a NuGet.Config file, with a repositoryPath setting, in a directory that is a parent to all the solutions. NuGet will then work its way up each directory until it finds a NuGet.Config file and then use the repositoryPath defined there. This repositoryPath is relative to the NuGet.Config file itself, unless you have specified a full path. A relative path is probably what you want so other developers do not need to check out the source code to the same directory.
OK,
So i recently reinstalled windows 10 and upgraded vs2013 -> vs2015. At this point i tried to grab a couple of nuget packages.
The problem i am having is that i have a .nuget/packages folder at the same level as my solution file (set via NuGet.config) but i also have exactly the same folder getting created in the root of my user folder.
the packages folder for my solution contains the packages installed for that solution, while the one i don't want in my user directory contains all the packages for all the projects and solutions i am working on.
Is there a way i can prevent this .nuget folder being created in my user directory? it seems useless when i already have package folders for my solutions
Thanks
You can clear the .nuget\packages directory under your user profile however the packages will be downloaded again if you install them again.
Package retrieval
%USERPROFILE%\.nuget\packages is the local machine cache used by NuGet v3 when installing NuGet packages for new project types, such as Universal Windows projects.
For a C# console project NuGet will use the %LOCALAPPDATA%\NuGet\Cache directory which is also what NuGet v2 uses.
ASP.NET Core projects currently use their own %USERPROFILE%\.dnx\packages directory for NuGet packages.
Specifying a custom NuGet package location
To prevent NuGet from copying the packages to your user profile you can create a new %NUGET_PACKAGES% environment variable pointing to the location where you want NuGet to copy the files e.g. C:\git-repositories\.nuget\packages.
To prevent NuGet from copy the packages to the solution folder too you can create a new NuGet.config file either in the solution folder or at any higher level up to the root. As content you can specify following XML.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\git-repositories\.nuget\packages" />
</config>
</configuration>
As help for configuration inheritance please follow this link: NuGet Configuration Inheritance
I have a solution in Visual Studio 2015 with about 40 projects in it. Some of these projects have some NuGet packages referenced.
Due to a combination of our branching strategy (where each project folder is branched individually) and our security requirements (that the NuGet binaries are actually checked into TFS) I would like the NuGet packages for each Project to be installed into each Project's folder, not in the solution's folder. Space usage is not a concern here.
I've looked at:
https://docs.nuget.org/consume/nuget-config-file
https://docs.nuget.org/Release-Notes/NuGet-2.1#Specify-packages-Folder-Location
And they've helped my understanding of how the config files work... but I can't seem to get it to do what I want.
I've tried this in my config file:
<configuration>
<config>
<add key="repositoryPath" value="$(ProjectDir)\Nuget\" />
</config>
</configuration>
But it creates a folder in the solution folder actually called '$(ProjectDir)'.
And I can't hardcode the path to the project folders (i.e. 'C:\myteam\teampackages' in the NuGet docs) as pretty much everyone in the team have different paths to their local workspaces!
How can I do this?
Firstly, you should not check in NuGet packages into TFS Version Control. As one of the advantages of using NuGet is that you can use it to avoid checking in binaries to your version control system.
Instead, you need to restore NuGet packages during TFS build process and the required packages will be downloaded. In VS2015, you need to follow steps in this blog: https://docs.nuget.org/consume/package-restore/team-build).
Some key steps are (assume you're working with XAML build):
Add following items to the solution. (Content of the nuget.config and .tfignore file can be found here)
Add one build.proj file under the root path of the solution folder. (Content of the build.proj file can be found here)
Create one folder named tools under the root path of the solution folder. Create NuGet sub-folder under tools folder, download and save nuget.exe under tools\NuGet path.
Check in nuget.config, .tfignore, build.proj and tools\NuGet\nuget.exe into TFS version control.
Modify the build definition to choose to build the build.proj file.
Then you will have NuGet packages restored successfully during the TFS build process.
The Nuget docs mentions specifying package folder location is to have many different solutions share the same package. This is an opposite scenario as your. Repository path setting only allows you to install the NuGet packages in the specified folder (like C:\teampackages ) or for relative path (like ../Nuget).
To make installing package in different repositoryPath, you can try:
<configuration>
<config>
<add key="repositoryPath" value="../Nuget" />
</config>
</configuration>
Check case: Is it possible to change the location of packages for NuGet?
How can I get Visual Studio to build a NuGet package for my library component on build?
I’m using a Portable Class Library as the example project.
Ensure the NuGet.exe file in .nuget folder is latest.
Default values come from AssemblyInfo.cs, so clean that up.
Add a NuGet package reference if you do not reference any, preferably something simple like JSON.NET. Often, PCL projects have no external dependencies, in which case no NuGet refs and without any NuGet refs, the required MSBuild config won't get set properly, so we need to add a 'dummy'.
Enable NuGet Package Restore.
Edit the NuGet.targets file and ensure BuildPackage is true.
<!-- Property that enables building a package from a project -->
<BuildPackage Condition=" '$(BuildPackage)' == '' ">true</BuildPackage>
Edit your .csproj file and add this to the first, default PropertyGroup
<BuildPackage>true</BuildPackage>
Rebuild your project and then search in the Output for nupkg and confirm creation and location of the package file.
Remove the dummy NuGet package reference and build again and check the Output.
To further customize the package creation, you can stick a MyProjectName.nuspec file next to your .csproj file.
See http://docs.nuget.org/docs/reference/nuspec-reference for more on the NuSpec format. You can also pull one from an existing package (its just a zip file) and have a nose around, see how it was done.
Add a post-build event like this:
$(SolutionDir)\.nuget\nuget.exe pack "$(MSBuildProjectFullPath)" -p Configuration=Release -o "$(MSBuildProjectDirectory)\bin\Release" -symbols"
And download and place nuget.exe in the .nuget folder alongside your solution file.
You can use nuget update -self to keep the .exe fresh.
Note
nuget.exe pack has a bug currently where it'll see a packages.config file and try to look for the packages it mentions in your solution but it fails to find them if the packages folder is in a strange place, e.g. if your solution file isn't a level up from the project.
To workaround this, add another post build event to copy the packages folder into the project folder.
The repositorypath config setting seems to do nothing for me.
See GitHub reports:
https://github.com/NuGet/Home/issues/5316
So funny. I was having problems with my usual way of auto-building a package on build when I arrived at this new way. So I looked for a suitable SO question to answer with my new post-build method when I came across my own question here!