I have problem with debugging SolidWorks Enterprise PDM addin. I don't know how the addins are handled within EPDM, but the problem seems to be related with Visual Studio - maybe someone else has similar problem with other platform's addins.
Adding a debug addin (so that latest source is used):
In Visual Studio 2010 Express there's no problem - kill explorer, start it, attach to it and:
I couldn't achieve the same with Visual Studio 2012 Express. Although it seems that it is debugging explorer (files are read-only, stop debug button is shown), it doesn't hit breakpoints:
I work on Windows 7 Professional x64. Addins are built with .NET 3.5. I've used both VS2010 and VS2012 solutions with the same problem.
I do restart explorer.exe, so the latest version of addin is loaded. Project uses start action "explorer.exe":
<StartAction>Program</StartAction>
<StartProgram>$(windir)\explorer.exe</StartProgram>
<StartArguments></StartArguments>
I don't know why the breakpoints are not hit, any help much appreciated.
Thanks!
UPDATE 1
I've checked what Hans suggested - there are two other processes starting, but attaching to them didn't result in anything.
That pointed out one more thing - when I was attaching to those processes there was an information within VisualStudio, that the breakpoints will not be hit, because no debug symbols were loaded - notice that in the third image attached the debug symbols are loaded (the red circle is filled and without the exclamation mark).
UPDATE 2
When I attached VisualStudio to the managed explorer.exe - the breakpoints were hit!
It seems that explorer.exe is running in Managed mode only sometimes:
It can even be running in both modes side by side:
So the question is how to force VisualStudio starting explorer.exe in managed mode?
UPDATE 3
Is it possibly a VisualStudio 2012 bug?
When debugging with VS2010 the explorer is started in normal mode, but as soon as the addin is loaded, it is switched to managed mode and VS2010 stops at the breakpoints.
With VS2012 it is different - when the addin is loaded, explorer.exe is not switched to managed mode and (therefore? is it connected?) breakpoints are not hit.
But when VS2012 is attached to the explorer.exe that already is in managed mode, it stops at breakpoints.
UPDATE 4
I've managed to reach the essence of the problem - when attaching VS2012 to another process (e.g. explorer.exe) with "Automatically determine the type of code to debug" selected" and the process is started in native mode and some time later loads managed code - the debugger doesn't stop at the breakpoints. When the process is already in managed mode when attaching to or when attaching to with code type(s) explicitly selected ("Managed (v3.5, v3.0, v2.0)") - the debugger stops at the breakpoints.
Already posted on connect - awaiting solution. Please vote if you experience the same problem as described in this update.
UPDATE 5
I've just tested it on a simple managed shell extension so it is not SolidWorks Enterprise PDM - related.
I've also posted a more precise bug on connect.
UPDATE 6
As of the beginning of 2013 Microsoft claims that it is a design decision that the debugger is not behaving as expected. More details in the first connect bug report.
When you're building a .dll (I assume this way it's loaded into explorer) breakpoints had always problems (at least in my experience), because you have no way of knowing in advance where file will be loaded in memory, therefore it's hard to add a breakpoint.
You may try to add manual breakpoint invocation inside your code (which is int3). In C++ this would be:
asm {
int 3;
}
In C# there's a method for that:
System.Diagnostics.Debugger.Break()
Try to adding to the beginning of your function/code part (don't forget co compile in debug mode).
Then you'll just start debugging application (.exe) which loads .dll file and loaded library should trigger a break point.
Related
I am in charge of testing VS 2015 and how it works with our current applications for my employer. We currently use VS 2013 for everything we have, so I know there are no issues there. The problem I am having is that it appears the vshost.exe isn't terminating correctly or something. I have not narrowed down the exact issue but so far that is what I believe.
Here is how I get my error:
Run my app in debug
Open a few windows
Hit the "Stop Debug" button (the little red square)
Clean Solution
Rebuild Solution
After my rebuild I get the following errors in the EXE:
Error Could not copy "obj\Debug\APP.exe" to "..\..\bin\APP.exe". Exceeded retry count of 10. Failed.
Error Unable to copy file "obj\Debug\APP.exe" to "..\..\bin\CRM.exe". The process cannot access the file '..\..\bin\APP.exe' because it is being used by another process.
If I open the Task Manager and manually end the vshost.exe process I can successfully rebuild again, no issues. If I take the same steps, however, I am no longer able to build.
I tested these steps in 2013 and did not have an issue.
Also note that disabling the "Enable the Visual Studio hosting process" does alleviate the issue, however I do not want to disable this option.
Has anyone else had this issue? I know we are still early in release. Any suggestions/solutions to try? Is it possible there is something wrong in our code (which I highly doubt since I would then get the error in 2013, most likely).
Thanks for any help I receive!
EDIT: This is a WPF application written in .Net 4.0 using C#. Also, I have verified that the issue also occurs if I exit the application normally (IE I open a window then close it with the shutdown mode on LastWindowClosed)
SECOND EDIT: This is a new issue that presented itself in Visual Studio 2015 with the addition of the new live diagnostic tools.
I have found that if I have the "Enable Diagnostic Tools while debugging" option enabled in the debug settings I get this error. If I disable this option, the error goes away. I am not sure if this is a bug in Visual Studio but I would assume so, unless I need to do something else to shut them down properly. If anyone has comments or concerns, feel free to leave a note.
Probably late for the original question (and I see that he had a workaround), but as per MSDN, VSHOST.exe is only an enabler for improving Debug performance or facilitates scenarios such as partial trust debugging. If you do not need that support or can bear the cost of starting a process and attaching the debugger on each debug session, go ahead and disable the hosting process from project designer -> Debug -> Clear the box "Enable Visual Studio hosting process"
I'm working on a project in C# where the code relies on polling a web server for a report, this can take anywhere from minutes to an hour to generate and respond. I'd like to be able to run my project and see how it responds, but also continue working on other parts of the code. I don't want to do Edit&Continue, because that will pause or modify what I'm running.
I've tried running it in Release mode so I'm not debugging, but Visual Studio still complains that I cannot edit code while debugging. Any advice? Is this possible?
Thank you in advance for any help or information.
When you F5 a project, whether it's Debug or Release, Visual Studio will attach to the process, locking the file. Try running without attaching (Ctrl+F5).
A rebuild will try to overwrite your executable, which probably can't be done because it's locked while running, even without the debugger attached. This way you can't compile or debug your newer version while the older one is running.
Deploy the executable somewhere else, run it, attach to it using another instance of Visual Studio and continue editing in your first instance.
Run with Ctrl-F5 rather than F5 (or the Run button). This is "Start Without Debugging," also available from the Debug menu.
When I hover my mouse over a variable when debugging a C# app in Visual Studio nothing popups. I expect to see the value of the variable (aka datatips). I'm running Visual Studio 2012 Ultimate (trial edition) on Windows 7 64bit. Does anyone know what may prevent them from showing?
Things I've tried to no avail:
- Reinstall VS
- Search for an enable/disable setting but there doesn't seem to be one
I can see the datatips correctly with the same C# project on Windows 8/64bit with the same version of Visual Studio.
THis helped me: you need to open in VS Tools | Options | Debugger | General and enable the flag [Use Managed Compatibility Mode].
Before running the application check you are running it in Debug mode. If set to Release mode change it to Debug and then run. The debugger will then provide the data-tips.
I have found this solutions:
reinstall Visual Studio as advised here, but you have already tried it
Open your VS->Tools->Import and Export Settings Wizard->Reset all settings->No, just reset settings, overwriting my current settings-> Choose a Default Collection of Settings from MSDN Forum: Debugging - hover watch has stopped working
maybe you have Release build configuration
set Code Optimization property to Disabled under Project property windows
as advised in similar question on SO
I had this problem so I deleted all the *.suo and *.user files I could find in the solution directory and that seemed to fix it.
I had this same problem. My project had somehow gone into Release mode, so I changed it back to Debug mode via Build|Configuration Manager and it was working again, the datatips reappeared.
I realize this is an older post. But I have the exact problem in Visual Studio 2019. The funny thing is that datatips are not showing on my external screens. But if I drag Visual Studio to my laptop screen, it shows without problems. Dragging it back to one of the two external screens and it won't show.
I also have a problem that the Project Properties and Team/Source Control Explorer does not show anything but white content until I switch to another tab and then back. Then it loads. I have tried enabling GPU support in Windows, but nothing.
Has anyone had the same experience?
I will of course try all of the suggestions for the datatips thing, as that's really decreasing my effectivity.
The same happened to me but only with C#, active mode administered compatibility (Managed Compatibility Mode) and it worked well, then I wanted to modify the code while had debugged and came out a motioning message
compatibility mode administered is not supports edit and continue
Then turn it off again, under native support is (Use the legacy C# and VB expression evaluators) enable this option and you can see the value of objects and edit code debugging.
Try deleting the .vs directory and restarting visual studio.
This 3 combinations solved it for me.
- Make sure you are in Debug mode
- Uncheck/Disable Use the legacy C#,VB.NET evaluator (Tools->Options->Debugger)
- Make sure Enable Just My Code is checked.
Using remote debugging on another machine makes it more challenging.
This thread talks about RPC Server being unavailable when using "Use Managed Compatibility Mode", which makes remote debug impossible with Managed Compatibility Mode
Remote Debugging not working. "Unable to attach to process. The RPC server is not available."
Native compatibility had the same effect.
It was only "Use legacy C# and VB expression evaluators" that allowed hover over variables AND remote debugging in my case.
I deleted the project and re-cloned it from git, then it worked. None of the other solutions worked for me.
I ended up with resetting VS Settings to make this work:
Ok, I'm not exactly sure why my Visual Studio 2019 v16.8.2 was not showing the data tips popup whenever I hover over the variables when I'm debugging. FYI, I am using a project that was created on another machine with the same version of Visual Studio. I got it fixed by doing the following steps.
Load up the project and set it to release build.
Visit Tools -> Options -> Use Managed Compatibility Code, set it to enabled. Close the Options menu.
Remove any breakpoints in your code.
Run the project in Release build mode, instead of Debug mode.
Let the program run for 5 seconds and then click red square that STOPS the debugging running program.
Open up the Options again and change the 'Use Managed Compatibility Code' back to disabled(uncheck it). Close Options.
Add some breakpoints and set the run mode back to 'Debug' mode and click Play to debug the program as per normal usage.
Doing these steps in this order solved the problem for me. I'm not exactly sure which steps solve the problem but somehow in doing the preceding list of things, it's now fixed. A reinstall of VS 2019 didn't help.
UPDATE: After going back to my project and attempting to debug, it appears it's back to not working again. I tried the above steps and that only fixes the problem for the first iteration of the loop I'm working in. It appears when the code is working, then the next iteration through the loop and when it comes to my breakpoints, they are no longer showing the little popup window that allows you to inspect the variable data. So doing the above-mentioned steps only solves the problem for the first time the breakpoints are hit.
P.S. I'm using two instances of Visual Studio 2019 and am recreating one of my older apps so that it is up to date. I'm not sure if this has anything to do with the datatip's not showing up when mouse hovers over the variables or not.
I updated the package of RestSharp, and my problem solved. Packages with warning icon on it can cause this problem.
drop this into .csproj of your project (first propertygroup).
<DebugEngines>{351668CC-8477-4fbf-BFE3-5F1006E4DB1F}</DebugEngines>
It's basically as adding for your project manually that it uses compatibility managed mode, since in vs2022 this option does not exist in options.
For me, this worked on Microsoft Visual Studio Community 2017, Version 15.9.9:
If you are facing this issue simply uninstall the current version and reinstall VS. After installing and running debugging mode first time, please choose "Disable Just My code and Continue" selection,it should work.(as shown in the attached screen shot).
If you do not want to uninstall and then re-install visual studio,then try these settings on the existing VS installation:
Go to: Options => Import and Export Settings ==>Reset All Settings==>No Just reset settings,overwrite my current settings =>Finish
after this simply start debugging and choose "Disable Just My code and Continue" option.
3.If you are still having problem,please also make sure by going to project =>properties ==> Configurations that you have configurations set to debug(sometimes configurations are set to release)
Go to Tools=>options =>Debugging ==> General ==> select Suppress JIT optimization on module load
I have a c# class library that I am calling from Classic ASP.
Is it possible to debug this using visual studio? Break points in the class don't work, which isn't surprising.
I am running this on iis7 in the browser, rather than through Visual Studio 2010 because of the fact that I'm using a classic ASP page. Do I need to get this running in Visual Studio in order for this to work?
I also tried to use Response.writes, but they result in:
The name 'Response' does not exist in the current context
You need to attach the debugger to the process (either IIS or another debugger that you are using to debug your classic ASP application) that is loading the assembly.
Under VS2010 go to Tools -> Attach to Process (probably the same under 2008 as well).
try to add in the code of the lib: System.Diagnostics.Debugger.Break(); where you want to break. Also ensure the lib is compiled and deployed with the pdb symbols. When the code will reach the instruction, IIS will throw an exception. The system will ask you to attach a debugger, and you're on the way.
I actually wrote an article regarding this:
http://www.jameswiseman.com/blog/tag/visual-studio-2010/
From the article:
Open Visual Studio 2010
This is easy enough if you have it installed. Might be a bit tricky if you don’t ;-)
Open your website in Visual Studio
Again, easy enough.
Fire up your web site.
I.e. open your browser and navigate to the website.
In Visual Studio, click ‘Debug’ Menu -> ‘Attach to process’
You may need to tick the box labelled ‘Show processes from all users’
‘Inetinfo.exe‘ if application protection is low or ”dllhost.exe‘ if application protection is higher. You may get an ‘Attach Security Warning’ popup. If so, continue On. It’s a bit scary at first, but if it’s your own app on your own PC, then you’ll be ok.
If you’re worried about this, follow the advice on MSDN.
Add a breakpoint to your code, and navigate to a location where you will hit it.
Troubleshooting - Registering pdm.dll
This worked on the first occasion that I tried it. Subsequent attempts were not so successful, and I found a few things that I had to do.
When trying to attach to ‘Script Code’ I got the following warning in the IDE.
Warning: Cannot debug script code. The
correct version of pdm.dll is not
registered. Repair your Visual Studio
2010 installation, or run
‘regsvr32.exe
“%CommonProgramFiles%\Microsoft
Shared\VS7Debug\pdm.dll”‘.
Just follow these instructions.
Troubleshooting - Restart IIS
This also helped on one occasion. Can’t really say why.
You will make your life much easier all round if you wrap you .net classes in a web service then call the web service from the classic asp pages.
For debugging, attach the debugger to the process as described in other answers.
For tracing, I find very handy the combination between System.Diagnostics.Trace.Writeline() in the class library and an OutputDebugString listener like DebugView.
I've been writing a program that serves in two primary parts- managed UI and native back-end (C# and C++). However, suddenly, Visual Studio thinks that when I try to run the solution, I'm tryng to run the native back-end (a DLL) and throws an error. When I start the exe manually, it won't break on my breakpoints, and suchlike - even though I've enabled mixed debugging. How can I set it back to the original settings- mixed mode debugging and start the managed .exe when launching? I'm in Visual Studio 2010.
I think that this is probably caused because I had a blue-screen in the middle yesterday, and this is the first serious work I've done on it since.
It sounds like you just need to set the managed project as the startup project in Visual Studio.
Open Solution Explorer
Right click on the project and select "Startup Project"