We maintain our own nuget server, and I recently set up a SymbolSource server (http://www.symbolsource.org/; the website is currently not responsive. Try the google cache or archive.org version of the website instead. The library you need to set up a SymbolSource server is available by nuget.) to complement the nuget server with .pdbs & source. After following this set of installation instructions (http://www.xavierdecoster.com/setting-up-your-own-symbolsource-server-step-by-step) I was able to upload symbols for a test nuget package. I created my test package on a different machine from the one I used it on in its nuget form so that my visual studio 2013 would not be able to find the source locally. I added an entry for the SymbolSource server in Visual Studio 2013 Tools, Options, Debugging, Symbols. In Tools, Options, Debugging, General I unchecked "Enable just my code," checked "Enable source server support," and unchecked "Require source files to exactly match the original version."
My test nuget package had deliberate error (divide by zero) so I would have something interesting to look at. When I created a host application and added the test nuget package, then invoked the path to the error, the exception flared, but instead of showing source code, a dialog box popped up asking me for the location of source .cs file. Since the source code for the test nuget package was not on the machine with the project using it, I was forced to click "cancel." Visual studio broke in code outside the nuget package. That was not what I had hoped for. I had hoped that visual studio would throw open the source code from the SymbolSource server.
The .pdb was downloading correctly. If I put a breakpoint in the calling code and stepped into the calls to objects from the nuget package, I would see the correct source code for the nuget package. If I then invoked code that threw an exception in a nuget object, the debugger broke in the source for the nuget package just as I hoped it would above. Once this happens, I can close and restart the project, and breaks inside the nuget assembly still pop up the source code downloaded from the SymbolSource server.
As best I can guess, when the exception is hit in the nuget package, Visual Studio 2013 downloads (or has already downloaded) the .pdb file. It then knows what source file it needs, but on an exception it does not download the source from the SymbolSource server. It instead opens a dialog box asking for the location of the source file on the local machine. If the source code has been downloaded for another reason (e.g. I have stepped into it), then it will find previously downloaded source code.
This seems to be either a Visual Studio bug, or I have missed some setting in Visual Studio. Is there something else I need to do to get the source code to download from a SymbolSource server on an exception without having previously stepped into the code in the nuget package?
Related
I am having a strange (new) issue with Nuget in Visual Studio 2019 (v.16.9.0).
The Solutions are all ASP.NET Web Apps (MVC). I run on a local LAN. In the Nuget Package Manager 'Allow Nuget to download packages' and 'Automatically check for missing packages during build are both selected. I am using Packages.Config for management and the source is https://api.nuget.org/v3/index.json. VS is able to communicate via the Windows Defender Firewall. The target framework is .Net 4.7.2
The first issue is when I do a package restore after deleting the packages in the folder, it shows this error: The requested operation cannot be performed on a file with a user-mapped section open.
After I do the build, the files are being created correctly, including the new/existing DLLs. These replenished/refreshed DLLs work perfectly and the program runs. The strange part, however, is that the relevant NUPKG file has zero content (which is obviously triggering the error). The message eventually disappears after completion of the DLL downloads I assume. All good so far but with zero content in the NUPKG file.
When I now try to update a package things go awry, the Error List shows:
An error occurred while trying to restore packages. The file is not a valid nupkg. File path...
Then after a full restart of VS, I get this:
An error occurred while retrieving package metadata for 'ABC.3.5.0.2' from source 'I:....\packages'. 'ABC' being the first file in the package list. It therefore appears to be failing because the relevant NUPKG has no content.
I am able to paste any file freely to the packages folder and its sub-folders, indicating that there is no lock on the files. Also VS is able to write the rest of the package structure to the folder without issue.
IMHO this must mean that something is specifically locking/blocking the NUPKG files (or deleting their content during creation perhaps?). A search reveals nothing that I can see.
I even tried creating a brand new solution. During creation, the identical error message above popped up a warning. I also tried a few other of my existing solutions and got the same result. I updated VS and then I even did a full VS reinstall to the latest version, all to no avail.
I first noticed the issue after defining dependencies during an Azure Web App deployment (the Azure deployment tool optionally allows for updates to Nuget packages). After the Nuget update failed I set the option to blank and deployed anyway, the idea being to manually update the packages later. I cannot be certain, but I think this is when I discovered the issue. Could this process have changed a VS config setting somewhere perhaps?
Before the reinstall I opened the devenv.exe.config from inside VS and changed the IPV6 setting to false. No luck, so I have changed it back. I also did a test on one of the packages, downloading the package from the Nuget site directly and replacing the VS downloaded version, but I get the same errors.
Install failed. Rolling back... Package 'System.Buffers 4.5.1' does not exist in project 'ClickAuth_Graph' Package 'System.Buffers 4.4.0' already exists in folder 'I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages' Added package 'System.Buffers 4.4.0' to 'packages.config' Removing package 'System.Buffers 4.5.1' from folder 'I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages' This file is not a valid nupkg. File path...\packages\System.Buffers.4.5.1.nupkg Central Directory Corrupt An attempt was made to move the file pointer before the beginning of the file. At line:1 char 1 • Update-Package System.Buffers +CategoryInfo NotSpecified: (:) [Update-Package], Exception o FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand
For the record I have one stale Nuget package in the portfolio. I don't use Github, but a repository was set upfront. I have not recently committed anything to Github.
Is there an expert out there that can help?
What you described is in a mess. And please try the following suggestions:
1) first clean all nuget caches or delete all cache files under C:\Users\xxx\.nuget\packages and I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages.
I think that you have download the valid nuget packages on it and if your local exists the same name,version nuget package, it will always use the local wrong nuget package. So you have to delete them and then download the right package from the nuget package source.
2) enter Tools-->Options-->Nuget Package Manager-->Package Sources and make sure that you have enabled nuget.org package source, and if you have other own feed which you want to use, also enable it.
If not, please try to close VS, delete nuget.config under C:\Users\xxx\AppData\Roaming\NuGet. And then restart VS to re-generate it. Then, re-add your own feed if you have it.
3) run update-package -reinstall under Tools-->Nuget Package Manager--> Package Manager Console and then also delete bin and obj folder of your project.
4) you could also try to disable Azure deployment tool
Besides, if you have other solution level nuget.config, please check whether its content is suitable for your project. And if it is useless, you could remove them.
There are several documented ways on internet on how to use Symbols Source files and Source Link to debug inside a Nuget Package but it's honestly hard to understand what is the good way for me.
We have an Azure DevOps Server on which we generate Nuget packages and at the same time publish the .pdb files to the Azure DevOps Symbol Server using an Index Sources & Publish Symbols task in our build pipelines as described here
My project' also has a reference to Microsoft.SourceLink.Vsts.Git and this code in the .csproj file
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
I've read several blog posts but the source I trust the most to be up to date is of course the official Source Link Git repository.
The readme.md file says
Including PDBs in the .nupkg is generally no longer recommended as it increases the size of the package and thus restore time for projects that consume your package, regardless of whether the user needs to debug through the source code of your library or not
I agree with that point that's why I want to use the Symbol Server, not to include the .pdb file in the Nuget Package. Therefore please don't flag my question as a duplicate of this one, because the accepted answer is exactly what I don't want to do.
The readme file also states that
.snupkg symbol packages have some limitations:
They do not currently support Windows PDBs (generated by VC++, or for managed projects that set build property DebugType to full)
They require the library to be built by newer C#/VB compiler (Visual Studio 2017 Update 9).
The consumer of the package also needs Visual Studio 2017 Update 9 debugger.
Not supported by Azure DevOps Artifacts service.
so at least I know I can't use that.
But what is the proper way to set Source Link up and working then?
When I debug my test console application it successfully downloads the .pdb file to my Symbols cache folder but if I try to step in the code coming from my Nuget Package using F11, it just doesn't work. (However it steps in System.String.Concat because my simple test Nuget Package is actually concatenating some strings)
I tried to run sourcelink test TestSourceLink.pdb but I get a error: url hash does not match. I read here that sourcelink test is a legacy thing and doesn't support authentication to private repositories like ours.
With my browser, if I visit the URL given by sourcelink print-json TestSourceLink.pdb I can see the latest source code. But now the question is, why is Visual Studio not able to download the source code? I'm authenticated to this Azure DevOps server in VS because I'm able to install Nuget Packages coming from this server.
Here are my debugging settings:
Thanks a lot. I really can't figure out what's the missing piece of this puzzle
Well, I should have read and followed this answer before posting my question because this was the missing piece of the puzzle.
I needed to follow steps 5 and 6 of Eric's blog post but I actually didn't need to modify my pack command because I'm not including the .pdb file in the Nuget Package.
[EDIT 2]:
Note: So far I could only get this working if the Nuget Package is generated with the Debug Build Configuration. If you find a way to get Source Link working with a Release DLL inside the Nuget Package, please answer my other question. Thank you
[EDIT]: Since I wrote a documentation for my company, here it is:
Summary:
This requires two things:
Having access to the Symbol file of the project (.pdb) which is a mapping file used by the debugger
Enable Source Link support so Visual Studio knows where it should look to download the source code while debugging
Set Up:
Component's project
For each project in your solution:
Only if you plan consumers of the Nuget package to use Visual Studio 2017. This step isn't required with you want to use Source Link with Visual Studio 2019:
In Visual Studio, right click on your project -> Properties then go to Build -> Advanced and change the Debugging Information from Portable (default value) to Full
Install the Microsoft.SourceLink.AzureDevOpsServer.Git Nuget Package
Edit the .csproj file and include the following code in the first PropertyGroup element:
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
Azure DevOps build pipeline
Create a pipeline variable called BuildConfiguration (if it doesn't exist already) and set the value to Debug
Use this variable as argument in your .NET Core Build task: --configuration $(BuildConfiguration)
In your .NET Core Pack task, use this variable in the Configuration to Package field: $(BuildConfiguration)
At the end of your pipeline you must have a task Index Sources & Publish Symbols
In the Artifact name field, the BuildConfiguration variable must be used too: Symbols_$(BuildConfiguration)
Of course you must also have a .NET Core Push task to push you Nuget package to your Azure DevOps Nuget Feed
Visual Studio
Tools -> Options -> Debugging -> Symbols click on the New Azure DevOps Symbol Server Location... button and authenticate to the server
Set the cache folder to a convenient location like C:\Symbols\. This is where all your .pdb files will be stored
Tools -> Options -> Debugging -> Symbols click on Load only specified modules. You can here specify the Symbol files of DLLs you want to load.
If you don't do this and leave the default to Load all modules, unless excluded, Visual Studio will take a very long time to load everything when you run your program in debug mode.
Tips : To see all the DLLs loaded by your project, when you're debugging, click on Debug -> Windows -> Modules. From here you can view the full list, select multiple and then right click Copy Value -> Copy Name
Tools -> Options -> Debugging -> General
Uncheck Enable Just My Code
Check Enable source server support
Check Enable Source Link Support
Consuming project
When you want to debug inside the Nuget Package's code, naturally press F11 to step into it and Visual Studio will ask if you agree to download the source code from your Azure DevOps repository
I have a solution that compiles and runs fine. However when trying to check it in to TFS I get the error :
"Could not find a part of the path C:\pathToMyProjects\MyProject\packages\System.Net.Http.2.0.20126.16343\lib\net40\System.Net.Http.dll".
I recently installed Visual Studio 2017 while the project was last checked in to TFS while being built in Visual Studio 2015 if that has anything to do with it.
I've removed System.Net.Http from references and Nuget packages. Even when all are uninstalled I get the same error. Any clues as to how I can figure out what the real issue is?
The error you have is mainly caused when you're trying to check in files which is no longer exist on the machine.
This will happen when TFS has some changes staged that no longer exist
on the file system. For instance, if you add some files in Visual
Studio (which adds them to the changes list), delete them directly
from the file system, then attempt to check in the changes, it will
complain that it could not find the file(s).
Just try below things to narrow down the issue:
Check if the file exists under the the specific path mentioned in the
error message.
Go to Source Control Explorer -> select these nonexistent files
-> Undo Pending Changes. Or you can just left these files in the Excluded Changes list to not check in them.
Re-install/upgrade Nuget packages in Package Manager Console:
PM > update-package System.Net.Http -r
Uninstall the System.Net.Http Nuget packages and remove the reference, then reinstall the System.Net.Http Nuget packages and add the reference again.
Clean and rebuild your whole solution, once that compiles and runs
fine locally, then try to check in the changes again.
Check if this issue also occurs on other VS machines, so we could
know that whether it is related to the VS Environment or others.
I'm able to successfully publish symbols to the VSTS symbol server as part of the build execution.
Followed this link to setup visual studio and everything good until this point. My symbol settings shown below:
When trying to debug, visual studio hits VSTS symbol server but return error message “Cannot find or open PDB file”
Below is the symbol load information provided by visual studio after trying to fetch from VSTS symbol server
As of November 15 2017 Visual Studio Online (also now known as Azure DevOps) the Index Sources and Publish Symbols build step handles the new portable PDB's create by dotnet build
You should tick Publish symbols and select your Subscription. The free tier has 5 users. You need to assign each user access to symbol server.
Ticking the Index Sources check box makes no sense though as the source files are on the build server, usually in an obscure location such as C:\agent\_work\34\s\... which will not match your local (or network path) to the source files.
To help Visual Studio find the source files you can do this... (you can avoid this by using SourceLink as described below)
Select the solution in Solution Explorer and then choose Properties from the shortcut menu.
Under the Common Properties node, choose Debug Source Files.
Click the folder Tools/ Options/ Debugging/Symbols folder icon icon. Editable text appears in the Directories containing source code list.
Add the path that you want to search.
When you start debugging all the symbols will download and you can step into the source code now.
This does NOT require disabling just my code and you do not need to enable source server either.
Unless you are using, or would like to use source server. It is pretty easy to do now by adding a few packages...
With AzureDev ops you can modify your build pipeline to make use of soruce files stored in GIT byt following this guide.
The prerequisite is .NET Core SDK 2.1.300 or desktop msbuild version
15.7.
On your package project project you need to add NuGet package "SourceLink.Create.CommandLine" which will enable your build server (and your local build machine) to rewrite parts of the Portable PDB's without changing anything in the build pipeline.
You also need to add a package to the correct source control. As described in this article. - I am using VSTS so I just install "Microsoft.SourceLink.Vsts.Git" package (must enable Include Prelease as of writing now)
To verify this works all you need to do is build the project and look inside \obj\{config}\{tfm}\ for a file called *.sourcelink.json and has the correct URL's inside it.
Then the usual pack and publish you would do.
In Visual Studio you just need to enable
Enable Source server support
Enable Source Link support
You need to run the application built in the same build as the build to publish symbols to VSTS Symbol server, the identity will be different in the different builds.
You can find that there is the GUID (0CD368C47775439…) in the Symbol load information, also you can check the Publish symbols task’s build log, there is the GUID too. Within a build the GUIDs will be the same and the symbols will be loaded correctly during debug.
Did you enable Source Server Support in the VS.NET debug options ?
You might also uncheck 'Enable Just My Code' in the VS.NET debug options.
There's a blogpost that I've recently written where I explain setting up and using a symbol server; might find some tips that might help you with your problem.
I've published some private/internal libraries as NuGet packages, using the symbols option. The packages and symbols are hosted on an internal network share. How can I step into these packages when debugging?
When I step to code from these packages, Visual Studio displays a "No Source Available" / "No Symbols Found" page. Clicking the "Load Symbols" only allows pdb files, not symbol packages.
These packages are not suitable for publishing on NuGet Gallery/SymbolSource.
What is the command that you used to generate the packages with the symbols? I tried to do the same exact thing nuget.exe pack -Prop Configuration=Release Framework.csproj -Symbols This creates two files: Framework.nupkg and Framework.symbols.nupkg. I put these files on a network share, used them from another project and debugging worked fine.
Have you tried putting the *.nupkg and *.symbols.nupkg files on a local disk instead of a network share?
There are a couple options; one is to set-up & configure your own symbol server.
You could also download Inedo's ProGet, enable symbol serving on the target feed, and then publish your packages to ProGet. All of this can be done with the free edition of ProGet.
disclaimer -- my day job is at Inedo
There is also now a tool called GitLink (https://github.com/GitTools/GitLink) which can insert into the symbol file links to versioned GIT files of your source.
You can set up your own symbolsource server internally using those network shares.
You can find a step-by-step tutorial on my blog.
It basically comes down to create an empty MVC application and run
Install-Package SymbolSource.Server.Basic
From there on you need to set up the hosting infrastructure and configure Visual Studio and build agents.
The way we do it (and works):
Generate "*.symbols.nupkg"
Deploy symbol package to SymbolSource server (private)
Configure IDE
Add required Library to project using NuGet (from our SymbolSource server)
Debug!
Links that can be useful:
SymbolSource server installation
Important: "Debugging Tools for Windows" won't install if it detects newer Visual C++ Redist version in the system than it needs/expects
Vs configuration to debug using SymbolSource
The URL to add is like http://your.symbolsource-server.com:[port]/[appContext]/WinDbg/pdb
I found that it doesn't work at all. NuGet package references are closed and cannot be used in the debugger. What I did instead was deleting the assembly reference from the project and instead added a reference to a Debug build of the DLL directly by path.
Then to make the debugger halt somewhere in that code, I inserted the call System.Diagnostics.Debugger.Break(); in that code. When running, the debugger will halt at that line, which is basically a code-defined breakpoint. This will open the correct source file and jump to that line automatically.
Open the library project in a second VS instance and move around the Break calls as necessary and rebuild the library. When done, remove those calls from the library code and restore the original reference (may need to reinstall the NuGet package).