This seemingly simple problem has been driving me nuts for two hours. I want to attach a debugger to an app but VS 2012 refuses to load symbols from its PDB file. It works without a problem in VS 2010. The PDB is of the same name as the .EXE and located in the same folder.
This is a screenshot from VS2012:
And this is a screenshot from VS2010:
As you can see everything looks OK on both screens. However, this is another screenshot from 2012:
And this one is from 2010:
It's an exact same process.
It took me an hour of googling, searching and banging my head against a wall to try in VS 2010 and to find out that everything works well there. At first I was convinced I was doing something wrong.
Binary was not built with debug information.
Huh?? There is a PDB file, what other debug information it needs? It was obviously built with debug information since 2010 doesn't complain at all and I've debugged what I wanted just fine.
The app being debugged is compiled in VB6 (as in classic, legacy VB, not VB.NET).
Any hint, comment or question is welcome...
Related
I have a problem with visual studio 2022. I am creating a WPF app in vs 2022 version 17.2.4 using .NET 7 Preview. When I build the solution or press Start Debugging or Start Without Debugging, Visual studio won't update the compiled code(Won't replace binary files with the latest ones) and the behavior of the program won't change to correspond to the code. The problem does not persist when I press Build->Clean Solution and then Build->Build Solution. It does the same whether I build the solution with the debug or release configuration. I tried it with other solutions as well and the problem will not go away. So I know how to deal with this, but it seems weird and annoying nonetheless. It's the first time that I encounter something like this.
P.S.(Yes the solution compiles with no errors or warnings)
When I attempt to debug a unit test on VS Mac, I see the following:
In the solution options, I don't see anything about locations to find source files. And I'm certainly not interested in disassembly.
I did try using version control to move the code to a PC. There I could debug with no problems. I also found Cannot find .cs files for debugging .NET source code, which appears to be similar, but not Mac-oriented, and the menus are different on VS Mac, so I can't try the answer from that question.
How can I get it to debug on VS Mac?
I need some help. I have put in dozens of hours into a VB.NET project, it has been built in release mode and distributed. Now I have to make some changes to it, and I am unable to debug it properly. My code changes result in behavior where my code is not even recognized.
Also, I installed Visual Studio 2013 recently (moving from 2010), but this project behaves the same in both environments.
I believe that my code has become 'optimized'. The error window tells me that code is being skipped over, and that my code is optimized and JIT is checked.
I have turned off JIT, and I have tried everything to make this project work again that I could think of. I am desperately wanting to know how I can get this project to be in a state where it will debug each line of code again when I make changes.
I can even purposely write bad code, and the debugger does not see it.
This project is now in debug mode, not release. I have checked and followed threads on every thing that other people have done to solve this issue, but nothing works for me.
Either my project launches and works properly as it is coded, or if I change any code only the form launches with no code being run - at all.
please help.
I finally figured it out. The applications that I was struggling with were all built in Visual Studio 2010 on Windows 10. I was trying to work with these in Visual Studio 2013 on Windows 7.
Once I tried to work with them on Windows 10 (visual Studio 2013 this time), they started working and debugging just fine.
I think it may have been DLL assembly paths? Took me more than a week, but I figured out my issue by moving from Win7x64 to Win10x64.
I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
I'm debugging classic asp code using VS 2008 sp1 on windows 7. Everything works great, I attach to the process and can debug. However, If I stop debugging visual studio will crash.
I read the recycling the app pool would help, but it has not helped me end a debugging session with out crashing. I have hunted through Google and stack overflow for a solution, but so far I've mainly found complaints.
Has anyone figured this out?
Coworker found answer:
http://code.msdn.microsoft.com/KB967631
This QFE fixes three complete separate issues in the VS2008 SP1 Debugger:
Debugger can hang the IDE after setting a breakpoint when working with a large C++ project
Breakpoints do not bind correctly when an MSIL file is built containing .line directives
VS crashes when debugging a classic ASP web and debugging is stopped.
I have had this same problem and the conclusion I came too after scouring the web and reading other user's stories is that VS 2008 has a bug when debugging classic asp! It crashes when you stop debugging. Sort of a time killer to have to restart VS every time you debug.
I have had to resort to using VS2005 to open classic ASP projects and debug them there. If I need to have the ability to work on an app in both 2005 and 2008 I've found that you can have 2 separate solution files, each created by the applicable app (for example I've got appName.sln that I open in VS2008 and then appName2005.sln that I open in VS2005). You will need to create a new solution in VS2005 and add the files, then save that solution with the slightly different .sln filename. This works, it just takes a bit of time to setup.
Supposedly MS is going to resolve this issue in VS2010 but they didn't consider it an important enough problem to issue a patch for VS2008.