C# Powershell 互操作
系统管理员正在编写一些常见的内务处理 Power Shell 脚本。 主要用于 AD 管理（更新交换详细信息、在安全组中移动人员等），
我想使用 C# 中的这些脚本（我打算将其编写为一个库，供网站使用）。
我看过这篇代码项目文章，它看起来很有趣，是一个很好的地方开始。
有人有 Power Shell 互操作的经验吗？ 在我一头扎进尖峰之前，有人能想到任何主要问题吗？
额外信息：
我知道物流方面存在挑战，尤其是 CI 和版本控制方面。
该计划最初是使用目录服务，通过 Web API 和 CmdLets 公开服务。 不幸的是，我们在目录服务方面遇到了困难（例如，大型集的结果被截断）。
与此同时，我认为我应该使用系统管理员的脚本进行调查，而不是使用不一致的组合。 为什么要重新发明轮子？
我已经编写了我的域模型。 我打算实现存储库模式，这样我就可以抽象出 AD/Exchange 集成，从而允许将来进行不同的实现。
The Sys Admin guy is writing some common housekeeping Power Shell scripts. Predominantly for AD management (updating exchange details, moving people around security groups etc.)
I'd like to use these scripts from C# (I intend to write it as a library, consumed by a web site).
I've seen this code project article which looks interesting and a good place to start.
Does anyone have any experience of Power Shell interop? Can anyone think of any major gotchas before I jump head first into a spike?
Extra Information:
I appreciate there are logistical challenges particularly with CI and versioning.
The plan was initially to use Directory Services, exposing services through a web API and CmdLets. Unfortunately we’re having difficulties with Directory Services (e.g. truncated results for large sets).
In the meanwhile, rather than use an inconsistent mix, I figured I should investigate using the Sys Admins’ scripts. Why re-invent the wheel?
I’ve already written my domain model. I intend to implement the repository pattern so I can abstract out AD / Exchange integration allowing different implementations in the future.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果脚本依赖于系统或用户配置文件，那么您需要首先将配置文件显式点源到您的运行空间中。
更高级别的控制（例如从一个命令到另一个命令的会话，...访问调试输出）需要更高级/低级/复杂的工作。
除此之外，一切都正常。
If the scripts have dependencies on system or user profile, then you will need to explicitly dot-source the profile into your runspace first.
Higher levels of control (e.g. session carried from one command to another, ... accessing debug output) require more advanced/low-level/complex work.
Other than that, it all just works.
我不认为这种方法比从编译程序运行脚本的常见问题有很多问题。 我发现最大的问题往往是
但我确实认为你应该考虑另一种发展模式。 为什么不将所有逻辑添加到已编译的库中，而不是让程序引用脚本。 这可以轻松链接到程序并通过 CmdLet 暴露给 PowerShell。 我发现这是在程序中的脚本之间维护共享代码的更简单的方法。
I don't think there are many Gotchas to this approach over the usual problems of running a script from a compiled program. I find the biggest problems tend to be
But I do think you should consider another model for your development. Instead of having a program reference a script, why not add all of the logic into a compiled library. This can be easily linked into the program and exposed to PowerShell via a CmdLet. I find this is an easier way to maintain shared code between scripts in programs.
过去几个月我一直在 C# 应用程序内部运行 PowerShell 代码，它运行良好，您可以用它做一些非常有趣的事情。 也就是说，JaredPar 提到将 PowerShell 脚本放在应用程序外部的脚本文件中可能会很痛苦。 我将所有 PowerShell 代码都放在一个库中，并将其运送到需要的地方并且运行良好。
I've spent the last few months running PowerShell code from insite a C# application and it works fine, you can do some pretty interesting stuff with it. That said as JaredPar mention having the PowerShell script in script files outside the app can be a pain. I have all my PowerShell code in a library and ship that around to where its needed and it works well.