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