I have packaged and published a symbols nuget packages for an internal class library within our VSTS environment. When I install the nuget package the bin folder gets the dll and pdb files.
When I try to step into the code it asks for the location of the source code file. If I do not specify the location I review Source Search information. It looks to be looking for the source code in the path specified with the VSTS Builder.
I know you can specify the symbols location with Tools -> Options -> Debugging area. However, I have multiple projects so would I have to define the symbols location for each project?
Is there a way to have it reference to the package folder by default?
Related
I'm trying to use the NetVips library in my VB.NET project, i've added the NetVips.Native.win-x86 in my project from NuGet, the issue is that instead of adding the reference to the Bin folder it's add the NetVips.Native.win-x86 in a folder inside bin called packages and when i'm trying to reference to the library methods in the project i'm unable to...
And if i try manually to add the references to all the NetVips dll i get the error that it's unable to reach assembly or COM.
So how can i make NetVips work?
It is normal behavior.
The NetVips.Native.win-x86 nuget package's runtimes folder's dlls are not the type of COM. Only COM dlls can be referenced under the project. They are native binaries.
And these three dlls are not for assembly references from the author's design.
And that is the folder runtimes folder's function. See this document.
These three dlls from the runtimes folder provide the necessary services for your application when your project is running and deployed. It is just that these three dlls are not the type of COM, which caused your problem.
Instead, you should use NetVips nuget package. The dlls from it are the type of COM. And you can use it.
Update
use Release mode, then move dlls like libvips-42.dll ... from runtimes folder into bin folder, get it.
I am unable to step into NuGet packages (either hosted in a folder, or on a server - in my case MyGet) compiled with symbols when attempting to debug into a .NET Framework class library (in my case an nUnit test project). I have tried everything here -
How to debug code in a nuget package created by me
To summarise what I have tried:
1) Compiling package with symbols, adding the folder containing the symbols.nupkg to the solution I'm debugging's Debug Source Files list. Adding the folder to the list in Tools -> Options -> Debugging -> Symbols. Tried 'load all modules' and 'load only specified modules'.
2) Enabling / Disabling 'Just My Code'
3) Manually copying the pdb files from the package project into my project's bin folder, no idea why this would still not work but it doesn't...
4) Adding the 'SourceLink.Create.CommandLine' package to my project.
5) Using a symbol source server (provided by MyGet)
EDIT: It appears that the debugger is using the versions in Temporary ASP.NET files, and only some have the PDB loaded for some reason. No matter what I use, symbol server, PDB files in the bin directory, it insists on only putting the DLL into Temp ASP.NET files.
All the DLLs here have been compiled with the 'Full' 'Debugging information' option, are not optimised, have the DEBUG/TRACE consts set, have the PDB inside the symbols.nupkg file - basically there is nothing special about the ones with the PDB in Temp ASP.NET versus the ones without :/
.snupkg is not an option for me as I'm using VS 2017.
I finally got this to work with this process:
1) Set up MyGet as the NuGet and symbol server.
2) 'Just My Code' can be enabled.
3) 'Source server support' can be disabled.
4) Options -> Debugging -> Empty Symbol Cache.
5) Options -> NuGet -> Clear NuGet Cache
6) Restore packages, build and run.
This works consistently for me with MyGet, but not with locally hosted symbols (in a folder).
Debugging into NuGet packages (again..) VS 2017
If you are not deploy the symbol package to SymbolSource server, you could not step into your nuget package, even if you have added the symbols folder to the solution. That because Visual Studio could not parse .pdb file in the nuget package.
For some details info, you can check another thread about this issue.
And, as a lightweight solution to debug the nuget package, you can use following method:
Is it possible to host both regular and symbols packages in a NuGet local feed on a network share?
Besides, MS team create a new .snupkg extension which creates a streamlined package debugging experience for the entire NuGet ecosystem. You can check the document for some more info:
NuGet Package Debugging & Symbols Improvements
Hope this helps.
I have 2 solutions, Source.sln and Client.sln both containing multiple projects.
After compiling Source I will copy all the dll and pdb to a Lib folder so that the projects in Client can use it. I added dll reference to this Lib folder for required projects in Client.
While debugging I couldn't step into the code of projects in source. I have referred so many SO and MSDN questions and did many changes. Apart from the steps performed below , could someone help me out to resolve this.
Clean and Build solution in Source. Copied new dll and pdb to Lib folder.
Enable Just my code is unchecked in debugger settings
Target framework matches in all projects
Symbol cache cleared
Debug info is set to full in Build-> Advanced Tab. Configuration is Debug
Deleted suo file from solution
Also tried to map the pdb at runtime from Debug-> Windows->Modules and for the specific dll. Getting an error like 'a matching symbol file was not found in this folder'
Please note that I am running a Unit Test
I've included a NuGet package (Edge.js) that I would like to debug by stepping into the source code. When I "step in" it "steps over". I'm guessing this is because there are no symbol file to step in to. Possibly the EdgeJS package was published without sources and this could be the reason. However I don't know how to verify if a NuGet package contains the pdb symbols.
It might also be that I failed configuration of Visual Studio but because I don't know if the NuGet package contains symbols I don't know which way to look.
Thanks for any help
Nuget supports creating packages that contain PDB and source files with the nuget pack -Symbols command. Usually, these packages are uploaded to symbolsource.org for open source projects. Visual Studio can be configured to use symbolsource.org during debugging, see this guide.
However, not every open source project uploads symbol packages to symbolsource.org, so you have to check whether Edge.js does (I don't know that library).
If Edge.js does not provide symbol packages, your options are as follows:
Download the edge.js sources and build locally with debug symbols. Copy the DLL and the PDB to the output folder of your application and start debugging.
Use a decompiler. You don't get as much information as with the debug symbols and source files, but it may suffice for your case. The decompiler that ships with Resharper (commercial tool) is pretty useful for debugging DLLs in this manner.
You can't "step-into" anything if you don't have the source code. Debug symbols won't help in this case.
You can step-into the decompiled code only by using third-party tools like RedGate's Reflector or Telerik's JustCode that decompile the IL on the fly and generate C# code for viewing purposes. These tools don't need the debug symbols to work, although they can use them to make the decompiled code more presentable.
I have included a dll file into my project. I reference it from a library folder where also resides dll's pdb file. When I compile I see both dll and pdb copied to main project's bin folder. On small projects this works wonderfully and I can debug into the dll with no problems. Sometimes, however, in larger projects, VS keeps asking for specific cs files even though their pdb file is included in the projects bin folder. That's ok if I can find those cs files, but it's annoying.
Why is Visual Studio sometimes asking for cs files and sometimes not?
It tries its best given the information it has, but sometimes that information is incomplete. When its ready to give up, it gives you the opportunity to provide the file, just in case you know better.
PDBs generally store the path to the file, as it was when msbuild was invoked to build the DLL. If the paths have changed (e.g. you're on a different machine to where the DLL was built, or just that files on the file system have moved) then the path information doesn't do it much good.
There is a process called source indexing that can embed enough information into the PDBs so that visual studio can re-locate the source files in your source control system (so that you get exactly the correct file as it was at the time of the build) but this is usually an extra step that has to be performed to modify the PDBs after the build has occurred.
Try this (from MSDN Forum)
Tools -> Options -> Debugging -> Symbols -> Empty Symbol Cache (button)
then
Tools -> Options -> Debugging General-> Enable Just My Code (checkbox)
and start debugging again. This should solve the problem if it was initiated by accidental third party components debug symbols that doesn't contains sources but storye only file paths.