PowerShell:如何用PowerShell创建WinForm窗体？-在PowerShell中使用GUI界面

                         从印度小哥那里受到启发，PowerShell不止可以做批处理，自动化。还能做界面做GUI,也能实现很好的交互。因为PowerShell是可以和.Net 程序无缝集成的。所以.Net能用的东西在PowerShell里也几乎都能使用。那么如果想让PowerShell的交互性更强，更友好无疑是创建一个友好GUI界面了。本文介绍如何在PowerShell中创建窗体程序。

目录

前言

一、创建Hello World窗口

1. 手残篇

2. 使用Assembly Name引入.net 库

3.使用DLL文件路径引入.net 库

4. 再次使用Assembly Name引入.net 库

二、添加Hello Button控件

1. 添加Button

2. 添加事件

3. 防止窗口假死

 4. 控制按钮的状态，拒绝加班

三、添加进度条

1. 添加进度条和状态标签

2. 添加更新状态的方法

总结

---

前言

这个前xi有点长，啊不对是前言。请耐心看完。

我为什么会写这篇文章呢？主要还是被印度小哥灵活的头脑震惊到了。

事情是这样的，之前在某外资银行工作的时候，因为大部分的系统和服务器都是运行在Windows下的。需要不定期在服务器上安装微软的补丁，这是一个纯手工的工程~~~OMG囧囧。你没看错，即使今天也仍然有很多企业在手动干这件事情。

那么装的多了难免有点腻歪，于是印度小哥成立了一个自动化部门，他们发布了一个宏大的愿景，就是立志要提高公司的自动化水平。（至于提高多少他们没说）

所以他们的第一个目标就瞅准了给Windows打补丁这回事，按理说计算机应该可以自动安装补丁才对啊？我们自己的机器不都是自动安装的吗？

事情没有那么简单。

由于银行对安全和风险控制及其严格，所以一般来讲银行的服务器是不能连外网的。当然也有其它的技术在内网实现补丁管理这一过程。但是，这不还没实施吗！而银行每一台服务器上都有可能跑着不同的服务和应用，某些补丁和更新动不动就重启服务器或者服务啥的，而IT部门是不知道的，因此打补丁这个看似简单的过程变得复杂起来。

刚开始IT部门尝试过统一打补丁什么的，但是每个服务器运行的应用程序不同，对可用性的要求不同。众口难调，补丁部门又不想承担过多的责任。比如打补丁把数据弄丢啦，把服务干倒了，银行系统宕机什么的。所以最后为了图省事就干脆把这个权限下放给对应的应用维护团队了，因为每个团队对自己的应用是最清楚的。（有点要向DevOps转向的意思哈^_^）

而这时候自动化部门出动了，豪言要自动化这一过程。于是他们开发了一套程序给每个应用团队让他们使用这个程序来自动化打包流程。

而我们部门刚刚得到这个程序的时候，一看是几个PowerShell脚本。那就先运行一下试试看喽。一运行，我艹，什么玩意不是跑个脚本就把补丁打完了吗？怎么还出来WinForm界面了。不简单~不简单~

于是关了脚本，用VSCode打开他们的脚步仔细的拜读了一下。不读不知道，一读真奇妙。明明可以用C#来直接写个Winform， 他不，非要用PowerShell来写。明明PowerShell脚本加几个参数就能一键运行打补丁，他不，非要在PowerShell里面用WinForm创建一个交互式的界面，里面又是添加补丁路径，又是拷贝补丁包，还用WinForm做了Log和进度显示。自动化团队还真是下了一番功夫。

之前在 PowerShell: 如何使用PowerShell操作FTP？ 中也提到PowerShell也是可以和.net 代码无缝集成的，知道归知道，但是真的这么用的还是第一次见，又给自己涨姿势了。毕竟一般情况下我会认为PowerShell就是用来跑些后台命令或者脚本的，如果有需要比较复杂的交互就直接用VS写了。但是用PowerShell来写这种程序也有些好处，那就是修改维护比较简单-即改即用，无需编译。而且PowerShell里面对有些事件和数据的处理也比较简单。

因此对PowerShell中使用WinForm程序做了一个简单的总结，以备后用。

---

一、创建Hello World窗口

虽然只是个Hello World，但是也经历了几番曲折。

1. 手残篇

上来想都没想，直接上代码

$Form = New-Object System.Windows.Forms.Form 
$Form.Name = "Form1";
$Form.Text = "PowerShell Form (Hello world!)";
$Form.ShowDialog()

古人曰：欲速则不达。果然，直接抛错了：

一看很明显这不就是对应Type找不到嘛，应该是对应的.net 库没有加载。

2. 使用Assembly Name引入.net 库

 记得PowerShell里面可以用using关键字直接引入DLL，那我也来高级一把。

using assembly "System.Windows.Forms, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

 然鹅，事情并没有沿着我的脑回路发展

使用Assembly Name~扑街

3.使用DLL文件路径引入.net 库

难道using 不能直接从GAC里面加载DLL ？查看了一下微软官方示例，我去难道要用路径才行么？

 找到这个DLL对应的文件路径再试一次

using assembly "C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll"

 bingo~~~ 没有抛错没有异常提示，搞定！

4. 再次使用Assembly Name引入.net 库

事情上面第三步似乎也就完了，但是我偏不信邪。用Assembly Name看起来多友好啊，不用关心这个DLL的具体路径，就可以自动找到对应的DLL。但是using只支持文件路径这一招，没法破。

那么问题的本质是什么呢？-- 当前的运行程序没有加载对应的DLL导致相关的类型找不到。

既然是这样那用反射的方法是不是也可以？只要DLL加载到当前的运行环境就可以了。重要的是使用反射的方式可以使用Assembly Name。