从 VS2010 调试在远程 IIS 服务器上运行的 ASP.NET 应用程序

发布于 2024-10-01 21:32:47 字数 339 浏览 1 评论 0原文

只是想知道是否有人可以在这里为我指明正确的方向?

我正在尝试调试部署的 Web 应用程序,但似乎无法使附件正常工作。 这是场景:

VS2010 安装在我的机器上 - 包含所有源代码。

我的计算机上的 IE8 浏览到生产 IIS 服务器上的 ASP.NET 站点(生产站点上的 FWIW .pdb 文件。)

当我将调试器附加到 IE 会话并继续浏览该站点时,不会遇到断点...所以有效我不认为我真的在调试该网站!?

我猜我需要某种远程调试设置?如果是这样的话,如果有人知道任何可以提供帮助的 URL,我们将不胜感激!

提前致谢!

吉姆

Just wondered if anyone could point me in the right direction here?

I'm trying to debug a deployed web application and can't seem to get the attach to work.
Here's the scenario:

VS2010 installed on my machine - with all source code.

IE8 on my machine browsing to ASP.NET site on production IIS server (FWIW .pdb files on production site.)

When I attach the debugger to the IE session, and continue browsing the site, no breakpoint is ever hit... so effectivly I don't think I'm really debugging the site!??

I'm guessing that I need some kind of remote debugging set up? If that's the case, if anyone knows of any URL to help that would be much appreciated!

Thanks in advance!

Jim

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

孤独患者 2024-10-08 21:32:47

这是完整的分步指南,因为有大量分散的信息,并且链接的 Microsoft 文章假定了大量信息。

首先,让我们澄清一下本指南其余部分中使用的术语:

diagram

客户端 是计算机你做的开发
远程是已部署代码并在 IIS 上运行的计算机

  1. 安装 msvsmon.exe (Microsoft 远程计算机上的 VisualStudio Monitor)。
    您可以在客户端上的以下路径找到随 Visual Studio 安装的可执行文件:

    VS 2010:C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86 
    VS 2017:C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\X64

    当该工具启动并运行时,您应该看到以下应用程序:

    新服务器

    调试监视器已创建您可以远程连接的服务器。如果您使用的是 Windows 计算机,则名称可能是 User@Remote。请记住这个名称,因为稍后您会需要它。如果想直接复制,可以进入“工具”>“复制”。选项,您将看到服务器名称。如果您愿意,您甚至可以将其更改为其他内容。

  2. 从这里您可以尝试霰弹枪方法,看看是否一切正常,但根据您的网络配置,可能会出现一些额外的问题。要尝试远程调试,请在 Visual Studio 中打开项目。这应该与部署在 IIS 上的项目完全相同。

    在 Visual Studio 中,您需要附加到新服务器上的进程。转到工具>附加到进程或点击 Ctrl + Alt + P

    attach to process

  3. 在“附加到进程”对话框中,将限定符从当前计算机名称更改为新服务器名称 (User@Remote)然后按 Enter 键查看远程计算机上可用进程的列表:

    附加对话框

  4. 如果一切立即恢复,那么您就得到了很好的照顾。这意味着没有防火墙策略阻止您连接远程服务器,您可以跳到步骤 6。

    或者,如果您收到以下消息,则意味着您的防火墙正在阻止客户端和远程设备进行通信。

    无法连接到名为“User@Remote”的 Microsoft Visual Studio 远程调试监视器。目标计算机无法连接回此计算机。防火墙可能阻止通过 DCOM 与本地计算机进行通信。

  5. 如果您无法连接,则可能存在一系列问题,具体取决于您的域策略。 。对于官方防火墙设置,您可以查看 Microsoft 的 配置Windows 7防火墙进行远程调试,但我发现它缺乏细节。

    如果附加失败,但您仍然会收到用户已连接的消息,如下所示:

    已连接

    那么说明问题不在于客户端的出站规则,也不在于远程服务器的入站规则。问题更有可能出在客户端计算机上的入站规则。

    要解决此问题,请在客户端计算机上转至“控制面板”>“ Windows 防火墙 >高级设置应打开具有高级安全性的 Windows 防火墙。选择入站规则并右键单击以输入新规则

    新规则

    为规则指定任意名称。根据这个SO问题中的建议,我们将允许所有流量通过任何视觉对象,而不是豁免特定端口工作室可执行文件。转到“程序和服务”并选择 Visual Studio 2010 安装的完整文件夹路径:
    %ProgramFiles% (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

    然后确保该规则仅适用于域内的计算机(确保未选中私有和公共)。

    Visual Studio 规则

    如果运气好的话,当您返回附加进程时,您应该能够进入远程计算机。

  6. 此时,您应该看到远程计算机上所有进程的列表。如果您想调试 Windows 应用程序,只需选择进程的名称即可。对于 ASP.NET,我们想要附加到 w3wp.exe(WWW Worker P进程)。如果您在列表中没有看到它,请尝试通过打开要调试的应用程序的网页来启动服务器。您可以在本地主机上执行此操作,也可以通过从任何计算机导航到 IIS 中的地址来执行此操作。

    附加对话框已连接

    确保为您的应用程序附加正确类型的代码。您可以在本机(C++ 等)或托管(VB、C# 等)之间进行选择,或者选择自动并让 Visual Studio 决定。

  7. 如果出现以下错误,我发现使用管理员权限重新打开 Visual Studio 和 msvsmon.exe 可以解决该问题

    无法附加到该进程。Visual Studio 远程调试器 (MSVSMON.EXE) 没有足够的权限来调试此进程。要调试此进程,请使用“以管理员身份运行”启动远程调试器。如果远程调试器已配置为作为服务运行,请确保它在属于管理员组成员的帐户下运行。

  8. 您将看到一条安全警告,您可以通过单击附加来接受该警告:

    security warning

  9. 我遇到的最后一个问题是加载调试器文件。您需要确保正在执行的库与当前在 Visual Studio 中加载的库完全匹配,并且它们在客户端计算机上的解决方案中具有正确的 .pdb 文件。您可以通过转到“调试”>“检查加载了哪些模块以及它们从何处加载”来检查。窗口>模块或按 Ctrl + Alt + U
    有关加载调试器文件的更多信息,您还可以尝试以下任何资源:

希望此时它已正常运行。现在,您可以捕获对 IIS 托管代码进行的任何调用,并像在开发期间一样逐步执行它们。

概念证明

进一步阅读

Here's a full step-by-step guide because there is a lot of scattered information and the linked Microsoft article assumes a lot of information.

First let's clarify the terms used throughout the rest of the guide:

diagram

Client is the computer on which you do development
Remote is the computer the code has been deployed to that is running on IIS

  1. Install msvsmon.exe (Microsoft VisualStudio Monitor) on the Remote computer.
    You can find the executable installed with Visual Studio on your Client at the following path:

    VS 2010: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86 
    VS 2017: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\X64

    When the tool is up and running, you should see the following application:

    new server

    The Debugging Monitor has created a server that you can connect to remotely. If you're on a Windows machine, the the name is probably User@Remote. Remember this name, because you'll need it later. If you want to copy it directly, you can go to Tools > Options and you'll see the server name. You can even change it to something else if you like.

  2. From here you can try the shotgun approach and see if everything works, but depending on your network configuration, there might be some additional hiccups. To attempt to debug remotely, open the project up in Visual Studio. This should be the same exact project that is deployed on IIS.

    In Visual Studio, you'll want to attach to the process on the new server. Go to Tools > Attach to Process or hit Ctrl + Alt + P

    attach to process

  3. In the Attach to Process dialog, change the Qualifier from your current computer's name to the new server name (User@Remote) and hit enter to see a list of the available processes on the remote computer:

    attach dialog

  4. If everything comes back right away, you're in good hands. It means there were no firewall policies preventing you from connecting with the remote server, and you can skip to Step 6.

    Alternatively, if you got the following message, it means your firewall is blocking the client and remote boxes from communicating.

    Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'User@Remote'.  The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer. Please see Help for assistance.

  5. If you weren't able to connect, there could be range of problems depending on your domain policies. For the official firewall setups, you can check out Microsoft's Configure the Windows 7 Firewall for Remote Debugging, but I found it to be lacking in detail.

    If attaching failed, but you still get a message that the user connected like this:

    connected

    Then it means that the problem is not with the outbound rules on the client or the inbound rules on the remote server. It's much more likely the issue is with the inbound rules on the client machine.

    To fix this, on the Client computer, go to Control Panel > Windows Firewall > Advanced Settings which should open up Windows Firewall with Advanced Security. Select Inbound Rules and right click to enter a New Rule:

    new rule

    Give the rule any name. Based off advice in this SO question, instead of exempting particular ports, we'll allow all traffic to go through for any Visual Studio executable. Go to Programs and Services and select the full folder path to the 2010 install of visual studio:
    %ProgramFiles% (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

    Then make sure that the rule only applies to computers within the domain (making sure private and public are unchecked).

    visual studio rule

    With any luck, when you go back to attach the process, you should be able to get into the remote machine.

  6. At this point, you should see a list of all the processes on the remote machine. If you wanted to debug a windows application, you'd just pick the name of the process. For ASP.NET, we want to attach to the w3wp.exe (WWW Worker Process). If you don't see it in the list, try kicking off the server by opening up the webpage of the application you'd like to debug. You can do this on localhost or by navigating to the address in IIS from any computer.

    attach dialog connected

    Make sure to attach to the right type of code for your application. You can select between native (C++, etc.) or Managed (VB, C#, etc), or select automatic and let Visual Studio decide.

  7. If you get the following error, I found that reopening Visual Studio and msvsmon.exe with Admin privileges fixed the issue

    Unable to attach to the process. The Visual Studio Remote Debugger (MSVSMON.EXE) has insufficient privileges to debug this process. To debug this process, launch the remote debugger using 'Run as administrator'. If the remote debugger has been configured to run as a service, ensure that it is running under an account that is a member of the Administrators group.

  8. You'll see a security warning that you can accept by clicking Attach:

    security warning

  9. The last issue I ran into was the getting the Debugger Files to load. You need to make sure that the libraries that are being executed exactly match the ones that are currently loaded in visual studio and that they have the correct .pdb files in the solution on the client machine. You can inspect which modules were loaded and where they loaded from by going to Debug > Windows > Modules or hitting Ctrl + Alt + U.
    For more on loading debugger files, you can also try any of the following resources:

Hopefully it's up and working for you at this point. Now you can catch any calls made into your IIS hosted code and step through them same as you would during development.

Proof of Concept

Further Reading:

画尸师 2024-10-08 21:32:47

这是一篇很好的文章:

http://msdn.microsoft.com/ en-us/library/bt727f1t.aspx

在远程计算机上安装远程调试组件,并在开始调试时启动远程调试监视器 (msvsmon.exe)

Here's a good article to do just that:

http://msdn.microsoft.com/en-us/library/bt727f1t.aspx

Install the remote debugging components on the remote computer and launch the Remote Debugging Monitor (msvsmon.exe) when you start debugging

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文