.NET Reflector Pro 体验
有人使用过 .NET Reflector Pro（非免费版本）吗？
我搜索了一些在外部环境（例如不在办公室的生产服务器）中轻松调试应用程序的方法，并且我发现.NET Reflector Pro 及其功能“进入反编译的程序集并使用您在自己的代码上使用的所有调试技术”。
它看起来非常有用，但我想听听使用该工具的个人经验......尤其是“每天”使用它的人的经验。
谢谢！
编辑： 一些附加信息：我想使用此功能来调试旧版本的模块化应用程序（多个版本中的 100 多个模块），以解决测试环境中未出现的难以重现的错误（例如数据组合）在数据库中，服务器/客户端的当前配置等）。
有一种方法可以重建指定的程序集（有时需要数十个程序集）...添加一些特定于问题的日志记录信息。但是，这需要很长时间，而不是轻松调试和查看局部变量、字段、线程等内容。
Does anyone have experience with .NET Reflector Pro (not the free version)?
I have searched for some way to easily debug an application in an external environment (e.g. a production server that is out of the office), and I found .NET Reflector Pro and its feature "Step into decompiled assemblies and use all the debugging techniques you would use on your own code".
It looks very useful, but I would like to hear about personal experience with the tool ... especially from people who are using it "every day".
Thanks!
EDIT:
Some additional information: I would like to use this feature for debuging the old versions of a modular application (100+ modules in several versions) for hard-to-reproduce bugs that don't show up in a testing environment (e.g. combination of data in the database, current configuration of the server/client, etc.).
There is a way to rebuild the specified assemblies (sometime there are dozens of assemblies required) ... adding some issue-specific logging information. But, it takes a long time instead of easily debugging and looking at things such as local variables, fields, threads, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
它看起来确实很酷，但我怀疑它是否经常有用。
大多数时候，错误可能出现在我自己的代码中，我有源代码、PDB 等，所以我不需要 Reflector。有了调试 Microsoft 框架代码的选项，我也不需要 Reflector Pro。因此 Reflector Pro 的用例似乎是调试第三方库。显然，这些有时会成为一些错误的根源，在这种情况下，Reflector Pro 可能物有所值。
然而，它添加的“唯一”功能是无缝调试这些的能力。您仍然可以使用普通版 Reflector 查看代码。根据我的经验，在大多数情况下这就足够了。
我承认我可能是错的，但我的直觉是免费版本对于很多用户来说已经足够了。无论如何，我并不急于为该特定功能支付 200 美元。
It does look pretty cool, but I doubt that it will be useful very often.
Most of the time the bug is probably in my own code for which I have source, PDBs and the lot, so I don't need Reflector for that. With the option to debug Microsoft framework code I don't need Reflector Pro for that either. So the use case for Reflector Pro seems to be debugging third party libraries. Obviously these will be the source of some bugs from time to time and in those cases Reflector Pro may be worth its price.
However, the "only" thing it adds is the ability to seamlessly debug these. You can still look at the code with the plain vanilla edition of Reflector. In my experience that is enough in most cases.
I admit that I could be wrong here, but my gut feeling is that the free edition will be enough for a lot of users. In any case, I am in no rush to pay $200 for that specific feature.
刚刚看到这篇文章...但我确实有使用 .NET Reflector Pro 的经验。总的来说，调试功能有时确实可以拯救你（即帮助你）。
事实上，我最近写了一篇博客帖子介绍如何使用 .NET Reflector Pro 调试 .NET Framework 源代码。这篇文章肯定会让您深入了解我自己使用该工具的经验。
http://www.cplotts.com/2011/01/14/net-reflector-pro-debugging-the-net-framework-source-code/
我还会说您可能很难找到每天使用调试功能的人。仅当我必须调试（或深入了解）非常困难的问题时才使用它，这些问题可能不在我自己的代码中，而是在 .NET Framework 或某些第三方程序集中。
有些人可能会争论，“为什么不直接使用 Visual Studio 的本机支持呢？”好吧，我愿意......如果可以的话，但并不是每个程序集都受支持。此外，有时发布的位与 Microsoft 公共符号服务器上可用的位相比已经过时了……也就是说，即使是受支持的程序集，在某些时候也不受支持。
当然，.NET Reflector Pro 还允许您调试无法访问 .pdbs 和/或源代码的第三方程序集。我的博客文章在这些情况下也会有所帮助。这篇文章是关于使用调试功能的非常通用的“如何”文章。
需要指出/强调的一件明显的事情（正如其他人已经指出的那样）是 .NET Reflector Pro 的调试功能只能在 Visual Studio 中使用。因此，Visual Studio 必须安装在您尝试调试的计算机上。大多数生产环境在这些计算机上没有（或不允许您安装）开发环境。因此，在您的特定场景中甚至可能无法使用 .NET Reflector Pro。
.NET Reflector 的免费版本只需复制到某个地方即可使其工作，因此您可以（至少）分析（但不能调试）您感兴趣的程序集。
Just ran across this post ... but I do have experience with .NET Reflector Pro. Overall, the debugging feature can really save your bacon (i.e. help you out) at times.
In fact, I recently wrote a blog post on how to debug the .NET Framework source code using .NET Reflector Pro. This post will definitely give you some insight into my own experiences with the tool.
http://www.cplotts.com/2011/01/14/net-reflector-pro-debugging-the-net-framework-source-code/
I would also say that you might be hard pressed to find someone who uses the debugging feature every day. I use it only when I have to debug (or gain some insight on) very hard problems that are likely not in my own code but in the .NET Framework or some third-party assembly.
Some might argue, "Why wouldn't you just use Visual Studio's native support?" Well, I do ... if I can, but not every assembly is supported. Also, sometimes the released bits get out of date with what's available on Microsoft's public symbol server ... that is, even the supported assemblies, aren't supported at certain times.
Of course, .NET Reflector Pro also allows you to debug third-party assemblies where you have no access to the .pdbs and/or the source code. My blog post will be helpful in these situations as well. The post is a pretty generic 'how to' post on using the debugging feature.
One obvious thing to point out/emphasize (as others have noted already), is that the debugging capabilities of .NET Reflector Pro can only be used from within Visual Studio. So, Visual Studio must be installed on the machines you are trying to debug on. Most production environments don't have (or allow you to install) a development environment on these machines. Therefore, it may not even be possible to use .NET Reflector Pro in your particular scenario.
The free version of .NET Reflector only needs to be copied somewhere in order for it to work, so you could (at least) analyze (but not debug) the assemblies you are interested in.
在您发布的链接中，写着“NET Reflector Pro 是 Visual Studio 的一个加载项，即使您没有源代码，也可以让您调试第三方代码和程序集。”
因此，您只能在开发计算机上使用它......因为我怀疑用户在生产计算机上拥有 Visual Studio。
In the link you posted, it is written this "NET Reflector Pro is an add-in to Visual Studio that lets you debug third-party code and assemblies, even if you don't have the source."
So, you can use it only on a development machine ... because I doubt the user has Visual Studio on a production machine.
我使用 .NET Reflector Pro 并大量使用“步入反编译程序集并使用您在自己的代码上使用的所有调试技术”功能。以下是几个示例：
Citrix XenServer：
我们使用 Citrix XenServer 并使用 C# Xen API 自动化许多流程。有时，从文档中并不清楚如何最好地使用 API 来执行某些功能（例如快照管理）。
Citrix XenServer 附带一个称为 XenCentre 的管理前端。 XenCentre 是一个 .NET Windows 窗体应用程序，严重依赖于 Xen API 和 SDK 工具。虽然该应用程序不是开源的，但他们并没有对其进行混淆。我使用 Reflector Pro 来单步执行他们的代码、设置断点等，以便我可以更好地理解 Xen API。
这对我来说是一个非常非常有用的工具，而且物有所值（事实上，我是在他们有报价时购买的，所以只花了我 46 欧元）。由于此功能，我节省了无数的时间，而不仅仅是使用代码的静态反汇编视图（ala vanilla .NET Reflector），或者等待他们的支持团队回答问题（他们非常优秀，但是“授人以渔”....）或在他们的论坛上。
IIS Metabase Explorer 1.6：
该工具派上用场的另一个很好的例子是 IIS6 Metabase Explorer 1.6 工具。我需要了解如何从 .NET 应用程序调用 IIS6 ABO（管理基础对象）COM API。幸运的是，这个版本的 Metabase Explorer 是一个 .NET Windows 窗体应用程序，带有围绕 ABO API 的托管互操作包装器。
使用“步入”功能，我能够了解如何使用 .NET 中的 ABO API、设置断点、检查实时变量等。这又让原本相当痛苦的事情节省了几个小时。任务（ABO API 没有完全记录或友好）。
总之，除非您确实需要去研究别人的代码并且您需要能够设置断点并在运行时查看应用程序的状态，否则基本工具可能足以满足您的需求。然而，更常见的是，我似乎发现自己需要查看应用程序或库实际上在做什么以及它的“实时”状态。暂且不讨论 RedGate 与 .NET Reflector 的最新滑稽动作的是非，从唯利是图的角度来看，它非常有用。
I use .NET Reflector Pro and use the "Step into decompiled assemblies and use all the debugging techniques you would use on your own code" feature quite heavily. Here's a couple of examples:
Citrix XenServer:
We use Citrix XenServer and automate many processes using the C# Xen API. Sometimes it's not obvious from the documents how best to use the API to perform certain functions (such as snapshot management).
Citrix XenServer comes with an administration front end called XenCentre. XenCentre is a .NET Windows Forms application that leans heavily on the Xen API and SDK tools. Whilst the application isn't open source they haven't obfuscated it. I use Reflector Pro to step into their code, set break points etc so I can understand the Xen API better.
It's a very very useful tool for me and was well worth the money (in fact I purchased mine when they had an offer running so it only cost me 46.00 euro's). I've saved countless hours because of this feature rather than just having a static disassembled view of the code (ala vanilla .NET Reflector) to work with, or waiting around to have questions answered by their support team (who are very good, but "teach a man to fish"....) or on their forums.
IIS Metabase Explorer 1.6:
Another good example of where the tool came in handy was with the IIS6 Metabase Explorer 1.6 tool. I needed to understand how to call into the IIS6 ABO (Admin Base Objects) COM API from a .NET application. As luck would have it, it turns out that this version of the Metabase Explorer is a .NET Windows Forms application with a managed interop wrapper around the ABO API.
Using the "step into" feature I was able to gain an understanding of how to use the ABO API from .NET, set break points, examine live variables etc. Again, this shaved a fair few hours off of what was becoming a fairly torturous task (the ABO API isn't exactly well documented or friendly).
In conclusion, unless you have an actual need to go poking about someone else's code AND you need to be able to set breakpoints and see the application's state at runtime, then the basic tool may be sufficient for your needs. However, more often, I seem to find myself needing to see what an application or library is actually doing and it's "live" state. Without getting into the rights and wrongs of RedGate's latest antics with .NET Reflector, from a mercenary point of view it's been damned useful.
我发现我不经常调试已编译的程序集，但是当我需要这样做时，它通常会在两天的时间内发生，我相信，如果没有它会导致日历时间加倍。
有时，Reflector Pro 可能需要一段时间才能扫描程序集以进行调试会话，但这种状态会保留下来，这很好，而且扫描会在后台进行。
我在寻找一个问题时看到了您的帖子，其中 Visual Studio 的错误窗口中显示了 Reflector Pro 反编译的程序集的错误。这些对我的应用程序开发毫无意义（并且不会阻止应用程序编译），但会给该窗口添加一些混乱。经过更多研究后，这可能最终成为另一个问题。
I find I don't debug into compiled assemblies often, but when I need to do so, it usually occurs in a two-day stretch in which, I believe, not having it would result in double the calendar time.
It can sometimes take awhile for Reflector Pro to scan the assemblies for a debug session, but this state is kept around, which is good, and the scanning occurs in the background.
I came across your post as I was hunting down an issue wherein errors show up in Visual Studio's Error Window for assemblies Reflector Pro had decompiled. These are meaningless to my application development (and don't prevent the app from compiling) but add some clutter to that window. After a bit more research, this may end up being another SO question.
在反汇编库中进行调试节省了我在某些 SharePoint SPFieldUser 中搜索奇怪行为时的麻烦。我花了几天时间研究它，如果没有能力逐步完成控件生命周期并查看哪些属性影响特定阶段的行为，我就无法确定解决该问题。真正的救星！
debugging in disassembled libraries saved my ass while searching for a weird behavior in some SharePoint SPFieldUser. I spent several days on it and I wouldn't have solved it for sure without the ability to step through the control lifecycle and see which properties affect what behaviour during specific phases. truly a lifesaver!
您可能想在 Red-Gate 关注该产品的论坛上提问：http://www.red-gate.com/messageboard/viewforum.php?f=85
You might want to ask your questions on the forum that Red-Gate watches for the product: http://www.red-gate.com/messageboard/viewforum.php?f=85