Sergei Antonov's blog

  • New features in RTW of PowerShell IIS snap-in

    IIS team announced the release of PowerShell snapin at the MIX 09 conference in March. Since the last preview release we added number of features and changed format of XPath queries. In this post I will describe some of these changes.

  • XPath, PowerShell and custom trust level in ASP.NET

    When you manage IIS and related products you often need to deal with configuration files that are not part of IIS configuration. You cannot use cmdlets from IIS7 PowerShell snapin for those files, but you could use XPath engine, provided by managed framework in System.Xml.XPath and there is a lot of common in XPath queries that we use for configuration APIs and for other configuration XML files. It is expected -- as soon as structure of files is similar to the structure of configuration tree, same XPath queries should produce similar results.

  • Extension cmdlets for IIS – done right way

    In my previous post I explained how to write your custom commands, that are based on lower level cmdlets. Well, there is a problem with this approach. As soon as we call InvokeScript() passing command line as string, PowerShell interpreter will process is exactly the same way as if it would be entered by user in console window. If command line will have parameters, which are embedded script blocks, those will be executed. This is not secure, because you cannot control where input is coming from. People name this security issue “script injection”. If user enters command line with script blocks from keyboard, it is up to him/her to decide, is it safe to run or not. In our case we are taking parameters and building new command line. What if parameter is coming from the file on disk, or from outside world? It could be unpleasant surprise to see side effects of your script.

  • 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: