为什么 Powershell 2.0 与 Powershell 1.0 安装在同一位置？
有谁知道为什么 Powershell 2.0 安装在 Windows 7 机器上的 C:\Windows\System32\WindowsPowerShell\v1.0 中？
Does anyone know why Powershell 2.0 is installed in C:\Windows\System32\WindowsPowerShell\v1.0 on a Windows 7 box?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这实际上是一个关于副作用的有趣故事。
Visual Studio 在其“添加引用”对话框中具有固定的程序集列表。
其他任何东西都必须浏览。
开发人员倾向于在 Windows 目录中浏览此位置，其中 System.Management.Automation.dll（运行大部分 PowerShell 的程序集所在的位置）
这对这个位置进行了绝对引用。
由于 PowerShell 不会有并行安装选项（与 .NET 框架一样），因此最好的选择是允许人们通过路径和 StrongName 继续引用相同的程序集，就像他们以前所做的那样。
如果这个故事没有继续下去，所有在 PowerShell V1 上编写的应用程序都必须针对 V2 重新发布。
It's actually an interesting story in side-effects.
Visual Studio has a fixed list of assemblies in their "Add Reference" dialog.
Anything else has to be browsed for.
Developers tended to browse for this location in the Windows directory, where System.Management.Automation.dll (the assembly that runs most of PowerShell lives)
This made an absolute reference to this location.
Since there wasn't going to be a side-by-side install option with PowerShell (as there is with the .NET framework), the best choice available was to allow people to keep referencing the same assembly, both by path and by StrongName, as they did before.
If this story hadn't have stayed this way, all applications written on top of PowerShell V1 would have to be re-released for V2.
我只是认为，从一开始，微软团队就计划并行部署 PowerShell 版本，就像对 Framework .NET 版本所做的那样。但随着时间的推移，他们决定当时只支持一种 PowerShell。
更奇怪的是，当您使用命令行的 -version 参数选择版本 1.0 时，var
$PSVersionTable出现，PSVersion 值为 2.0。 PowerShell 1.0 中不存在 $PSVersionTable如果您查看两个版本中都存在的 var
$hostPowerShell V2.0（版本 1.0 或 2.0）
PowerShell V1.0
我的观点是PowerShell V2.0能够运行几乎所有PowerShell V1.0脚本。微软添加了一些变量，如果你的脚本中存在这些变量，你可能会遇到麻烦，但它是花生。
太平绅士
I just think that, at the very begining, Microsoft team plan to deploy PowerShell versions side by side, just as it's done for the Framework .NET versions. But with the time they decided to support only one PowerShell at the time.
There something even more strange when you use the -version parameter of the command line to choose version 1.0 the var
$PSVersionTableis present with PSVersion valued to 2.0. $PSVersionTable is not present in PowerShell 1.0If you have a look on var
$hostwhich exists on both versionsPowerShell V2.0 (vith version 1.0 or 2.0)
PowerShell V1.0
My opinion is that PowerShell V2.0 is able to run almost all PowerShell V1.0 scripts. Microsoft add some vars and you can get troubles if you have these vars present in you scripts but it's peanuts.
JP
我认为因为PowerShell 2.0与1.0非常兼容，所以没有必要在同一台机器上有两个不同的版本。因此，他们在 XP 和 Vista 系统上将 2.0 置于 1.0 之上，并且很可能决定为 Windows 7 保留相同的目录。这也是扩展名仍然是 .ps1（以及 .psm1、.psd1）的相同原因。
对于 Windows 7 x64，您也可以提出同样的要求。为什么 64 位系统 dll 位于名为 System32 的目录中，为什么这些相同的 64 位 dll 名称以“32”结尾，例如 user32.dll、kernel32.dll 等。:-)
I think because PowerShell 2.0 is extremely compatible with 1.0, there was no need to have two different versions on the same machine. So they put 2.0 over top of 1.0 on XP and Vista systems and most likely decided to keep the same directory for Windows 7. This is also the same reason the extension is still .ps1 (and .psm1, .psd1).
You could ask the same for Windows 7 x64. Why are the 64-bit system dlls in a dir called System32 and why do those same 64-bit dlls' names end with "32" e.g. user32.dll, kernel32.dll, etc. :-)