I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.
Related
I'm using VS 2015 Update 2 with an asp.net 5 web project configured for debug mode. When I run the project with F5 to debug it and hit a break point, some variables can not be observed in the watch window even when they are in scope. Further, if I hover over such variables no value is displayed.
If I use the same visual studio to create an empty web project and add a webform and place the code in the load method, the debugger works fine. That is to say, I can see the variables in the watch window and I can see their values by hovering over them. I glean from this that the root cause of the issue is not VS2015 Update 2 but rather something to do with the project or solution configuration, perhaps specific to asp.net 5 web projects.
I've scoured the web for answers and similar problems happen when trying to debug compiler optimized code. But I am running the solution in debug mode. Any suggestions?
I am aware of Variable does not exist in the current context while debugging but it applies to a different version of visual studio and the solutions offered there do not fix my issue.
I had the same problem. Eventually I noticed that some settings are different after update 2.
You need to go to Tools --> Options --> Debugging --> General and then check "Use Managed Compatibility Mode".
That worked for me.
This is a bug that was introduced in Visual Studio 2015 Update 2. Essentially the debugger is unable to inspect local variables in dynamic modules. We released a hotfix for it today. You can download the patch here. Documentation for the patch is here. Let me know if the patch does not fix your particular scenario.
Thanks!
-Patrick Nelson
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 using the latest NUnit, 2.5.9, on Windows 7 64-bit, Visual Studio 2010 Premium, and the projects are .Net 3.5.
The problem is that I attach to NUnit (there is NOT an nunit-agent appearing), and symbols are loading, but my break points aren't being hit. There is no error indicator next to the breakpoint indicating something is wrong.
The first run seems to take some time to start the test, but subsequent runs after that seem to complete almost instantly. I assume because StructureMap (required for the objects i'm testing) has already done its thing and doesn't need to repeat that setup.
Any ideas on how to fix this?
I sort of figured out the answer. I reset all of my settings to the standard Visual C# Development Settings and debugging suddenly works again.
I'm not sure which setting got everything back on the right track; I didn't see a "disable debugging while debugging setting."
I have a command line app that uses a certain assembly. The assembly is sitting in the root of the project, and set to "Copy Always."
I add a reference to that assembly, and Visual Studio 2010 is happy -- Intellisense highlights everything correctly, and no errors are reported.
But as soon as I actually build, I get compilation errors like I haven't added the reference, and Intellisense suddenly gives me red squigglies as if the reference was never added.
But the reference is still there.
If I delete the reference and then re-add it, Visual Studio gets happy again, and the red squigglies go away. Then I build, and the same thing happens again.
So, Visual Studio agrees that the reference is there. Until I build. Then it claims its not. Even though it is.
And this only happens with a specific DLL (NLog, if it matters). Another DLL (HtmlAgilityPack) works fine, and it's set up and configured the exact same way.
With a little search I found a problem with the .NET client profile. Try looking at that link and see if it resolves the issue.
There's also some posts on it at the microsoft connect website if you're interested in further reading.
I’m using visual studio 2008 and moles version 0.93. Everything works well except when I try to debug any test that uses a Moled type. The test skips all my breakpoints. And I get the following message in the output window:
Unable to attach. Check for one of the following.
The application you are trying to debug uses a version of the Microsoft .NET Framework that is not supported by the debugger.
The debugger has made an incorrect assumption about the Microsoft .NET Framework version your application is going to use.
The Microsoft .NET Framework version specified by you for debugging is incorrect
Please see the Visual Studio .NET debugger documentation for correctly specifying the Microsoft .NET Framework version your application is going to use for debugging.
If I try debbuger.Break () I get a message: "No symbols are loaded for any call stack frame. The source code cannot be displayed."
I’m in a crunch right now chasing an issue with one our main components and it has been a pain (like I need novocaine) trying to figure anything out without being able to step through the code.
I want to take advantage of mole's "smooth debugging experience". However, I can't seem to get the debugger to attach at all.
Thanks,
Bzz
See the solution to this issue here:
http://social.msdn.microsoft.com/Forums/en/pex/thread/91c08bf4-3260-458c-a221-91f030a75499
I had this problem when I moved a project from Visual Studio 2010 to Visual Studio 2008. Here's what I did to fix it.
Close Visual Studio. Navigate to the Debug/bin location. Delete the following files:
*.vshost.exe
*.vshost.exe.config
*.vshost.exe.manifest
Open the solution. Goto the project Settings. Under the Application Target Framework, select a framework lower than the one you are working with (you'll set it back later). Visual Studio will close and re-open your project automatically. Then set the Target Framework back to the original version you were working with. Rebuild all, and debugging will work properly.