I did this several time before, without any problem.
But somehow, this time it simply doesn't work.
Systems:
Remote PC: VPS, Guest Win2008R2 x64 dual core (hosted on VMWare Server), VS 2008 remote debug x64 Sp1, application ASP.NET 2.0, isolated in own classic app pool. All updates applied. Host (if matters): AMD Phenom quad core
Develop PC - Win7 x64, VS 2008, all updates applied
I can connect to remote PC with Attach to Process. If I stop and start the app pool while "Attach to process" is open in VS, I can see the process and (apparently) I can attach to it.
However, the breakpoint briefly get activated (red, filled) then immediately gets deactivated (red empty circle) and of course it doesn't stop the application.
I searched on google and found very few references. One suggested to copy the *.PDB in asp.net temporary files, and even if there there are lot of dirs with subdirs (one for each dll) I copied all PDB in temp folder with the dll. No success.
I'm running out of ideas. Does anyone feced similar issue? Any thoughts?
Thanks
You need pdb files for the same. Copy the actual pdb files of the dll from the development project. It will be inside the bin/debug/ directory of your original project (source code one not the deployed). Then copy the pdb file to remote directory where the dlls resides and then attach the debugger. Also for that , you need Remote Debugger.
Related
I have recently deployed my ASP.NET Core application to my IIS8 server. However due to some issues, I have to remotely debug it.
I installed the Remote Debugger and managed to connect to the server and Attach a process.
However, I am unsure of what to attach from there. I have tried attaching all dotnet.exe and w3wp.exe processes but each time I do that, my breakpoint turns white and says that it won't hit.
I took a look at my Modules tab and for some reason, my symbols aren't loaded for my application dlls. I have made sure that the configuration is Debug and that the ASPNETCORE_ENVIRONMENT is Development.
Currently this is what I am doing:
Run the Remote debugger on the IIS server
Run the website on my local laptop
Attach a process in Visual Studio
I have an ASP.NET project managed in the VS 2010 IDE. I constantly copy it from one development machine to another. By its nature this ASP.NET project must run on an actual IIS. One development machine has a local IIS configured but I couldn't set it up on a second machine. The project is set up to Use local IIS in its properties. The issue happens when I try to copy this project from a machine with the local IIS to the one that does not have it. When I load it up in VS 2010 the only thing I get in the "Solution Explorer" is <SolutionName> (Unavailable) and I can't do anything, even open up its properties. The only way to fix this is to go back to the first machine and set up this project to Use Visual Studio Development Server and then copy it.
Is there any way to do this on the destination machine without this route of going back to the first computer?
We have a Windows Server 2008 R2 box setup as a Terminal Server with Visual Studio 2012 installed on it for remote developers to be able to do development on our ASP.net systems.
We would like to be able to do debugging on out projects the same way we do when developing on our local machines using visual studios internal development server.
I am trying to start local debugging on an ASP.Net project (F5) in VS2012 - the project compiles - IE comes up with my localhost url and then it just spins with "connecting..." and the page never comes up.
Pulling up the same workspace on a local machine and debugging comes up just fine.
I've exhausted my google-fu on looking for solutions here and humbly ask you all for any insight.
Visual Studio works a little differently when you are debugging on a server. You don't really want to use VStudio to play/debug on a web server. You need to use the menu option "Debug", "Attach to process". There will be several processes running, so it might take a few tries to find the right process.
Be careful though. Because your break-points will actually freeze IIS for the entire server. It could be a pretty big inconvenience for everyone who is using IIS at the time.
If you are trying to debug the project from your IIS server, you need to verify if the account has Administrator rights, also if the project has been deployed with its source files, you can attach the process (maybe it is w3wp.exe) in Visual Studio and debug it.
Another way is to open the solution using Visual Studio and change in the web project's property the server: Use Visual Studio Development Server.
Let me know more info about your scenario to provide you more paths.
What I would do is attach to the IIS process on the server: http://msdn.microsoft.com/en-us/library/vstudio/3s68z0b3.aspx you can even do this off your machine.
make sure debug is enabled in web.config for that app and you've mounted the remote project. Add a break point, debug by attaching to the IIS app pool process & it'll trigger the break point.
I was able to Attach Process to the SPUCWorkerProcess.exe even though it's a farm solution and not a sandbox solution
This is more a 'why does this work this way' than a 'how do I make this work' sort of question.
I have a WCF web service I am debugging remotely. It is deployed to a staging server where the VS 2010 remote debugger is installed and running as a Windows service. The permissions are correct, I can attach to processes without any problem. The issue I ran into is I couldn't consistently get the symbols to load.
I have the WCF service deployed to C:\Webs\MyService, with assorted DLLs in C:\Webs\MyService\bin. It is set up as a separate site with its own app pool. What I found is even if I had the necessary .pdb file in the bin folder, Visual Studio wouldn't load any symbols when I attached to the w3wp.exe process from my local machine. What was happening is when IIS started and the worker process was spawned, my service DLL would get copied deep under the temp ASP.NET files directory, into something like C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\19f82539\e55fff8f\assembly\dl3\2926a261\f625d158_f62ecd01. I found that if I manually copied the .pdb file to this folder, then symbols would be loaded and I could do the debugging.
I'm wondering why the heck it works that way, and how I can avoid having to manually copy the symbol file to this other directory. What's worse is if I had to make changes and redeploy, the worker process wouldn't recognize them. I had to restart IIS which caused a different temp directory to be created, requiring me to copy the .pdb again.
I have a similar problem, with web applications. Apparently Microsoft are aware of this: http://go4answers.webhost4life.com/Example/remote-debugging-symbols-not-loaded-207525.aspx
Hopefully, they will release a fix soon.
There is also a suggestion by BrianR on a related question, Why are no Symbols loaded when remote debugging?, saying to create a folder with the debug files and on the remote server to point the environment variable _NT_SYMBOL_PATH to it.
I have sit up remote debugging on a Window 2003 server accessed through the Internet. I have VS 2008 SP1 installed on my XP dev box.
I launched the site on the remote server and attached to all the w3wp.exe processes on the remote server. I noticed that the .dll did not load the symbols file. When I try to load the corresponding .pdb file from my local machine, it says file does not match. I have "Require source files to exactly match the original version" unchecked. The assembly on the remote server is the same as the one on my dev box. The site and .dll was copied from dev boc to remote server and code hasn't changed since. So I know .dll and .pdb files should match or at least I need to force the matching.
Questions:
How do I get the .pdb file to load? I know breakpoints won't trigger unless symbols file is loaded. I noticed that the .pdb file does not exist in the "Temporary ASP.NET Files" folder on the remote server. The .dll does.
What's the proper sequence to start debugging remotely inside VS? (Remote set up is done and I can see remote processes).
In VS, I have start page as the url of the remote site. I start without debugging and then attach to w3wp.exe(s) on the remote. Is this all?
Are you running a Web Site or a Web Application (is it a compiled project, that you deploy the DLL for, or a collection of aspx and aspx.cs files that you deploy)?
If it's a Web Application, did you deploy a release build, or a debug build? You won't be able to hit breakpoints when "debugging" a release build, as the code is fairly heavily optimised.
Have you got "debug=true" set in the web.config compilation section? If not, again, debugging is going to be difficult.
Finally, the steps I use when remote debugging are:
Deploy latest debug build of files
Request page on remote server to start/restart application
Ensure that the VS Remote Debugging Monitor is up and running on the remote server
In VS, go to Tools (or Debug) | Attach to Process..., ensure that the remote server is selected in the Qualifier, and select w3wp.exe for the correct app-pool, etc.
Request page that will fire break point.
Debug!
If the breakpoints are hollow (thin red circles rather than filled disks), I'll often check the Stack window in VS to see what has and hasn't been loaded.