如何扩展 Windows 资源管理器单击的行为或扩展 Shell 行为
有什么方法可以扩展或修改 Windows 资源管理器单击的行为吗？
比如我想修改点击事件。单击驱动器后，我应该能够连接到 FTP 服务器，而不是打开驱动器。该驱动器将是已安装的驱动器。
所以我想做的是修改Windows资源管理器单击的默认行为或扩展Shell的行为（我不确定这是否属于shell扩展）。
Is there any way I can extend or modify the behavior of Windows Explorer click?
For example, I want to modify the the click event. On clicking a drive, I should be able to connect to an FTP server instead of opening the drive. The drive will be a mounted drive.
So what I want to do is modify the default behavior of Windows Explorer Click or Extending the Behaviour of Shell (I'm not sure if this belongs to shell extension).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，这远远超出了“点击”的范围。您必须编写一个外壳扩展。由于 CLR 版本注入问题，在 .NET 4.0 之前，在 C# 中执行此操作是完全不受限制的。非托管程序（例如记事本）在使用 shell 对话框（例如FolderBrowser 或 OpenFileDialog）时会注入 CLR。这可能会导致后续代码失败，需要另一个版本的 CLR。这已经解决了，CLR 4.0 支持多个 CLR 版本在内存中并行操作。
没有解决的是您需要编写的代码的复杂性。 Shell 扩展需要 COM 代码。硬接口，源自 IUnknown。为了开始，您需要为 COM 接口编写大量声明。您无法从 SDK 声明中获取它们，它们只能由 C++ 程序使用。而且它很容易出错，C# 不支持多重继承，而您需要声明从其他接口派生的 COM 接口的功能。
最后但并非最不重要的一点是，调试此类代码是一场噩梦。这是您正在修改的一个重要的 Windows 进程。犯一个错误会给你带来一个无法使用的外壳。重新启动会启动相同的 borked shell。
嗯，需要黑带技能。我认为 .NET 4.0 的可用性应该会启动一些提供友好的托管包装器的项目。我只是还没有看到。也以此为标志。
Hmya, this is quite a bit beyond "click". You'd have to write a shell extension. Doing this in C# was quite off limits until .NET 4.0 because of the CLR version injection problem. Unmanaged programs (say, Notepad) would get the CLR injected in them when they use a shell dialog, like FolderBrowser or OpenFileDialog. Which could cause subsequent code to fail that requires another version of the CLR. That's solved, CLR 4.0 supports in-memory side-by-side operation of multiple CLR versions.
What isn't solved is the complexity of the code you'd need to write. Shell extensions require COM code. The hard kind, interfaces that derive from IUnknown. To even get started, you need to write masses of declarations for the COM interfaces. You can't get them out of the SDK declarations, they are only usable by a C++ program. And it is very error prone, C# doesn't support multiple inheritance, the feature you'd need to declare COM interfaces that are derived from other interfaces.
Last but not least, debugging this kind of code is a nightmare. This is an essential Windows process you're tinkering with. Making a mistake leaves you with an unusable shell. Rebooting starts that same borked shell.
Well, black-belt skills required. I imagined that the availability of .NET 4.0 should have jump-started some projects that provide friendly managed wrappers. I just haven't seen any yet. Take that as a sign as well.