对于一些监控应用程序和需要计划轮询某些服务的任务，我们传统上使用控制台应用程序，该应用程序反过来调用我们业务层中的某些方法或轮询文件位置/ftp 位置。
对于我正在执行的另一项任务，我开始使用 Powershell 并印象深刻，这让我开始思考 Powershell 脚本和控制台应用程序有什么好处。
似乎可以在不重新编译的情况下即时编辑 powershell 脚本，这使其成为潜在更改的一个优点，但肯定有我没有看到的缺点。
那么人们什么时候会建议将控制台应用程序换成 Powershell 脚本呢？
【问题讨论】：
标签： .net powershell
我认为更好的方法是，您什么时候选择控制台应用程序？
如果您不关心前沿的运行速度、分发给第三方（PowerShell 还不是很标准）或保护源代码，那么我认为 PowerShell 是一个强有力的竞争者。
顺便说一句，PowerShell 可以开箱即用地操作 COM 对象，因此就任务自动化而言，它可以很好地作为 .NET 和基于 COM 的基础架构之间的粘合代码。
【讨论】：
对我来说最大的好处是失去了编译过程并推出了二进制文件。我给你举个例子。我有一个应用程序使用 Visual Studio 私有程序集文件夹中的一些程序集，该应用程序插入二进制文件并在我们的编译过程中运行单元测试。当 VS 2008 出现时，我不得不更改资源、重新编译，然后必须将二进制文件部署到我们所有的构建服务器。我认为这很愚蠢，并切换到 PowerShell，所以现在我的脚本可以确定安装了哪个版本的 vsts 并加载到最高版本的 dll 中。现在你可以在应用程序中使用反射和后期绑定和其他东西来做到这一点，但在 PowerSHell 中要容易得多，当我们添加二进制文件或删除我们需要检测的二进制文件时，每个 Release ENgineer 都可以在文本编辑器中快速修改脚本.对于小型内部应用程序，我现在总是 PowerSHell...
【讨论】：
嗯，您的机箱似乎非常适合 Powershell 的设计用途。我能想象到的唯一可能的缺点是，Powershell 可能会有点慢，因为它是解释而不是编译的，而且也没有针对速度进行优化，而是为了易于使用。
【讨论】：
您还应该考虑“应用程序”的大小。如果单个小文件可以管理任务，那么 PowerShell 是一个很好的解决方案。一旦超出此范围，您就需要询问有关脚本与典型应用程序代码的可维护性和可理解性的问题。 （源代码控制不应该进入等式，因为两者都应该存储在那里！）
【讨论】：
不要低估本质上免费的参数解析的价值，使用 V2 中的高级功能会变得更好。想想你编写的所有小控制台应用程序，以及这些代码中有多少是参数解析而不是做一些有趣的事情。还要考虑一下您处理参数解析的能力如何？你处理位置参数和命名参数吗？参数验证怎么样？默认参数值？响应文件呢？虽然 Posh 不支持字面意义上的响应文件，但在 V2 中，有一个 splatting 运算符允许您将参数打包到数组或哈希表中 - 非常相似的功能。
OTOH 在某些时候，如果我的脚本开始变得庞大并且我调用 .NET 代码而不是 cmdlet，我开始考虑编写一个 cmdlet 来完成这项工作。 VS 调试器仍然比 V2 调试功能更好。
【讨论】：