Visual Studio ignores breakpoints in different file - visual-studio

I'm debugging .Net Core in Visual Studio, and the breakpoints are working fine in the current file, but when a method from a different file is called, its breakpoints aren't being hit. I'm not familiar with Visual Studio because I usually debug in VS Code so I'm sort of lost.
I've googled it, but can't find any info - is it possible that VS ignores breakpoints in files other than the current one?
(It's ignoring the Debug.WriteLine I added as well but I just need to confirm if it's really not hitting breakpoints rather than not actually calling the method.)

Visual Studio ignores breakpoints in different file
If this issue is as phuclv's descroption, a net core project references a c++ Dynamic link library, you can follow the link, open the c++ project-->change it as mixed and then open net core project, choose Enable native code debugging. Also,
If you create the project in vs-code and then migrate it into VS2019,since vs-code is different from visual studio, you should try these steps:
1) delete the bin and obj folder first
2) make sure that these two options are checked under Tools-->Options-->Nuget Package Manager.
3) Try disabling Just My Code under Tools--> Options --> Debugging-->General
4) If the file is from the other project,please add reference to these projects by Right-click on the Dependencies-->Add Reference-->these projects or just copy these projects's dll and pdb files into the main project's output folder(Bin).
5) Use Debug mode to debug your project.
In addition, if these do not work, please try to create a new net core project in vs and migrate your old project into the new project to test whether this issue persists.

Related

UNITY_EDITOR undefined in Visual Studio

I'm debugging some code from within the Unity editor that starts with #if UNITY_EDITOR, but UNITY_EDITOR isn't getting defined though I'm running Visual Studio through the Unity editor. I've tried
Ensuring that I've got Visual Studio set in Debug mode (vs. Release)
The Scripting Define Symbols settings, and msc and csc solutions from here: http://docs.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html?_ga=2.148389495.1394951635.1638832224-1796620461.1636419298
I've also tried to just add a #define to the project sheets that Unity is generating, which doesn't work because there's no project files that these files are being opened & debugged through. And, I've regenerated solution files. What am I missing? Thank you!
Edit:
Some additional important information: this behavior isn't happening in all files within the Visual Studio instance, just files that are NOT included inside of any of the the .csproj's in the solution I have open. So, my workspace is .csproj's that do have UNITY_EDITOR defined, but the file I'm opening is from outside of that project. In this case, the .cs file I'm trying to debug into is from a package that is running, so the debugger will drop into it, but no .csproj is generated for this package.
It seems to me that there should be different behavior here, but I'm not sure what it is. Should Unity create a .csproj for packages whose .cs files you can debug into so that you can view them correctly in Visual Studio?
So, finally: in the context of the existing .csproj's that I have open, if I add a line <Compile Include="Full\Path\To\File.cs" />, it works as desired. Kludgy, but it works for my purposes.
In one of the existing .csproj's that I have open, if I add a line , it works as desired. Kludgy, but it works for my purposes.

Visual Studio breakpoints only work on second debug attempt

I have a VS 2010 solution with a web application project, and several class library projects to which the web app project has project references. When I am trying to debug the code for one of the class library projects through the F5 debug build process, the Modules window normally fails to load the symbols for the DLL in question, or if it does, the breakpoints are ignored anyway. However, on the second attempt at an F5 debug build, the breakpoints usually are recognized, and the code will halt in the required location.
I have tried ALL sorts to fix this issue - all the usual solution cleaning business, repeating the referencing procedure. I didn't see this issue until I upgraded to VS 2010, after which I rebuilt a new VS2010 solution from existing projects. I am beginning to think this is some sort of timing bug in 2010, as I am making no changes between the first and second attempt - it's as though VS 2010 is disregarding the dependendencies in the build configuration, and starting the web app build before the PDB for the class library is ready, or before it can locate the PDB for the class library.
Has anybody seen similar behaviour in VS2010? As you can imagine it is adding considerable amounts of 'productivity killing' time to my debugging, having to build everything 2 or 3 times just to get the breakpoints to be recognized.
Thanks if you can advise.
Try erasing the bin and obj folders between runs. does it help?
I have similar issues with a web server which does not get changes made to the configuration file on VS2010.

Break point not working and modules not loading dll files in VS 2010

I am using VS 2010 professional [64bit - Windows 7] and in my solutions, i have 3 class library project and 1 wcf service projects are there. All these dll's are refereneced in my WPF applications. For the last 1 year, it was working fine and i was able to debug the all the referenced projects. But from yesterday itself, debug is not working all of a sudden.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
When I checked in the Debug --> Windows ---> Modules window, all those projects dlls are not seen there and says no pdb files are available ???
But in the WPF bin\Debug folder, i have all the referenced dlls and their pdb are ther.
What could be the problem ?
Even I am not able to debugg the wpf project as well. For getting break point or debug, each time i have to clean the solution or project then rebuild it again. Then i will be able to debug the WPF project.
In the case of referenced dlls, I removed the dlls and added the new compiled dll again and copied that pdb files to the wpf project exe folder. Still no use !!!!
I have changed the options in the Debug and Options [disabling and enabling the Just my code options etc]. But still it is not working.
This is not only my problem. One of my colleague also have this problem we took the whole latest solution code from TFS. SO I changed the Local code path to a new folder and took the latest code from TFS again. Still the problem exists !!
I am able to run the application. But debug is not working. In the WPF project, all those dlls are referenced properly.
Can anyone help us ???
I guess I don't have enough points to comment to ask specifics, so this may or may not solve your problem but I'll take a crack at it. Also, there appear to be other questions about this. So I would check those out first to see if they will help.
This question was solved by adding configuration to tell the program which version of the framework to use during debugging.
Why doesn't VS2010 debugger stop at my breakpoints?
Why does Visual Studio 2008 skip over my break points?
If those don't help, I'll give it a go.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
This sounds like it could be one of the following issues:
Remote debugging and Visual Studio does not know where to load the symbols from or they are out-of-date
Need to clean and rebuild (which you seem to be doing)
The server you are running your WCF service on is not getting the updated DLLs and PDB files. If it's IIS Express, try killing the process between builds.
Also, make sure you are building in Debug mode and not Release mode. While building Release mode will generate the PDB files if it's set to do so which will allow you to debug an application, the code may be optimized as well which can cause breakpoints to be missed.

Removing all unused references from a project in Visual Studio projects

I just wondered if it possible within various Visual Studio versions to automatically remove all references from a project that were never been used?
In your answer, please specify which version of VS the solution applies to.
If you have Resharper (plugin) installed, you can access a feature that allows you to analyze used references via Solution Explorer > (right click) References > Optimize References...
http://www.jetbrains.com/resharper/webhelp/Refactorings__Remove_Unused_References.html
This feature does not correctly handle:
Dependency injected assemblies
Dynamically loaded assemblies (Assembly.LoadFile)
Native code assemblies loaded through interop
ActiveX controls (COM interop)
Other creative ways of loading assemblies
All you need is stone and bare knuckle then you can do it like a caveman.
Remove unused namespaces (for each class)
Run Debug build
Copy your executable and remaining namespace references to new location
Run the executable
Missing Reference DLL error will occur
Copy required DLL from Debug folder
Repeat 4-6
Gu Gu Ga Ga?
Throw your stone
You can also rely on your build tools to let you know which reference is still required. It's the era of VS 2017, caveman still survived.
The Resharper extension will do this for you.
This extension supports Visual Studio 2005 through 2017.
While the compiler won't include unused assemblies, extraneous using statements and references slows down Visual Studio and Intellisense, since there's more code the tools have to consider.
You can try the free VS2010 extension: Reference Assistant by Lardite group. It works perfectly for me. This tool helps to find unused references and allows you to choose which references should be removed.
In a Visual Basic project there is support to remove "Unused References" (Project-->References-->Unused References). In C# there isn´t such a function.
The only way to do it in a C# project (without other tools) is to remove possible unused assemblies, compile the project and verify if any errors occur during compilation. If none errors occur you have removed a unused assembly. (See my post)
If you want to know which project (assembly) depends on other assemblies you can use NDepend.
With Visual Studio versions 2017 and 2015, you can do this with the Code Map feature, but this feature is only available in the Enterprise Edition, not the Community or Professional versions.
Right-click on the project node in the solution explorer and select 'Show on Code Map.' This will display your .dll as a single node in a blank graph. Right-click on that node in the Code Map and select "Show Assemblies This References." This will add an additional node called "Externals" which can be expanded to show only the assemblies that are actually referenced.
For Visual Studio 2013/2015/2017 there is an extension that does exactly what you want: ResolveUR. What this basically does is:
reference is removed in the project
project is compiled with msbuild
check for build errors
restore removed references if there were build errors.
For anybody coming here looking for Visual studio 2012:
Download and Install Reference Assistant for Visual Studio 11
Later you can do:
In Visual Studio 2013 this extension works:
ResolveUR
Some people suggested to use an awesome tool - Reference Assistant for Visual Studio. The problem is that VS2012 is the latest supported Visual Studio. But there is the way to make it work in VS2013 as well ;)
And here is how:
1) Download Lardite.RefAssistant.11.0.vsix
2) Change the extension to zip: Lardite.RefAssistant.11.0.vsix -> Lardite.RefAssistant.11.0.zip
3) Unzip and open the extension.vsixmanifest file in the text editor
4) Find all occurences of InstallationTarget Version="[11.0,12.0)" and replace them with InstallationTarget Version="[11.0,12.0]" (note the closing bracket)
5) Save the file and zip all files so they are on the root zip level
6) Change the extension of the new zip to vsix
7) Install and enjoy :)
I've tested it with VS2013, thanks source for the tutorial
EDIT
Add to support VS 2015 Community Edition
<InstallationTarget Version="[14.0,15.0]" Id="Microsoft.VisualStudio.Community" />
Meaning of the brackets
[ – minimum version inclusive.
] – maximum version inclusive.
( – minimum version exclusive.
) – maximum version exclusive.
[Update] This feature is only available for .Net core projects.
This feature will be coming to Visual Studio 2019 very soon and already available with Visual Studio 2019 v16.10 Preview 1.
This option is turned off by default, but you can enable it under menu Tools > Options > Text Editor > C# > Advanced. Select the Remove Unused References command in Solution Explorer (Experimental). Once the option is enabled, the Remove Unused References command will appear in the right-click menu of a project name or dependencies node.
You can use Reference Assistant extension from the Visual Studio extension gallery.
Used and works for Visual Studio 2010.
In the VS2022 (preview at the moment of writing) this comes out of the box for SDK Style Projects (read: .NET Core and newer).
If it is available you can find it in the project context menu:
You get to choose what to do with each finding.
Read more about it here.
Pro-tip: Check if your project compiles and runs correctly after applying this. In my experience it doesn't check whether a dependency is used at runtime, for instance.
Using DevExpress, I follow these instructions:
In VS, go to DevExpress - Editor - Code Cleanup. Under Rules, check 'Remove unused namespace references'. Click OK.
Right-click on the solution, and choose 'Code Cleanup'. The cleanup runs for a few minutes, and finishes.
Build your application
The following method does not depend on any 'add-on's and is not very painful.
Step through each of your source files and
Select all (Ctrl-A)
Toggle outline expansion (Ctrl-M, M). This will reduce the file to two lines.
Click on the namespace's '+'. This will show each of the file's classes as a single line. Scan each class's reference count, looking for unreferenced classes.
Click on each of the classes' '+'. This will show each of the class functions as a single line. Scan each function's reference count, looking for unreferenced functions.
Scanning each file looking for '0 reference' takes only a second.
Scanning an entire project takes only a couple of minutes.
In VB2008, it works this way:
Project>Add References
Then click on the Recent tab where you can see list of references used recently. Locate the one you do not want and delet it. Then you close without adding anything.

How do I navigate to the source for a method in an external reference in Visual Studio 2005?

I have a C# project in VS 2005, with a reference to Foo.dll, a library of C++ .NET code, at c:\Foo\Foo.dll. It shows the reference in the Object Browser properly, but for a given object + method, I can't figure out how to navigate to the source for it inside of Visual Studio.
I've built Foo.dll myself from source on my local machine, and Foo.pdb is in the same location as Foo.dll, at c:\Foo\Foo.dll.pdb. I don't have a project for Foo in the solution I'm working within.
Looking at a stack trace from my C# app, I can see that it knows exactly where the source is on my system - I see a line that looks like:
at mycompany.Foo.SomeClass.SomeMethod() in c:\src\foo\src\SomeClass.cc: line 123
This is the right location for that source file, but I can't figure out at all how to easily have VS open SomeClass.cc. Does Visual Studio require that Foo be setup as a project in my solution in order to easily navigate to the source code?
Thanks!
Can you include the project in the solution and build by 'project reference'?
Is your application loading Foo.dll from the patch c:\Foo\Foo.dll? I'm guessing you actually have a copy of the dll in your application's bin folder. If that's the case, the .pdb file will need to be in the same location. Once you do that you should be able to step in to the code - Visual Studio should prompt for the code location.
One other thought - Under Tools > Options, look at the Debugging section. Under the General sub-section, see if "Enable Just My Code (Managed only)" is checked. If it is, uncheck it and then try to debug.

Resources