铸剑谷

cmdlet虽然编译后是一个程序集,但是它内嵌于powershell.exe中运行,所以它的配置文件用app.config就不太适合了,得用powershell.exe.config,发现原来没有,就自己加一个过去,改个名就可以了.

今天碰到一个让人狂晕的问题,那就是明明在配置文件里面加了配置项了,但是在程序里面死活读不到,于是到处找,因为之前已经给cmdlet加了config,并给里面配置了一个connectionstring,但是这次加的两个appsetting不生效.最后发现那个修改的文件的最后修改日期还是停在了上次的时间,并没有更新过来,但是打开文件的时候,又可以看到完整内容.一个比较恐怖的念头出现了,那就是系统不知道用了什么策略为了保护windows目录下面的文件,不能去写文件,只能够用覆盖的方式来实现。（我的机器是Vista，发现所有的Windows等核心目录里面自己弄的文件全放在%userprofile%\AppData\Local\VirtualStore\目录下，估计这是为了保护系统，以及为了能比较好地恢复系统吧）。

Cmdlet在使用的时候，可以用$v=cmdlet 这种方式把cmdlet的输出保存给变量，特别是输出的是对象或是列表的时候，这样获取值还可以传给后面cmdlet的继续使用.在为了把输出的对象列表格式发成一个表格的时候，花了偶N多时间，因为系统提供的例子是Get-Process这个例子，得到的进程列表信息输出的时候，不用任何的操作就可以直接输出成一个列表，但是自己写的对象，死活以一种不专业的形态输出来：属性名：值 这样一行一行地输出来。开始我总觉得是对象实现了某一个接口或是某个attribute起了作用，自己尝试去实现这些，可是就是不行。最后突然想到了powershell目录下面的那些ps1xml文件，拿editplus打开它们，发现原来这些会自动列表的对象在这里面都定义好了每个字段可以显示成什么名字，以及列宽什么的。因为没有时间了，所以只好先在输出的时候用format-table这个管道来格式化成列表，以后再研究怎么修改这些ps1xml。

现在感觉有两个地方让人不爽了，一个就是配置文件不能随着cmdlet的plugin文件走，另一个就是对象列表的说明还要自己搞ps1xml来描述，这对于cmdlet的分发造成了不便。这东西给别人用的时候，只好写上把config和原来的合并一下，把ps1xml复制到运行目录上。在MSDN里面有看到一个make-shell命令，但是本机运行的时候，没有发现这个命令，GOOGLE的时候，发现那是UNIX上的。

打印 | 张贴于 2007-10-22 22:14:00 | Tag:暂无标签