Debug (or Release) folder of my Desktop application when copied to another location does not run the exe. It issues no errors, but simply hangs the system for a second or two, but returns to normal straight away, as if nothing had been run.
Does Visual Studio 2015 create dependencies in upper hierarchy of Debug as well? My installer created using Wix was not running the intended exe and i thought it was Wix's problem. But then i tested it by copying the full Debug folder in a temporary subfolder and the app was not running even from there. It can only happen when it has dependencies present in places other than the Debug folder (because system resources (dlls) are accessed from absolute path of C: drive, so they would always be available.
Could there be something wrong in your manifest file or some other settings file? Some relative path pointing to a folder in your source hierarchy? Maybe it is just an image file or some sort of settings file that is missing? Or it might be something completely different.
A I wrote in your other question, one approach for hard-to-debug dependency scenarios is to just bite the bullet and run a thorough procmon.exe session (that is a direct hotlink to the live sysinternals tool share, clicking it will start the download instantly - just so you are aware).
You can see a quick description of how to use this tool in this question: Registering a CPP dll into COM after installation using Wix Msi installer. The key is to set an include filter which will show only events you need to see - basically for your own application.exe should suffice I believe.
Many find this procmon-stuff overkill, and don't want to deal with it - but trust me, it almost always reveals something unexpected (not always useful however).
As before this answer may also be worth a quick skim (on dependencies in general): After creating MSI Installer for WPF app in Visual Studio 2017, EXE does nothing. I would at least try the Dependencies.exe tool - even if it is a bit "beta-ish". You can download from here: https://github.com/lucasg/Dependencies/releases.
And certainly double-check the modules view in Visual Studio which I describe in the linked answer (Debug => Start Debugging, then go Debug => Windows => Modules). It should show whatever was loaded to run your project interactively.
Just as the title asks. I have solution with 5 projects in it. All dlls are connected with each other and whenever I start debugging, I can freely debug any of them. I'd like to add a separated project and access it's object by using reflection only (no references between the rest and 6th proj at all). Can I make it attach automatically to the debugger? I'm aware of function 'attach to existing process' but that's manual job.
You don't need anything special. Make sure you have pdb file next to the dll for that separate project, have source code locally matching to the version used to build that project, and possibly turn off "my code only" in tools -> options -> debug. At that point Visual Studio should pick up debugging information and allow you to set breakpoints and debug normally.
If PDB located somewhere else you can manually point to the PDP via debug->window->modules view by selecting "load symbols" from context menu on module you are interested to debug.
If sources don't match exactly you can instruct VS to use whatever you have also it likely will lead to confusing debugging experience (How does Visual Studio know if the source file matches the original version?).
You can put below line in your debugging dll ,in which function you want to debuge. it automatically ask you to attach with debugger
System.Diagnostics.Debugger.Launch();
I'm working on a project that retrieves a number of Solutions from a team foundation server, to a temporary folder, uses Microsoft.Build.Execution.BuildManager.Build to build a release version for these Solutions, and cleans up the temporary folder with source code afterwards.
The problem arises when running my project with a debugger attached:
during the clean-up I get a system.UnauthorizedAccessException with message
"Access to the path ...\obj\release\CalithaLibrary.pdb denied".
Using sysinternals Process Explorer I found out that the lock was aquired by devenv.exe.
When I build a release version of my project and run it outside of visual studio the problem does not arise.
Any ideas as to why Visual Studio would aquire a lock of a PDB belonging to a project that was never opened by Visual Studio?
Edit: The first answer I received made me think I probably wasn't clear enough about the situation:
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
If I were trying to delete the AutoReleaseService.pdb from my own project, to which I did, in fact, attach the debugger, I'd understand, but the project to which the pdb file that gets locked belongs hasn't even been run on my machine, let alone debugged. I only built the project.
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
Well, CalithaLibrary looks like a DLL project, which is most certainly being used when you run AutoReleaseService.exe. It is straightforward - when the exe project is run, it uses all of the dll-s which it depends on. Visual Studio (devenv.exe) locks the .pdb files, because they are the link between the source code and the executable when you debug the application, and if you open the executable from outside of Visual Studio - they are not locked, because you do not need them then.
I'm starting to become pretty sure there's a bug in MSBuild here somewhere.
Luckily I managed to debug the last part of the application I needed to debug by excluding a few of the builds it was making, so it's now running in Release and does not encounter problems anymore.
Some information on why I think it must be a bug.
My application's workflow was something like this:
Create a temporary workspace on Team Foundation Server
GET a number of solutions/projects from TFS to a temporary folder
BUILD a number of these (configurable through xml but that's beside the point) to a different temporary folder
Clean up the temporary folder with source code
I tried setting MSBuild Options "DebugType" to none and "DebugSymbols" to false, but for some reason it kept outputting the Program Database files which is why I think there's a bug somewhere.
Whenever I skipped the "Building" step and skipped straight ahead to "Clean up" there were no locks on any files.
This is happening to me very often. When I am working in Visual Studio 2010 and say I make a code change, then build... Both my existing breakpoints become disabled / and or cannot be set and I also cannot set new breakpoints. Does anyone have a solution for this? It is very annoying. So far the only way I have been able to get around this is to restart Visual Studio which can take 5 to 8 minutes to reindex everything or to try rebuilding individual projects in my solution. My solution consists of several DLLs which make up the entire program.
Check that you have the dependencies set correctly in your projects. I know my breakpoints will become disabled if the code is "out of date". If you don't have the dependencies set up right, then when the updated code is rebuilt it will not rebuild all of the related code which will then leave those modules "out of date".
Since this is VS 2010, the dependencies are on the project not on the solution (you can add solution dependencies, but project dependencies will carry over into a new solution so it is the better way to go when possible).
This issue is caused when you having your Configuration Manager settings set to Release rather than Debug.
In Visual Studios select Build from the menu, then Configuration Manager.
In the next dialog select your project, then locate the drop down menu near the top left corner titled "Active solution configuration:" Make sure it is set to Debug.
That should fix the problem.
As it turns out the post.build file contained numerous conditions for whether or not it should copy several DLLs to a target directory... Since I didn't have time to pick through the xml for these actions I just used a bash script to copy the files after building. No need to get complicated... Otherwise, the formal solution involves setting conditions for allowing the DLLs to be overwritten/copied after compile or not.
I find the Visual Studio post.build file concept a little excessive since in the end it will make little difference whether a dll is overwritten with a freshly compiled version, yet, if you make code changes, compile, and it doesn't copy to the target directory you end up running your app with an out of date DLL and you are not testing with the recent code change..! Others have even implemented the post.build file complete with xml and goto statements...! Leave it to Microsoft to complicate the build & debug process...
Alternatively, if your code is under version control start afresh by checking out the head revision, do another clean and rebuild and start debugging again.
This for whatever reason enabled me to insert breakpoints in my VS 2010 C# project once again, whereas no amount of fannying around with properties, configurations etc got rid of my phantom breakpoint problem.
The best solution I found for this was to quit my Windows job and get another job as a Mac Developer where we use Xcode.! What a huge difference.! I sure haven't seen that breakpoints problem again.!
A C# desktop application (on the Visual Studio Express edition) worked, but then it didn't work 5 seconds later.
I tried the following:
Ensure debug configuration, debug flag, and full debug information are set on all assemblies.
Delete all bin and obj folders and all DLL files related to the project from my entire machine.
Recreate projects causing the problem from scratch.
Reboot.
I have two Windows Forms projects in the solution. One of them loads the debug information, one doesn't. They both refer to the assembly I'm trying to get debug information on in exactly the same way in the project file. Any ideas?
I want to add here, mostly for myself when I come back to review this question, that symbols are not loaded until the assembly is loaded, and the assembly is not loaded until it is needed. If the breakpoint is in a library that is only used in one function in your main assembly, the symbols will not be loaded (and it will show the breakpoint as not being hit) until that function is called.
Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All, use Debug > Windows > Modules. You'll see a list of all the assemblies that are loaded into the process. Locate the one you want to get debug info for. Right-click it and select Symbol Load Information. You'll get a dialog that lists all the directories where it looked for the .pdb file for the assembly. Verify that list against the actual .pdb location. Make sure it doesn't find an old one.
In normal projects, the assembly and its .pdb file should always have been copied by the IDE into the same folder as your .exe, i.e. the bin\Debug folder of your project. Make sure you remove one from the GAC if you've been playing with it.
Check to make sure that you are not in release but in Debug.
When in debug:
First try rebuilding your project by right mouse click the project > Rebuild
If that doesn't work, try a clean of the project (right mouse click on the project > clean)
If that didn't work check this:
Right mouse click your project
Select [Properties]
Select the [Build] tab
Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Make sure [Optimize Code] is unchecked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)
(step 7 generates the .pdb files, these are the debugging symbols)
Uncheck the "Enable Just My Code" option in the
Tools/Options/Debugging/General
Just something simple to try - you may have tried it already.
Right click the Solution in solution explorer, click "clean solution", this deletes all the compiled and temporary files associated with a solution.
Do a rebuild of the solution and try to debug again.
I've also had troubles with breakpoints multiple projects in a solution - some compiled as x86, some as x64.
The selected answer led me to fix my problem. But I need to do a few things more:
Even with "Debug" selected in the dropdown:
And in the project Properties > Build:
The Visual Studio was not loading symbols to a specific project. So in that dropdown I select "Configuration Manager" and saw that the settings to my web project was incorrect:
Then I set that to "Debug" and it started to generate the .pdb file.
BUT I need to manually copy the PDB and DLL and put in the folder that VS was looking (here is where the selected answer helped me):
Sometimes, even though it gives you this error, the Breakpoint still gets hit, so just ignore the error.
This happens fairly often in the Views of an MVC web app, i.e. .cshtml.
I was able to fix the error by simply setting the option in the 'Attach to Process' to 'Automatically determine the type of code to debug' option as shown in the attached screenshot.
Simply follow the steps below:
Go to Debug from the menu bar
Click on Attach to Process
Near the Attach to option, click on the Select button
The Select Code Type window will appear
Now select the option Automatically determine the type of code to debug and click the OK button.
Debug > Windows > Modules to see what modules were being loaded put me in the right direction.
In my case IIS Express seemed to be loading a different DLL from the temporary ASP.NET files.
The solution?
Browse to C:\Users\<YOUR USER>\AppData\Local\Temp\Temporary ASP.NET Files\vs
Delete everything in this directory!
Check if your .pbd file is missing in your bin/Debug folder. If it is then go to "Properties" of your project, selected "Build" and then "Advanced" at the bottom. Choose "full" under "Debug info" in the new window that appeared. This was my issue and solved it for me.
In my case "Optimize Code" was checked in my project properties. This caused VS to see my assembly as "not my code", and in turn, it did not load symbols for it.
The solution was to uncheck this.
Try running visual studio as an administrator within windows.
You need to enable "Generate debug info" in compiler settings
I tried everything mentioned above, but nothing worked.
[Clean solution, and check for PDB files etc.]
Even publishing the same solution did not resolve the issue.
Then I went to back to what I usually do to resolve (fool this stubborn Visual Studio)
All I did was to make a deliberate change in code and publish the solution.
Then I reverted the change and published again.
Voila [PDB files rid of evil spirits].. Not a smart resolution, but this did work.. :-|
We found the cause of our problem. This code was using the "CodeBehind" attribute in the Page directive of the .aspx file instead of the "CodeFile" attribute (ASP.NET 2.0 and beyond). After days of desperation, a simple search and replace solved the problem.
Option "Start debugging, Debug + Windows + Modules" does not exist in Microsoft Visual Studio Express 2013 edition.
Unchecking "Use Managed Compatibility Mode" in Tools Options Debugging fixes this.
Webapplications (IIS Express) only:
Rightclick IIS Express Tray and close the IIS.
Clean Solution
Clean solution and Rebuild
Check the configuration is set to Debug
Make sure that the PDB file is in the Debug folder it self
From Debug menu click Enable All Break points
Make sure you're in Debug and not is release by choosing debug in the dropdown menu like you can see in the picture below.
Then, try cleaning your project by clicking the right button in your mouse on the solution in the solution explorer window and choosing Clean solution.
Then rebuild your solution by clicking the right button in your mouse on the solution in the solution explorer window and choose Rebuild solution
Check are the following two setting the same in Visual Studio:
Right click test project, go to Properties, Build tab, and look at Platform target
Mine are all set to "Any CPU" so x64
On the Main Menu bar, go to Test, Test Settings, Default Processor Architecture
Mine was set to X86
Changing this to X64 to match above setting made the built in Visual Studio menu “Debug Test(s)” work and hit breakpoints that were previously ignored with the message “The breakpoint will not currently be hit. No symbols have been loaded for this document”.
Update:
For Visual Studio 2019 the menus have been moved around a bit:
I also had the same issue what I rebuild the whole solution (including refereced projects) in x86( or x64)
Even though I set all of my projects to x86 from Configuration Manager (Build->ConfigManager) some of my projects were not set to x86.
So Just to make sure right click on the project and follow
project -> properties -> Debug Tab, verify Configuration and Platform.
The .dll where I want to stop debugger and the associated .pdb files where copied near the .exe file. Those files had an older date so I thought they weren't updated in the runtime. I manually deleted them, Visual Studio create another pair AND put this new pair near the .exe. Now the breakpoint works!
Maybe Visual Studio cannot copy and REPLACE existing files (.dll and .pdb) near the .exe since there are another there. So if I deleted manually then VS could create new one near .exe.
I think that the root cause of the problem is that the Visual Studio use another file in runtime, no the file from the project, with the stop.
Instead of doing all these things just Close and reopen
Project Properties (then select your build config) > Build Tab > Advanced... > Debug Info (dropdown)
Set to 'all' or 'pdb-only' then rebuild
This took me a while tried other options above and for some strange reason debugging stopped working.
Tool -> Options -> Debugging -> General -> (untick) "Require source files to exactly match the original version" option
I was integrating a C# application with a static library using VS10 - which I'm new to. I wrote a managed code dll to interface them. I could set breakpoints everywhere but the static lib. I got the message described above - no symbols have been loaded for this document. I tried many of the suggestions above. I could see that the symbols weren't being loaded. I finally noticed a check box Configuration Debug, Enable unmanaged code debugging. That allowed me to set breakpoints in the static lib functions.
In my case, I was compiling a class library (DLL). No modules seem to be loaded in Debug -> Modules, so I couldn't even load the symbols manually.
My solution was to add this line to my code:
System.Diagnostics.Debugger.Launch();
Once this code is reached, an exception is triggered and .NET Framework shows a dialog box asking which Visual Studio (i.e. new instance of VS 2008, new instance of VS 2013, etc) you want to use to debug the program. You can choose the existing instance of VS with your project loaded. This will attach the process to your VS session and load all symbols, and now you can debug your project.
Of course, the compilation has to be done using the Debug configuration, not Release.
For an ASP.Net application, check the properties of the site, ASP.NET tab. Ensure that the correct ASP.NET version is selected.
I think the source if this error is, the debug symbols have a hard time surfacing to the solution after building for release.
I tried all the other answers -- generally, regenerating .pdb symbols or checking their location, cleaning and rebuilding project, ensuring active configuration is not Release etc.
What eventually worked for me is right-clicking on the project in solution explorer > Debug > Start new instance.
After trying a bunch of these, the thing that ultimately worked for me was this:
In Debug > Options > General, uncheck Enable Edit and Continue.
this happened to me after copy paste another webservice asmx file into an existing webservice, resulting in the same error when trying to debug the recently added service, to be able to debug I had to start without debug, then attach to the process. its weird but its the only way i found to be able to debug.