我会先说这是针对 Microsoft 唯一商店的问题。
如果您要编写一个控制台应用程序来管理数据仓库，您会使用什么：
1）为 PowerShell（也就是 Exchange / SQL Server 的最新版本）编写一个自定义环境
2）将其编写为 C# 控制台应用程序
如果 #2 是否有任何框架可以为您减轻编写“菜单系统”或任何其他任务的负担。
如果这个应用程序需要持续 6 到 8 年 - 你会使用 PowerShell 吗？目前团队中没有人拥有 PowerShell 经验，但我们是快速学习者。
如果您将管理功能编写为 PowerShell cmdlet，那么您可以通过让人们直接运行 cmdlet 或将它们包装在 GUI 中来展示该功能。使用 PowerShell 可能会为您提供最长期的灵活性，并且随着 MS 实施更多 PowerShell cmdlet，这意味着管理您的数据仓库可以在必要时与其他更大的业务流程合并。我可能不会选择编写 C# 控制台应用程序 - 但我有一个明显更“管理员”的观点。我们管理员已经厌倦了向我们扔自定义控制台应用程序 - PowerShell 的想法是以支持命令行和 GUI 管理的方式标准化所有内容。
我认为您可以在两者上都取得成功，并且应该能够在两者之间切换而不会太麻烦。如果您开始构建控制台应用程序但后来学习 PowerShell，您可以丢弃大量控制台应用程序特定的代码（例如命令行解析代码）并构建一些 PowerShell cmdlet 来包装您现有的 API。或者，如果您构建了一堆 Cmdlet，但稍后需要切换到控制台应用程序，您将不会浪费太多时间来编写 Cmdlet。
所以，我真的没有任何强烈的建议。我会说：嘿，去试试 PowerShell。如果你不喜欢它，切换也不是太难。
我发现 PowerShell 对于较小的事物来说是一种更易于维护的解决方案。控制台应用程序需要重新链接到新库，并在您依赖的库发生更改时重新编译和重新分发（在我的情况下，来自 Visual Studio 2005 - Visual Studio 2008 的代码覆盖和其他内容）以及您的脚本可能调用 vsinstr、mstest 等的可执行文件. 与 PowerShell 脚本一样，您可以轻松地为您拥有的每个环境进行自定义，而不必为您选择的每个环境进行编译、链接和部署。事实上，如果您从注册表中获取路径信息，则相同的脚本可以在两种环境中运行。
你可以做任何你想做的事情，我只是更喜欢维护一个简单的文本文件，然后是一个控制台应用程序。只是个人喜好。
当您说管理数据仓库时，您指的是什么类型的任务？
我会在 T-SQL 中进行的大部分管理（清除、归档、转换）——其接口可能非常薄（甚至不存在）。
好的，根据您的评论，我将拥有在存储过程中使用 .NET 程序集（典型的 API 类库）完成所有工作的代码，尽可能多地在存储过程中，其中的程序集更容易在那里完成或者需要COM或其他什么。然后，我要么将类库包装在 cmdlet 中，要么只从 PowerShell 调用 .NET 对象（请记住，PowerShell 可以实例化对象。）。
现在你有了一个 .NET 库，如果你想要的话，它也可以从网页、GUI 应用程序等中调用，并且你有一个 cmdlet 和一个直接的 .NET 接口——如果它们是的话，还可以选择从 SQL 调用它们在 SQL 层完全实现。
实现 PowerShell 而不是一个 cosole 应用程序的美妙之处在于，您不必编写所有参数解析或所有格式的代码。PowerShell 会为您处理所有这些。当然，如果需要，您可以覆盖默认值。您可以免费获得通配符。您还可以让您的 Cmdlet(s) 从管道中获取值，这为自动化开辟了各种可能性和用途。使用 PowerShell，最终用户和开发人员都将获得更好的体验。