Develop Reference

Does nuget create separate packages?

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".

Visual studio won't read .pdb from my nupkg

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.

Nuget Package to install a file first time a package is installed only

How do I create a nuget package that installs a config file only once?
Basically, I'm adding a log4net config file (+2 transform files for Debug + Release builds) via a nuget package to my project.
I want the file to be added on the first install and after that - it should never be updated, since it might have been customized by the developer.
This question: Is there a way to tell nuGet to install a file, into a project, only if the file is not already in the project? seems like a decent answer - but I can't see where the $filesToMove variable comes from....
Btw. I only need this to work in VS2015 for now - so I'm fine with using install scripts. (yeah, short-sighted - I know :-)
I do need to support the fact that this package can be used in multiple projects in the same solution. In this case it must install the file the first time it is installed in EACH project and not just for the first project...

How do I know where NuGet puts my tools?

I have a project with some protobuf files. I want to compile these files to C# as a pre-build step.
So I add Grpc.Tools as a NuGet package to the project. And lo and behold, the tools are downloaded inside the solution's packages folder: packages/Grpc.Tools.1.6.1/windows_x86/protoc.exe.
Our CI server, on the other hand, uses a linux docker container (microsoft/dotnet). Is there a portable way to specify where to find the protoc compiler? Preferrably I would like to just ask the system: dotnet where Grpc.Tools or something.

I had a similar issue, in my case I wanted to pack C# code using ExcelDNA tools that come with the package. The post build event was added as part of the package install, but depended on the package folder been located in the solution folder, as you say. Porting the code to Net Standard we realised that the new version of nuget cannot deal with this specific issue of post build events which require the package tools to be in some folder relative to the solution or project. So to directly answer your question see here.
However you may not find that very useful if you want to do a post build event from the solution? If you are using jenkins et al and have a seperate step for packaging then the above should work fine.
There are a couple of ways around it. Most simply you can add the tools to source control, and then manually edit the post-build events. Depending on how you feel about that.
Secondly you can force nuget to resotre the packages locally and not in the system wide cache folder. You can do this through the Nuget.Config file. I have not got the specifics to hand, but if you cannot figure it out I can look in my old code.

How to see source code from github in Visual Studio IDE, but compile with dlls from Nuget?

Nowadays there's a lot of great open source packages and frameworks for all sorts of uses. Let's take for example, ASP.NET Core MVC and Newtonsoft.Json.
Those are shipped in Nuget packages, which are stripped of the source code.
I think many of you can remember a lot of situations in which one would like to see the source code freely available on GitHub (to help debugguing some issue), but was forced to do one of the following:
Be lazy and just forget about it, or continue debugging your issue with a popular library treating it more like a "black box";
Go to the browser, type github.com and search the source code without the mighty advises of the Visual Studio IDE;
Spend 5 minutes, clone the repository to the local drive and look at it with IDE;
Spend even more time while compiling the source code, deinstalling all of the nuget packages of interest from your projects and instead, hooking up directly to all of the freshly compiled assemblies (which are not always one-to-one to Nuget package).
This last option is the most viable, but you're left with a lot of time spent and you can't just push this to your repository or deploy the compiled code anymore. Other developers won't find those relative paths to the dlls and customers may end up with wrong versions of nuget packages baked in the deployment package.
Is there a fifth option which has all the pros of the fourth, but none of the cons? I imagine this being done by an IDE in an isolated fasion, i.e. no modification to my .csproj and package.config files, but the "Go to definition" & "Find all references" features and debugging should work as if I'm hooked up to the real stuff.
Yes, I'm pretty lazy.

Please pack the package as symbols package and then put the PackageName.Symbols.nupkg file with the ProjectName.nupkg file on the same package server after you downloading the package source code. I’m using following steps to debug my NuGet package source code in Visual Studio IDE.
Create my NuGet package project and implement the function that I want. In your situation, you just need to download the package source code from Github.com.
Build the project in your Visual Studio IDE, it will general a dll file and a pdb file in bin\Debug folder.
Download NuGet.exe and run this command to pack the source code project to package:
NuGet Pack MyProject.csproj -Symbols
There will generate two files, one is ProjectName.symbols.nupkg and another is ProjectName.nupkg. Upload these files to your NuGet Server. And you also can put them on your local driver.
Add your NuGet Server into your Visual Studio IDE through Tools -> Options -> Package Manager Console -> Package Source.
Open your project and install the package from the added package source.
Right-click your solution, choose Properties -> Common properties -> Debug Source Files, add the path where the PackageName.Symbols.nupkg file with the ProjectName.nupkg file stored on your local machine.
Now when your start debug your project and press F11 step into one function in your installed package, it will step into then package source code.

as mentioned in one of the comments, there is a VS extension that does this:
Nuget Reference Switcher (select one that matches your VS version to install), for more info, you can read its wiki on github.
here is what I usually do:
git clone the source repository
add the open sourced .sln/.csproj to your own solution:
run nuget reference switcher extension
This is equivalent to your step 4, but a lot less work since the heavy lifting is done by the extension.