I run my onw nuget server for shared code I am using. When debugging blazor webassembly either via visual studio or via chrome (shift alt d), I only see the files in my assembly, not the referenced ones via nuget. I do have the symbols and the sources. Is there a way to debug step into those ?
Related
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 am trying to port a (very) old project of mine from Visual Studio 6 to Visual Studio 2010.
The project is an OpenGL application, and as such, it uses the following libraries (amongst others):
glu32.lib
glui32.lib
glut32.lib
opengl32.lib
The glui32.lib library links the libcd.lib library, which is not supported on Visual Studio 2010.
So I need to find a version of the glui32.lib library, which links the libcmtd.lib library instead.
My questions are:
Is there any such version of the glui32.lib library?
If yes - where can I download it?
If no - can I use the libcd.lib library on Visual Studio 2010?
If yes - where can I download it?
If no - is there any other way for me to solve this linkage error?
UPDATE
I'm leaving the answer below as the accepted one, but here is a workaround for porting an OpenGL project from Visual Studio 6 to Visual Studio 2010 (after creating the project in Visual Studio 2010):
Right click the project and choose Properties.
Open Configuration Properties --> C/C++ --> Preprocessor.
In the Preprocessor Definitions entry, add GLUT_BUILDING_LIB.
In the Runtime Library entry, choose Multi-threaded (/MT) or Multi-threaded Debug (/MTd).
Open Configuration Properties --> Linker -->Input.
In the Additional Dependencies entry, add glu32.lib;glui32.lib;glut32.lib;opengl32.lib.
In the Ignore Specific Default Libraries entry, add libcd.lib.
You can rebuild GLUI. The MSVS project they ship converts without issue to VS2010.
You will have to point it at your GLUT build though.
I have an ironpython app that uses dlls.
Some of the dlls written in c#, and one is in managed c++.
The app works fine on my host, and on any host that includes visual studio (2010) installation.
When I tried to run this app on hosts without vs, It failed. After some checking I discovered that ironpython cannot load the c++ dll.
After installing vs - the app runs fine.
I narrowed it down: the dll can be uploaded after the installation of:
-Microsoft application error reporting
-VC 9.0 Runtime(x86)
-VC 10.0 Runtime(x86)
-Microsoft visual studio macro tools
I tried to install Microsoft Visual C++ 2010 Redistributable Package http://www.microsoft.com/download/en/details.aspx?id=5555 and it didn't do the trick.
Why? what exactly happens in installation of vs, that doesn't occur when I install Microsoft Visual C++ 2010 Redistributable Package component?
How can I monitor errors that arise when loading dlls with ipy?
Thank you!
The DLL that is written in managed C++ uses a DLL for its standard libraries. You can change it to static libraries. Follow these steps
Open your project properties in Visual Studio (right click on the project)
Click you way to Configuration Properties > C++ > Code Generation
On the right, find Runtime Library and select Multi-Threaded Debug (/MTd)
Do the same for the Release build, but this time select Multi-Threaded (/MT)
Rebuild all
As for your specific questions :
1. The redistribuable installer will copy the DLL in the system path. Visual Studio will do the same thing. So if it doesn't work, make shure that you have the 32 or 64 bit binaries (same as your code, not the platform you are running). +If you are running from a console, close it and start a new one to get the updated path.
2. Use Dependency Walker. Loading your DLL will show you what it is looking for, it should be enough. To monitor its runtime execution, load IronPython. In the "Profile" menu, select "Start Profiling" and provide a command line that will reproduce your problem.
I am trying to debug the .Net framework source using VS2008 SP1. It is giving me the message :
Source Code cannot be loaded
Any help?
Have you followed the steps in this MSDN article?
To quote above:
The most recent version of Visual Studio provides new features for
.NET Framework debugging. To debug .NET Framework source, you must
have access to debugging symbols for the code. You also need to enable
stepping into .NET Framework source.
You can enable .NET Framework stepping and symbol downloading in the
Options dialog box. When you enable symbol downloading, you can choose
to download symbols immediately or just enable the option for later
downloading. If you do not download the symbols immediately, symbols
will be downloaded the next time that you start debugging your
application. You also can do a manual download from the Modules window
or the Call Stack window
.
I'm having some troubles debugging a solution which contains both a native ANSI C DLL project and a managed C#/WPF application project.
I call the functions exported by the DLL using the LoadLibrary/GetProcAddress Win32 API functions (DllImport attribute is not applicable for my program as the DLL is selected by the user). Both projects are built using the Debug configuration. The native DLL is copied to the bin/Debug directory of the C# program. When I debug the C# project, I can't step into the native code.
Is there a way to step into the native code?
It works when I debug the DLL project using the C# program, but then I can't step into the managed code...
I'm using Visual Studio 2010 Professional and Visual Studio 2010 Ultimate.
lg,
Dominik
In your C# Project: Project + Properties, Debug tab, tick "Enabled unmanaged code debugging". Single stepping from managed code into unmanaged code isn't going to work. You need to set a breakpoint on the DLL function you want to debug.