我应该为 PowerShell Cmdlet 实现 IPropertyCmdletProvider 接口吗？
我正在编写 用于 PowerShell 的 NavigationCmdletProvider。通过 GetItem 和 GetChildItems 覆盖，有多种类型的对象被写入管道。
IPropertyCmdletProvider< 的文档/a> 接口告诉我们以下内容：
开发者应该实现这个 界面如下 条件：
- 当用户必须使用 Get-Property 和 Set-Property 等 cmdlet 时 cmdlet。
- 对于派生自 ItemCmdletProvider 的提供程序， ContainerCmdletProvider，或 NavigationCmdletProvider 类。
困惑：
我认为没有太多有用的信息，因为用户如何知道他们是否必须使用 Get-Property 和 Set-Property cmdlet？我想这取决于 Cmdlet 作者。最大的困惑（至少对我来说）是 Cmdlet 是否将对象写入管道；这些对象具有公开的可调用属性（即获取/设置）；与直接操作对象相比，调用 Get-Property/Set-Property 有什么好处？
问题：
什么情况下应该实现IPropertyCmdletProvider接口？
我知道我在这里错过了一些东西！任何见解将不胜感激。
I'm writing a NavigationCmdletProvider for PowerShell. Through the GetItem and GetChildItems overrides, there are various types of objects that are written to the pipeline.
The docs for IPropertyCmdletProvider interface tell us the following:
Developers should implement this
interface under the following
conditions:
- When users must use cmdlets such as the Get-Property and Set-Property
cmdlets.- For a providers that derive from the ItemCmdletProvider,
ContainerCmdletProvider, or
NavigationCmdletProvider classes.
Confusion:
Not a lot of useful information in my opinion because how would a user know if they must use the Get-Property and Set-Property cmdlet's? I would imagine that's up to the Cmdlet author. The big confusion (for me at least) is if the Cmdlet writes the objects to the pipeline; and those objects have properties exposed that are callable (i.e. get/set); what benefits does calling Get-Property/Set-Property have over manipulating the object(s) directly?
Question:
Under what circumstances should the IPropertyCmdletProvider interface be implemented?
I know I'm missing something here! Any insight would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
哇，这些文档有点旧了。没有 Get/Set-Property cmdlet。这必须引用 Get/Set-ItemProperty cmdlet。对于RegistryProvider，这些cmdlet 是必不可少的，因为它是访问注册表值的唯一方法。也就是说，Get-Item/ChildItem cmdlet 仅返回RegistryKey 对象，而不返回注册表值对象（它们在.NET 中不存在）。您必须使用 Get/Set-ItemProperty 来获取/设置 regkey 下的特定 regvals。
OTOH 文件系统提供程序允许您直接访问容器（目录）和叶子（文件）。您可以直接获取文件的内容。不过，如果您想获取文件的 LastWriteTime，则可以使用 Get-ItemProperty：
但是，我通常不会以这种方式访问此属性。我发现输出太冗长了。我会这样做：
至于指导，我想说，如果您采用RegistryProvider方法，您确实需要实现这个接口，但如果您采用FileSystem提供程序所采用的路线，那么它就不那么重要了，因为您可以轻松地直接访问Get-Item/ChildItem 返回的对象。
Wow those docs are a bit old. There are no Get/Set-Property cmdlets. This must be referring to the Get/Set-ItemProperty cmdlets. In the case of the RegistryProvider, these cmdlets are essential because it is the only way to access registry values. That is, the Get-Item/ChildItem cmdlets only return RegistryKey objects and never a registry value object (they don't exist in .NET). You have to use Get/Set-ItemProperty to get/set specific regvals under a regkey.
OTOH the FileSystem provider allows you to directly access containers (dirs) and leafs (files). You can get the content of a file directly. Still, you can use Get-ItemProperty if you want to get the LastWriteTime of a file:
However, I wouldn't normally access this property in this fashion. I find the output is way to verbose. I would do this:
As for guidance, I would say that you really need to implement this interface if you take the RegistryProvider approach but it is less important if you go the route the FileSystem provider went because you can easly access the properties directly of the objects returned by Get-Item/ChildItem.