Contents tagged with PowerShell
-
Simple way of extending PowerShell objects with custom methods
As you may know, IIS configuration is extensible. You could add new section, extend existing one by adding new schema file into folder containing schemas. All this was described in full details in the article of Tobin Titus. When we provide methods on configuration elements with COM extension, the only way to call it using configuration APIs is through creation of method instance, then creation of input parameters element on this instance, etc -- quite convoluted way. In PowerShell we expose it in more convenient way, like intrinsic methods on the object. User is able to call these methods exactly the same way as any other intrinsic methods of given object. Let's see how runtime methods work on site element:
-
How to change output format in PowerShell
I was looking around the Net today and stumbled on the post in Scott Hanselman's blog, where he talks about technical and marketing aspects of product naming in Microsoft. There he shows display format for IIS application pools that may be relevant to servers, where admins keep multiple versions of CLR and run applications in various modes. This output includes managed runtime version for the pool and mode (integrated or classical) for the pool. By default IIS provider shows only name, state and list of applications, assigned to this pool. It is pretty easy to change this output to what Scott prefers.
-
How we use XPath in IIS PowerShell namespace
IIS 7 configuration API's were designed as DOM: you always have to start from top level data structure and work your way to the data you need, either collection element or child element attributes. It is quite annoying model when you are building generic tools, and soon we started looking for some way of cutting off amount of code required for access of internal collections and attributes. At some moment we realized that we could use System.Xml.XPath.XPathNavigator type to expose IIS configuration. This type could be used to represent any hierarchical data as tree for XPath queries, not necessarily originated in XML. That was a perfect fit: with XPath query we could access any entity inside of configuration in one step. First CTP of provider was based on this approach. It worked nice but was pretty slow. Keeping XPath engine in managed code introduced major performance bottleneck: configuration data are in non-managed code, and XPath engine should marshal across the border every piece of data during processing of query. To make it better, fearless IIS developer William Moy created XPath query processor in native code, following the same model as XPathNavigator, and second CTP of provider is based on this engine. It is so effective, that when we access internal data inside of configuration section using fully qualified path it takes in average only 10% longer than using straight code based on explicit configuration API's, when this code accesses the same data. Fully qualified here means that path points to the unique data inside of configuration, and query don't need to walk around big parts of tree. As you probably know, configuration system in IIS 7 is distributed, and is merged from multiple configuration files located in root folders of virtual directories and file system folders below them. Path that points to any of these containers for configuration files named commit path. XPath engine works with the search tree built from IIS configuration sections, merged from files which were gathered along some commit path. The tree has root, represented by root section group, then it includes child groups and sections, then child elements and collection elements, so it is kind of like Object Viewer tree in Visual Studio, rather than file system tree. If written properly, XPath query could return just one unique piece of data from configuration, in that case we could use it as universal addressing format for configuration data. Or it could select set of nodes from the search tree, in that case it is good to describe groups of data, for example, all sites, or all applications of the site, etc. If we store these queries into some place, we could describe our own namespace, composed from data extracted from configuration by these stored queries. XPath queries are the backbone of IIS 7 PowerShell namespace: if you open file NavigationTypes.xml, you will see that most of things in the namespace are described as XPath queries, for example,
-
IIS7 PowerShell support -- details of our design
After IIS team released Technical Preview of our PowerShell provider and commands, we got a few rants and grumblings from our customers. Some people pointed to complexity of IIS PowerShell provider and command parameters. Other people denied the need of provider for IIS at all, telling that just a set of commandlets with simple parameters will be sufficient. I have to admit that we did a mistake shipping preview of provider without complete set of commands. This created an impression of incomprehensible complexity of our tool.