I am using Visual Studio 2013. I use a single start up project. There are more than 8 projects in the solution. Here is what I used to do when I was on Visual Studio 2010;
I would Build the solution. Then run it from its .exe file in /bin/Debug, then on Visual Studio, I would Attach to Process and it would start debugging and it would always hit the breakpoints as long as the source code and the .exe are not different.
This is the same thing that I do on Visual Studio 2013. I put the breakpoints in a file in my startup project. I build the solution (it says it successfully builded on the output window), or I Start Without Debugging, then attach to process, it says "The breakpoint will not currently be hit. The source code is different from the original version" Then I stop debugging, and without building again, I run the .exe again, attach it, then the breakpoints start hitting. Why do I have to close my .exe and then start it again? I use attach to process a lot and this 'must do twice to hit' is really annoying. I haven't change any configuration or anything. What am I doing wrong? I swear I don't change the source code. Not even a single space. It says "Build succeeded" when I attach it.
I have a similar issue. (on a webproject)
my temp solution:
right click the web project
Select Property Pages
Under Build --> Change the Target Framework to something else than the one selected (Apply the new framework)
Then Change back to your desired framework and Debug
Related
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
I am trying to launch the Console.Tests part of https://github.com/ServiceStack/ServiceStack.Redis in Debug mode (by pressing F5), so that I can place a breakpoint in it.
Visual Studio (2013), however, refuses to do so, claiming that my project is of DLL type:
Why? What am I missing?
BTW, building this project produces Console.Tests.exe in Visual Studio 2013\Projects\ServiceStack.Redis-master\tests\Console.Tests\bin\Debug which runs just fine.
Also, if I attempt to debug the project by right-clicking its menu, it also starts just fine:
Why? What am I missing?
You need to tell Visual Studio which StartUp project it should run by right clicking on Console.Tests project in solution explorer and selecting Set as Startup Project.
Want to debug an executable under debugger. How to do it in visual studio.
Windbg has an option of open executable. But I find this is missing in VS 2010.
The question is not exactly same as
Debug exe in visual studio 2010
as I am not really interested in image file execution to debug a start up.
Rather want to just debug the exe under debugger, once it is broken, want to
set some break points and understand the flow of execution.
Albeit image file execution is a workaround for this.
I am not sure if this question is naive; But this is a very straight line use case scenario, I find missing in MS VS 2010.
You did not specify it in the question, but I assume you do not have the source code. Just use File/Open Project/Solution, select EXE file and Open it. Then select Debug/Start debugging. The other option is to run the EXE first and then Select Debug/Attach to process.
If what your asking is how do you attach VS to the exe you want to run then you can follow these steps:
Run the executable
In VS navigate to Debug -> Attached to Process
Find your process created by running your executable and click "attach".
However, if the executable you are trying to run fails almost immediately or runs quickly and exits then you could try the following steps:
Set a debug point at the start of the code
Switch your build to Debug and run the application.
If your application is running in Debug, but failing when you execute the exe then you could try these steps to see if the your app will give more information in a console window or other.
Make sure your build is set to Release.
Navigate to Debug -> Start Without Debugging
If you have the source code, you can use Debugger.Launch();
You put it anywhere in your code, build the .exe and then once it gets launched (by Process.Start for example) and reaches Debugger.Launch();, a window will be asking you how you want to attach to the process.
Typically, you'll attach to some Visual Studio instance and it'll automatically pause the debugger where Debugger.Launch(); has been placed.
You can then open the project's files (File -> Open -> File...) and place breakpoints wherever you want.
I have an issue with Visual Studio 2010 and an ASP.NET 2.0 project.
I have searched StackOverflow for a possible solution to my problem, but even though there are alot of articles related to the Visual Studio debugger, none specifically solve my issue.
Every time I start debugging, Visual Studio tells me that "The breakpoint will currently not be hit. The source code is different from the original version.". In the past when I got this problem, I could solve it by doing a Clean Solution. Or if that didn't work, I could always restart Visual Studio or my machine and the problem would be gone. This, however, doesn't work anymore. The solution cleans and I can rebuild, but the debugger still complains about the source.
I found that if I delete the folder "root" in "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files", the problem is temporarily gone but only the next time I start the debugger, and only for the breakpoints that are currently set in the project. All breakpoints I add when the debugger is running are also not being hit due to the source/original difference.
I don't know how to solve this issue permanently because I don't want to delete that folder every time I have to start a debug session.
I also have a few ASP.NET 4.0 projects that debug just fine.
I use Windows 7 Enterprise (x64).
If someone has a suggestion I would very much appreciate it :)
Try this
Right click solution.
Click "Property"
Go to: "Common Properties" -> "Project Dependency"
Select your "project" from drop down list
Check every item in list of "Depends on"
Click "OK"
Now Open "Task Manager"
And kill all worker process i.e. "w3wp" in case of iis7
Or Kill all "WebDev.WebServer40.exe" process
Now run your application.
Firstly I'm completely aware of this message and why it happens normally. It's not that I'm just trying to run a dll (like this question).
I have a project that compiles to a dll but has a startup program specified in the project properties. Most of the time I'm able to right-click on the project and select Debug > Start new instance, and it will run the program and let me debug my dll. However, occasionally I get this message (A project with output type of class library cannot be started directly) as if I haven't got a startup program. The first few times I thought it was just me accidentally clicking on the wrong project but I'm certain this isn't the case given that it's happened so many times and I've been careful to watch it.
When this message appears I'm able to try it again and it always works on the second or third attempt.
A colleague using the same Solution never has this problem :-/
Anyone else had this problem or know how to solve it?
I'm using Visual Studio 2005 Pro Version 8.0.50727.762 (SP.050727-7600)
Edit: Also happens with Visual Studio 2010
Another colleague suggested it's because after clicking Debug > Start new instance, while I'm waiting for it to start up, I click on a different project. I don't do it for any reason, just randomly selecting things as I wait for the project to start up. Maybe Visual Studio looks at the selected project sometime after I clicked the menu, gets confused, and shows the error message?
Anyone able to confirm this matches their experience?
Typically problems in VS are caused by:
Add-ins: Run VS without and see if the problems is solved
Corrupted files in your solution: Delete / rename all files created by Visual Studio which are not part of your project, i.e. all .suo, .ncb files and a like.
I had this problem with projects that were created as "Windows Control Library" that somehow forget their status. Unloading and reloading the project usually did the trick.
If it was created as a "Class Library" then to make it a "Windows Control Library" I manually add the following to the .csproj file. It was the only difference I could see between a class library and windows control library project.
BTW - starting a Windows Control Library starts the User Control Test Container - allows you to test any user control in the library. Very cool.
<Service Include="{94E38DFF-614B-4cbd-B67C-F211BB35CE8B}" />
add that inside of an <itemgroup> element.
If you plan to use/create/add extra dll's or just have more than one project in your solution, you may get this kind of problem, especially if you forgot a simple rule:
1. In your "Solution Explorer" window. Right click and chose "Set StartUp Projects..."
2. Under "Start Up Project" select and change "Single startup project" to your working entity.
no just make a start up project
Going to resurrect this thread, I have just been experiencing similar issues, when right clicking a project and start new instance..
So instead of right clicking the project and selecting start new instance, I right clicked and clicked set as startup project.
Low and behold a class library project was set to bold, certainly not the one I was right clicking.
I tried selecting a different executable project and setting that as the startup project. Same class library was highlighted as the start up project.
Realised that the current open file was from that project, possibly all the open files were from that project...
closed all open files and tried again.... Problem solved, behaviour as expected for both set as start up project and start new instance options...
Definitely a bug, hope this helps others..
Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework Version 4.0.30319 SP1Rel
This sounds like a transient Visual Studio problem. Reinstallation or upgrade may solve your problem.
I've seen this as well, and it seems like a bug in VS. It happens after you right-click/build a class library (that requires rebuilding), and then right-click/debug > start new instance.
edit- It's still very intermittent, I can't seem reproduce it reliably
I've found that I've had the Startup Project on the Solution set to Current selection, then at some point, I've unloaded a project, and the solution has reverted to Single startup project on a project that happens to be a class library.