中国服务器网
  1. 中国服务器网
  3. In-Proc SxS在托pipe代码中打开shell扩展？
Intereting Posts
禁用统计/分析JavaScript 如何确定当前的Windows定时器分辨率？ 我如何使我的function粘性重载iostream提取操作符 通过VBScript获取图像分辨率 删除临时密钥C＃Windows 8应用程序 服务器CPU和GPU与LAMP Visual Studio从2005年升级到2015年，C ++ GUI保持XP主题不是系统主题 PHP-FPM – 上游提前closures连接，同时读取响应头 如何从batch file中调用VBA函数 Qt包装的Windows平台 在python中以微秒精度设置文件的mtime 在linux / bash中创build无限循环重复的文件猫 Windows cmdbatch file，复制源文件夹和内容 从低到中完整性提升 奇怪的行为，而负数乘以-1

In-Proc SxS在托pipe代码中打开shell扩展？

该build议曾经是“不要在托pipe代码中编写进程中的shell扩展”。

但是对于.NET Framework 4和并行进程，应该解决在托pipe代码中编写shell扩展的主要原因。

就这样说，我有三个问题。

  1. 现在可以在托pipe代码中编写shell扩展了吗？
  2. 如果在托pipe代码中编写shell扩展可能存在哪些问题？
  3. 在非托pipe代码中编写shell扩展的原因是什么？

现在可以在.NET 4托管代码中编写外壳扩展了。 你仍然应该避免在.NET 3.5或更早的版本中编写外壳扩展，因为这些早期的版本不支持并行的in-proc。

看看这个MSDN文章：使用.NET Framework 4编写Windows Shell扩展（C＃，VB.NET） – 第1部分http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows -shell延伸-与净框架-4-C-VB净部分1.aspx

  1. 好的，可以。
  2. 一个巨大的问题和时间超长的是大量的shell接口，函数，结构等，你必须在托管代码中声明。 你必须非常小心，因为即使单个参数的单个不正确的声明可能会导致爆炸，访问冲突，内存泄漏以及不需要数小时追踪的内容。
  3. 唯一的原因是如果你喜欢或被迫使用非托管语言。

查看EZNamespaceExtensions.Net ，它消除了上面的＃2以及一般开发名称空间扩展所需的时间（不管是托管的还是非托管的）。