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