CarlosAg Blog : .NET

Microsoft Web Platform Installer Beta Released

CarlosAg — Thu, 02 Oct 2008 14:00:00 GMT

Today we are releasing a new Web Site at http://www.microsoft.com/web/ where users can get a one stop shop for learning about the Microsoft Web Platform. This is part of a bigger effort to make it easier to get started with building and running Web Applications on Windows and IIS.

As part of this a new tool called the Web Platform Installer Beta is also being released to help you getting started installing and getting all the software that you need from a single place without having to hunt around for installers, links or anything else. Just launch the tool, choose the software and configuration you are interested and it takes care of validating and installing pre-requisites.

This tool will let you easily setup your development machines for building Web Applications quite nicely, it will also help you discover new tools, applications, features and beta's as they are getting released from several sources including IIS, ASP.NET and Visual Web Developer and more as we continually make new software available through updates to the feed that the tool consumes.

Download page: http://www.microsoft.com/web/channel/products/WebPlatformInstaller.aspx

Link to Run it: http://go.microsoft.com/?linkid=9588072

Here are a few snapshots of the tool:

This is the start page where you can choose to install everything available or customize the installation (Your Choice).

In this page you can customize the selection and browse around all the current list of products and check and uncheck any product you want to install.

There are a couple of more pages, and finally the progress where the tool downloads any files required and install them, so that you can at once get the whole Web Platform installed easily.

Some of the products and features that the Beta supports installing and configuring include:

IIS (Ability to granularly configure each of the features of IIS)
IIS Extensions (such as the Out-of-band releases that we have made available in http://www.iis.net including Bit Rate Throttling, Web Playlist, Microsoft Web Deployment, FTP 7.0 Server, URL Rewrite, and more)
.NET Framework 3.5
SQL Express 2008
SQL Server Driver for PHP
Visual Web Developer 2008 Express
Windows Installer 4.5
more

So as you can see everything you need to build Web Applications, from a Web Server (IIS), to a Development tool (Visual Web Developer) to a Database (SQL Server Express) and many more all for free.

So go ahead and try the tool, give us feedback (remember this is a Beta) so it can only get better :)

Adding ASP.NET Tracing to IIS 7.0 Failed Request Tracing

CarlosAg — Fri, 04 Jul 2008 18:00:00 GMT

IIS 7.0 Failed Request Tracing (for historical reasons internally we refer to it as FREB, since it used to be called Failed Request Event Buffering, and there are no "good-sounding-decent" acronyms for the new name) is probably the best diagnosing tool that IIS has ever had (that doesn't require Debugging skills), in a simplistic way it exposes all the interesting events that happen during the request processing in a way that allows you to really understand what went wrong with any request. To learn more you can go to http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis7/.

What is not immediately obvious is that you can use this tracing capabilities from your ASP.NET applications to output the tracing information in our infrastructure so that your users get a holistic view of the request.

When you are developing in ASP.NET there are typically two Tracing infrastructures you are likely to use, the ASP.NET Page Tracing and the System.Diagnostics Tracing. In recent versions they have been better integrated (attribute writeToDiagnosticsTrace) but still you want to know about both of them.

Today I'll just focus on logging ASP.NET Tracing to FREB, and in a future post I will show how to do it for System.Diagnostics Tracing.

To send the ASP.NET Tracing to FREB you just need to enable ASP.NET tracing, use the ASPNET trace provider and you will get those entries in the FREB log. The following web.config will enable FREB and ASP.NET Tracing. (Note that you need to go to the Default Web Site and Enable Failed Request Filtering so that this rules get executed)

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
    <trace enabled="true" pageOutput="false" />
</system.web>
<system.webServer>
    <tracing>
      <traceFailedRequests>
        <add path="*.aspx">
          <traceAreas>
            <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
            <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,Compression,Cache,RequestNotifications,Module,Rewrite" verbosity="Verbose" />
          </traceAreas>
          <failureDefinitions statusCodes="100-600" />
        </add>
      </traceFailedRequests>
    </tracing>
</system.webServer>
</configuration>

Now if you have a sample page like the following:

<%@ Page Language="C#" %>
<script runat="server">
    void Page_Load() {
        Page.Trace.Write("Hello world from my ASP.NET Application");
        Page.Trace.Warn("This is a warning from my ASP.NET Application");
    }
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    </div>
    </form>
</body>
</html>

The result is that in \inetpub\logs\FailedReqLogsFiles\ you will get an XML file that includes all the details of the request including the Page Traces from ASP.NET. Note that we provide an XSLT transformation that parses the Xml file and provides a friendly view of it where it shows different views of the trace file. For example below only the warning is shown in the Request Summary view:

There is also a Request Details view where you can filter by all the ASP.NET Page Traces that includes both of the traces we added in the Page code.

IIS 7.0 Talk at ASP.NET Connections at Orlando

CarlosAg — Mon, 28 Apr 2008 15:15:00 GMT

Last Monday I gave a presentation at the ASP.NET Connections event in Orlando, the title was IIS 7.0 for ASP.NET Developers. I just wish I had more time to stay at Orlando, weather was great, especially considering that Sunday I was watching Snow in Redmond and then Monday and Tuesday I was around 80 degrees in sunny Orlando.

Anyway, thanks for all the people who attended the session, you can download the

Slides and the Demos from here.

Here are some of the things that I demonstrated:

First Demo: ApplicationHost.config, Web.config and Tools.

Showed the Application Pools list and how Visual Studio 2008 now provides IntelliSense for all the configuration of IIS.
Added a new Application Pool using Notepad, and IIS Manager shows it.
Showed the Sites section and created a new /Temp Application to my c:\temp directory.
Browsed to the application and showed the new detailed error messages that IIS7.0 includes giving you all the details on what the problem is, and suggestions on how to fix it.
Created a new Web.config where I enabled system.webServer/directoryBrowse and showed how this immediately applied the changes.
Showed all the new tools that IIS includes for managing web.config, including IIS Manager, AppCmd, Javascript, and the new Configuration Editor included in IIS Admin Pack that will allow you to generate scripts for all of them.

Second Demo: Pipeline Mode and Application Migration

Showed the Application Pools created by IIS, explained some of the differences in Classic Mode versus Integrated Mode.
Showed how to create a new Application Pool and where to specifythe pipeline modes.
Downloaded BlogEngine.net and created an application for it running in Integrated Mode. Showed the detailed errors when IIS detects compatibility issues with the pipeline mode and settings like <httpModules/httpHandlers>.
Showed how assigning it to a Classic Mode immediately makes it run in the same way as before.
Then moved it back to Integrated Mode, and showed how to use AppCmd to migrate config (appcmd migrate config "path"), and showed the changes between the original web.config and the updated one.
Explained these differences and how this is the right way to create applications that will run in IIS6, IIS7 classic mode and IIS7 integrated mode

Third Demo: Leveraging the Integrated Pipeline

Showed a typical application that was configured using Forms Authentication and ASP.NET Membership and how accessing other content than ASP.NET (i.e. text files, images, classic ASP etc) would not cause authentication to happen.
Showed how easy just by changing the FormsAuthentication module and the UrlAuthorization module you were able to easily now authenticate all the requests, including Classic ASP, PHP, static files, etc.

Fourth Demo: Output Caching

Showed a little performance script using WCAT running against the BlogEngine.net in my laptop (running Windows Vista) gave around 400 requests per second, and made W3WP.exe take about a 100% of CPU, meaning it couldn’t do anything more.
Enabled Output Caching using IIS Manager for .aspx pages.
Ran the Stress Test again, and this occasion the results were that we got around 1000 requests per second, but more importantly CPU consumed by W3WP.exe was only around 20%. The Stress client was the one taking all the CPU, meaning that the server could easily do more than twice as many request per second if the stress client was done by another machine.

Fifth demo: Extensibility

Showed how easy it is to extend IIS using Managed code, building a Handler that would translate PNG images to Jpeg images as well as embed a copyright information all dynamically at runtime.
Showed another simple example on how to extend using a Module that logged every request to a SQL Server database.

Then I ran out of time :)

Not getting IntelliSense in your web.config for system.webServer sections in Visual Studio 2008?

CarlosAg — Sun, 20 Apr 2008 03:20:00 GMT

Today I was playing a bit with Visual Studio 2008 and was surprised to see that I was not getting IntelliSense in my web.config. As you might already know IntelliSense in Xml in Visual Studio is implemented by using a set of schemas that are stored in a folder inside the VS folder, something like: \Program Files\Microsoft Visual Studio 9.0\Xml\Schemas. After looking to the files it was easy to understand what was going on, turns out I was developing using .NET 2.0 settings and Visual Studio now ships different schemas for Web.config files depending on the settings that you are using: DotNetConfig.xsd, DotNetConfig20.xsd and DotNetConfig30.xsd.

As I imagine I looked into the DotNetConfig.xsd and it indeed has all the definitions for the system.webServer sections as well as the DotNetConfig30.xsd. However, DotNetConfig20.xsd does not include the section details, only its definition, so to fix your IntelliSense you can just open DotNetConfig.xsd, select the entire section from:

<xs:element name="system.webServer" vs:help="configuration/system.webServer">...</xs:element>

and just replace the entry in DotNetConfig20.xsd. You might also want to copy the system.applicationHost section and add it to the DotNetConfig20.xsd since it does not include it as well.

How to register a new Section Definition using Microsoft.Web.Administration

CarlosAg — Tue, 15 Apr 2008 15:10:00 GMT

Today I was asked how can someone would be able to add a new section definition using Microsoft.Web.Administration, so I thought I would post something quickly here just to show how this could be achieved.

using System;
using Microsoft.Web.Administration;

class Program {
    static void Main(string[] args) {
        using (ServerManager m = new ServerManager()) {
            Configuration config = m.GetApplicationHostConfiguration();

            SectionDefinition definition =
                RegisterSectionDefinition(config, "system.webServer/mySubgroup/mySection");
            definition.OverrideModeDefault = "Allow";

            m.CommitChanges();
        }
    }

    public static SectionDefinition RegisterSectionDefinition(Configuration config, string sectionPath) {
        string[] paths = sectionPath.Split('/');

        SectionGroup group = config.RootSectionGroup;
        for (int i = 0; i < paths.Length - 1; i++) {
            SectionGroup newGroup = group.SectionGroups[paths[i]];
            if (newGroup == null) {
                newGroup = group.SectionGroups.Add(paths[i]);
            }
            group = newGroup;
        }

        SectionDefinition section = group.Sections[paths[paths.Length - 1]];
        if (section == null) {
            section = group.Sections.Add(paths[paths.Length - 1]);
        }

        return section;
    }
}

The idea is that you can grab a Configuration object they usual way, it could be ApplicationHost.config or any web.config, and then you call the method RegisterSectionDefinition which will ensure the whole hierarchy is added (in the case of multiple nested Section Groups) and then it will return the newly added Section Definition that you can then use to change any of their properties.

A very similar functionality is exposed for scripts and native code in the AHADMIN COM library exposing the RootSectionGroup as well from any IAppHostConfigFile that you can manipulate in the same way.

Hope this helps,

Host your own Web Server in your application using IIS 7.0 Hostable Web Core

CarlosAg — Mon, 14 Apr 2008 11:00:00 GMT

IIS 7.0 includes a very cool feature that is not so well known called Hostable WebCore (HWC). This feature basically allows you to host the entire IIS functionality within your own process. This gives you the power to implement scenarios where you can customize entirely the functionality that you want "your Web Server" to expose, as well as control the lifetime of it without impacting any other application running on the site. This provides a very nice model for automating tests that need to run inside IIS in a more controlled environment.

This feature is implemented in a DLL called hwebcore.dll, that exports two simple methods:

WebCoreActivate. This method allows you to start the server. It receives three arguments, out of which the most important one is applicationHostConfigPath that allows you to point it to your very own copy of ApplicationHost.config where you can customize the list of modules, the list of handlers and any other settings that you want your "in-proccess-IIS" to use. Just as ApplicationHost.config you can also specify the "root web.config" that you want your server to use, giving you the ability to completely run an isolated copy of IIS.
WebCoreShutdown. This method basically stops the server listening.

The real trick for this feature is to know exactly what you want to support and "craft" the IIS Server configuration needed for different workloads and scenarios, for example:

Static Files Web Server - Supporting only static file downloads, good for HTML scenarios and other simple sites.
Dynamic Web Sites
1. ASPX Pages
2. WCF
3. Custom set of Http Modules and Handlers
All of the above

An interesting thing to mention is that the file passed to ApplicationHostConfigPath parameter is live, in the sense that if you change the configuration settings your "in-process-IIS" will pick up the changes and apply them as you would expect to. In fact even web.config's in the site content or folder directories will be live and you'll get the same behavior.

Sample

To show how easy this can be done I wrote a small simple class to be able to run it easily from managed code. To consume this, you just have to do something like:

internal class Program {
    private static void Main(string[] args) {
        int port = 54321;
        int siteId = 1;

        WebServer server = new WebServer(@"d:\Site", port, siteId);
        server.Start();
        Console.WriteLine("Server Started!... Press Enter to Shutdown");

        Console.ReadLine();

        Console.WriteLine("Shutting down");
        server.Stop();
    }
}

This will start your very own "copy" of IIS running in your own process, this means that you can control which features are available as well as the site and applications inside it without messing with the local state of the machine.

A very interesting thing is that it will even run without administrator privileges, meaning any user in the machine can start this program and have a "web server" of their own, that they can recycle, start and stop at their own will. (Note that this non-administrative feature requires Vista SP1 or Windows Server 2008, and it only works if the binding will be a local binding, meaning no request from outside the machine).

You can download the entire sample which includes two configurations: 1) one that runs only an anonymous static file web server that can only download HTML and other static files, and 2) one that is able to run ASP.NET pages as well.

Download the entire sample source code (9 kb)

You might be asking why would I even care to have my own IIS in my executable and not just use the real one? Well there are several scenarios for this:

Probably one of the most useful, as mentioned above this actually allows non-administrators to be able to develop applications that they can debug, change configuration and pretty much do anything without interfering with the machine state.
Another scenario might include something like a "Demo/Trial CD" where you can package your application in a CD/DVD that users then can insert in their machine and suddenly get a running/live demo of your Web Application without requiring them to install anything or define new applications in their real Web Server.
Test Driven Development. Testing in the real Web Server tends to interfere with the machine state which is by definition something you don't want in your test environments, ideally you want your tests to be done in an isolated environment that is fully under control and that you will not have to do any manual configuration. This makes this feature an ideal candidate for such scenario where you own the configuration and can "hard-code" it as part of your automated tests. No more code for "preparing the server and site", everything starts pre-configured.
Build your own service. You can build your own service and use Hostable WebCore as a simple yet powerful alternative to things like HttpListener, where you will be able to execute Managed and Native code Http Modules and Handlers easily without you having to do any custom hosting for ASP.NET infrastructure.
Have your own Development Web Server where you can have advance interaction between both the client and the server and trace and provide live debugging information.
many, many more...

In future posts I intent to share more samples that showcase some of this cool stuff.

Summary

IIS 7.0 Hostable WebCore feature allows you to host a "copy" of IIS in your own process. This is not your average "HttpListener" kind of solution where you will need to implement all the functionality for File downloads, Basic/Windows/Anonymous Authentication, Caching, Cgi, ASP, ASP.NET, Web Services, or anything else you need; Hostable WebCore will allow you to configure and extend in almost any way the functionality of your own Web Server without having to build any code.

IIS Admin Pack: Configuration Editor

CarlosAg — Mon, 31 Mar 2008 11:00:00 GMT

Today I will be talking about one of the features included in the new IIS Admin Pack called Configuration Editor.

Configuration Editor is an IIS Manager feature that will let you managed any configuration section available in your configuration system. Configuration Editor exposes several features from configuration that are not exposed anywhere else in IIS Manager, including:

Schema Driven - Config Editor is entirely driven by the configuration schema (found in \windows\system32\inetsrv\config\schema\), this means that if you extend the configuration system creating your sections, they will be available for managing inside config editor, no need to build additional UI for them.
Additional Information - Config Editor exposes more information such as the deepest place where the section is being used, or where a particular element in a collection is coming from (where is it inherited from?), etc.
Script Generation - Allows you to make changes and it generates the code to automate those tasks, generating Managed Code (using Microsoft.Web.Administration), JavaScript (using AHADMIN) or Command Line (using AppCmd).
Searching - Allows you to quickly perform scoped searches of the configuration system for all the sections and where they are being used, becoming a great way to get a bigger picture of the server as well as to prevent configuration locking violations and many other uses.
Locking - Allows you to do advanced locking such as locking specific attributes so that they cannot be used in deeper locations, lock individual items in a collection or lock the entire section, etc.

Please give us feedback on things you would like to see or change at the IIS Forums: http://forums.iis.net/1149.aspx

OK, but rather than keep with more and more text, I will just show you a video on how it looks and all its features (for those of you who like text, there is a transcript below).

Transcript:

So I have here Windows Vista SP 1 with the IIS Admin Pack installed, in my machine I have very few applications installed but should be good to show some of the features on config editor. When entering Config Editor, first thing you will notice is that at the top you have a drop-down list that shows all the sections currently schematized and ready to be used in your system.

Since this is sorted alphabetically, the first section that gets selected is AppSettings, for I can very easily switch between ASP.NET configuration sections, such as system.web/authentication, or the IIS configuration sections such as system.webServer/defaultDocument or the system.applicationHost/sites that contains all the sites configuration for IIS.

As you can see the user interface displays the configuration elements and properties of the section that is selected, providing you an easy way to see every single configuration property available in the system.

At the top you'll get a label specifying the deepest path where this section is being used relevant to your scope, so in this case its telling us that its been set in ApplicationHost.config. After that, all the elements and properties are shown in a Property Grid, that displaye elements as a collapsible set of properties. One of the interesting things is that we provide validation for the properties for example, when entering string characters in a numeric property type an error message will be displayed giving you the details of the expected types. Additionaly other benefits such as type editors, so that when editing a property of type boolean, you get the True/False drop-down, or when a property that is of type enumeration such as the LogFormat inside the SiteDefaults, you will get a drop-down list with only the list of options that are allowed for that enumeration. Same way, when editing a property of type flags such as the logExtFileFlags that contains the fields to include in the log file, you will get a multi-select drop-down list where you can select and de-select the different options. Also, you will notice that additional information is displayed as you select the different properties, giving you details of their data type as well as additional validations for those that have some, for example, the truncateSize property has specified that only a certain range is considered valid, if I type a value that is not within that range it will show this message giving me details of the problem.

Making Changes

Now, lets move to a simpler section so that we can show other features of the Configuration Editor. For example here in default documents, if I want to disable it I just change it to False and click Apply. As you would expect all the changes are applied and to see what changes this actually made in my system I'm going to show a Diff of the configuration that I have backed up and indeed the only change that happened in my configuration system is that it changed from true to false.

Collection Editor

As you will notice there is a collection in this section, all the collections are shown in an advanced collection editor that will let you see all the information of the items on it, including the ability to add, remove and clear the collection, as well as lock individual items on it. It additionally shows where each of the individual items is coming from making it easier to understand the distributed configuration.

Another thing you will notice is that this collection editor shows some visual cues to help you deal with data, for example this little key here tells you that this property is the unique key of the collection item.

So lets actually add a new one, for that I just need to click Add and fill the values, in this case, lets add Home.aspx as a new default document. After doing that, I can close dialog and click Apply. And lets take a look at what happened to my configuration. As you can see the new item was added. So as you can see its really easy to see and change configuration in collections.

Script Generation

Now, one of the interesting things that it also has is those changes that I just did, its great but sometimes I dont want to apply them immediately but instead automate them so that I can apply them at a later time. For example, lets just change the attribute Enabled back to true, and rather than just applying the change as we did before, I want to generate the script cause probably I'm creating a provisioning script for my site and I want to include this as part of it, so just by clicking Generate Script I get this dialog that gives you the code for Managed Code using Microsoft.Web.Administration in C#, and as you can see its quite easy to read. It also gives you JavaScript code that uses a COM library that our configuration system ships called Microsoft.ApplicationHost, and just as the managed code version it just sets the value. It also gives you command line for it, so you dont need to build code or scripts, you can just run the command line and to prove that, lets actually just run this command line. First lets show the diff again so that we see that its set to false. Now lets run the command line AppCmd which lives in Inetsrv directory. Now lets show the difference again, and as you can see it actually sets the value as expected. As you can see this will help you write scripts or code to manipulate IIS and ASP.NET settings without requiring additional knowledge.

Locking

Another interesting feature is locking, for example if I want to make sure that my default documents are always enabled and no one else can override them, I can go here and select the enabled attribute and click lock attribute which will prevent it from being changed in any other web.config file.

Search Configuration

Now, another interesting feature which is probably one of the most powerful features is the ability to search configuration so that you can see a high-level overview of the configuration system and all the web.config files on it. Just click Search Configuration. This shows me this dialog that shows me the root web.config that includes all the section that are being set on it, it also shows me applicationHost.config that includes again all the sections being used on it, as well as a location tag for a particular application that includes also some sections for it. you will notice that I also have a couple of applications that include web.config's in their folders, and sub-folders. where we can see how for example in this web.config it includes some

one of the neat features is that you can actually click any of this nodes and it will immediately display the content of the section as well as where its coming from. For example if I click the web.config my entire web.config is displayed, if I click a specific section it only displays the content of the section. I can even click the locationPath that I'm interested and only get that particular one.

Additionally you can easily search who is changing the authorization settings from asp.net and as easy as that you can see all the places in your server where the authorization settings are being set and quickly identify all the settings that are being used in your server. This feature is extremely useful because now, you can easily search for example default Document and make sure nobody is changing it and make sure no one else is violating the locking we just did.

It also allows you to see the files in a flat view where it gives you all the different paths and files where each of them is coming from. You get the exact functionality, its just a different visual representation of the config.

Schema-Driven

Another interesting thing is that if you want to build your own sections and extend our configuration system, you can go to the schema folder and write your own configuration section, declare it using our schema notation, here I'm just defining a section named mySection, that includes an attribute called enabled of type bool and an attribute called message of type string and an attribute password of type string that should be encrypted.. Now, I just need to edit applicationHost.config to define the section so that config system knows we are going to consume it . Just by doing that, now I can go back to config editor and refresh the window, and my section is now available in the drop down, and as you would expect it displays all of the properties I defined, and I can just go ahead and set them, and I get all the locking functionality, I get all the script generation, I get all the UI validation.

And if I apply, you will see that as expected the changes are done, the password attribute is encrypted, etc.

So as you can see configuration editor is an extremely powerful feature that will be really useful for successfully managing the web.config's in your system.

IIS 7.0 Admin Pack: Request Filtering

CarlosAg — Mon, 24 Mar 2008 17:00:00 GMT

My last post talked about the Technical Preview release of the IIS 7.0 Admin Pack, and how it includes 7 new features that will help you manage your IIS 7.0.

Today I was going to start writing about more details about each feature and Bill Staples just posted something (How to (un)block directories with IIS7 web.config) that almost seems that it was planned for me to introduce one of the features in the Admin Pack, namely Request Filtering UI.

IIS 7.0 includes a feature called Request Filtering that provides additional capabilities to secure your web server, for example it will let you filter requests that are double escaped, or filter requests that are using certain HTTP Verbs, or even block requests to specific "folders", etc. I will not go into the details on this functionality, if you want to learn more about it you can see the Request Filtering articles over http://learn.iis.net

In his blog Bill mentions how you can easily configure Request Filtering using any text editor, such as notepad, and edit the web.config manually. That was required since we did not ship UI within IIS Manager for it due to time constraints and other things. But now as part of the Admin Pack we are releasing UI for managing the Request Filtering settings.

Following what Bill just showed in his blog, this is the way you would do it using the new UI instead.

1) Install IIS Admin Pack (Technical Preview)

2) Launch IIS Manager

3) Drill down using the Tree View to the site or application you want to change the settings for.

4) Enter into the new feature called Request Filtering inside the IIS category

5) Select the Hidden Segments and choose "Add Hidden Segment" from the Task List on the right

6) Add the item

As you would expect the outcome is exactly as Bill explained in his blog, just an entry within you web.config, something like:

    <system.webServer>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <add segment="log" />
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>

So as you can see the Request Filtering UI will help you discover some of the nice security settings that IIS 7.0 has. The following images show some of the additional settings you can configure, such as Verbs, Headers, URL Sequences, URL Length, Quey String size, etc.

Search your configuration sections in web.config files using IIS 7.0 API's

CarlosAg — Wed, 19 Mar 2008 03:05:00 GMT

Background

In IIS 7.0 we have the great functionality to allow you to configure the Web Server settings in a distributed way, including the IIS configuration along with the ASP.NET configuration in the web.config files by using Configuration Sections. For example, the following shows a web.config adding a default document (home.aspx) to a Web Application inside my Default Web Site:

Now, that is great but it does come with a price, specially for server administrators it means that now you need to deal with a distributed configuration environment where certain settings are applied at the server level and certain settings are applied along with the application or even folders.

Another interesting challenge is that given the nature of distributed configuration, we've added the functionality to lock certain configuration sections so that they can only be set by a server administrator. Again this is good, however before the server administrator locks any section in order to prevent breaking applications they should search configuration and see if anyone is using that configuration section underneath.

Searching Configuration

The IIS 7.0 configuration system has a not so well-known feature that allows you to "query" the configuration system to get an overview of the configuration files in the system as well as the configuration sections that are used in each of them. This feature is implemented as a magical section called configPaths, that has the following schema:

How to use it

One thing that is pretty cool is that you can consume this section from all of our tools, including a command line (AppCmd.exe), a script (such as vbscript or javascript using Microsoft.ApplicationHost.AdminManager), or using Managed Code (Microsoft.Web.Administration) including the ability to use it under PowerShell. For this exercise we will only use Microsoft.Web.Administration, but the concepts are exactly the same in the other tools.

In its simplest form you can use the following function to display all the configuration files in your server as well as the sections included on them (just add a reference to Windows\System32\Inetsrv\Microsoft.Web.Administration.dll):

    /// <summary>
    /// Displays the list of configuration files as well as the
    ///     sections being used in each file
    /// </summary>
    private static void DisplaySections() {
        using (ServerManager serverManager = new ServerManager()) {
            Configuration appHost = serverManager.GetApplicationHostConfiguration();
            ConfigurationSection configPaths = appHost.GetSection("configPaths");

            foreach (ConfigurationElement configPath in configPaths.GetCollection()) {
                string path = (string)configPath["path"];
                string locationPath = (string)configPath["locationPath"];

                Console.WriteLine();

                Console.WriteLine("Config Path:" + path);
                if (!String.IsNullOrEmpty(locationPath)) {
                    Console.WriteLine(" <locationPath path=" + locationPath + "'>");
                }

                foreach (ConfigurationElement section in configPath.GetCollection()) {
                    Console.WriteLine("    " + section["name"]);
                }
            }
        }
    }

An example result of running this is:

Config Path:MACHINE/WEBROOT/APPHOST
    system.applicationHost/applicationPools
    system.webServer/defaultDocument
    system.webServer/ImageCopyright
    system.applicationHost/sites
    system.webServer/security/authentication/windowsAuthentication
    system.webServer/tracing/traceProviderDefinitions
    ...

Config Path:MACHINE/WEBROOT/APPHOST
  <locationPath="Default Web Site/BlogApp">
    system.webServer/security/authentication/windowsAuthentication

Config Path:MACHINE/WEBROOT/APPHOST
  <locationPath path="Default Web Site/aspnet_client">
    system.webServer/directoryBrowse
    system.webServer/handlers

Config Path:MACHINE/WEBROOT/APPHOST
  <locationPath path="Site2/aspnet_client">
    system.webServer/directoryBrowser
    system.webServer/handlers
    system.webServer/defaultDocument

Config Path:MACHINE/WEBROOT/APPHOST
  <locationPath path="Default Web Site">
    system.webServer/security/authentication/anonymousAuthentication
    system.webServer/directoryBrowse
    system.webServer/security/authentication/windowsAuthentication

Config Path:MACHINE/WEBROOT/APPHOST/Default Web Site
    appSettings
...

This tells us that in ApplicationHost.config we have a lot of sections begin used including applicationPools and many more.

Now, lets focus on the last two set of entries, the one with "MACHINE/WEBROOT/APPHOST" with locationPath set to "Default Web Site" tells us that anonymousAuthentication was used as well as windowAuthentication. The locationPath basically tells the configuration that even though this is set in ApplicationHost.config this configuration should only be applied to Default Web Site and its children. The next entry with path "MACHINE/WEBROOT/APPHOST/Default Web Site", basiclally tells you that in the Web.config inside the Default Web Site (in other words in c:\inetpub\wwwroot\web.config) the section appSettings is being used.

Now, what is interesting is that this is walking the entire server to find configuration files and do a lot of processing, however if you already know that you only want to search within a Site, or a particular application, then you can scope it down by using the GetWebConfiguration() method instead and this will give you only the configuration sections that apply for that site or application. Note that this will also report the sections that are specifically set for that object inside ApplicationHost.config making it much more than just a "findstr" inside the site folder and their virtual directories.

    DisplaySectionsForSite("Default Web Site");

    private static void DisplaySectionsForSite(string siteName) {
        using (ServerManager serverManager = new ServerManager()) {
            Configuration appHost = serverManager.GetWebConfiguration(siteName);
            ConfigurationSection configPaths = appHost.GetSection("configPaths");

            foreach (ConfigurationElement configPath in configPaths.GetCollection()) {
                string path = (string)configPath["path"];
                string locationPath = (string)configPath["locationPath"];

                Console.WriteLine();

                Console.WriteLine("Config Path:" + path);
                if (!String.IsNullOrEmpty(locationPath)) {
                    Console.WriteLine(" <locationPath path=" + locationPath + "'>");
                }

                foreach (ConfigurationElement section in configPath.GetCollection()) {
                    Console.WriteLine("    " + section["name"]);
                }
            }
        }
    }

PowerShell

Now, lets look at other examples, lets consider that we are a server administrator and I want to lock the defaultDocument section, but as a good citizen I first want to see if I would be breaking any application in my entire server if I do this. Just for fun lets do this using PowerShell instead, to test this just copy the entire code below and paste in inside an elevated PowerShell window.

$sectionToLookFor = "*defaultdocument*"

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration")
$iis = new-object Microsoft.Web.Administration.ServerManager

$configPaths = $iis.GetApplicationHostConfiguration().GetSection("configPaths").GetCollection()

foreach($path in $configPaths.GetCollection()) {
foreach($section in $path.GetCollection()) {
    if ($section.GetAttributeValue("name") -like $sectionToLookFor) {
      write ($path.GetAttributeValue("path") + " LocationPath:" + $path.GetAttributeValue("locationPath"))
      write ("    " + $section.GetAttributeValue("name"))
    }
}
}

The result in my machine gives you something like follows:

MACHINE/WEBROOT/APPHOST
    system.webServer/defaultDocument
MACHINE/WEBROOT/APPHOST/Default Web Site/aspnet_client
    system.webServer/defaultDocument
MACHINE/WEBROOT/APPHOST/Site2/aspnet_client
    system.webServer/defaultDocument

This tells us that inside the c:\inetpub\wwwroot\aspnet_client\web.config file we are actually using that section so if we end up locking this in the server we would break that application.

Summary

The configPaths section is a very useful section that allows you to search configuration files and the configuration sections being used in each of them, making it an invaluable tool for scenarios like understanding the configuration usage as well as locking and many others.

Using Microsoft.Web.Administration in Windows PowerShell

CarlosAg — Mon, 11 Feb 2008 03:53:00 GMT

A couple of months ago I wrote about using LINQ with Microsoft.Web.Administration to manage and query IIS 7.0 configuration. Somebody came back to me and said that LINQ was very cool but that it was very much Developer oriented and that in a production server without VS or .NET 3.5 it wouldn't be an option. Indeed that is a very valid comment and so I decided to show similar stuff with a tool that is available in Windows and its more IT oriented, Windows PowerShell.

So in this blog I will quickly mention some of the things you can easily do with Microsoft.Web.Administration inside Windows PowerShell.

To start working with Microsoft.Web.Administration the first thing you need to do is load the assembly so that you can start using it. It is quite easy using the methods from the Assembly type.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration")

Once you have the assembly available then you will need to create an instance of our ServerManager class that gives you access to the entire configuration system.

$iis = new-object Microsoft.Web.Administration.ServerManager

The above line basically declares a variable called $iis that we will be able to use for all of our configuration tasks.

Now to more interesting stuff.

Getting the list of Sites

Getting the list of sites is as easy as just accessing the Sites collection, this will output all the information about sites

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.sites
ApplicationDefaults : Microsoft.Web.Administration.ApplicationDefaults
Applications : {DefaultAppPool, DefaultAppPool, DefaultAppPool, DefaultAppPool...}
Bindings : {}
Id : 1
Limits : Microsoft.Web.Administration.SiteLimits
LogFile : Microsoft.Web.Administration.SiteLogFile
Name : Default Web Site
ServerAutoStart : True
State : Started

However, we can also specify the information we care and the format we want to use, for example:

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.sites | select-object Id, Name, State
Id Name State
-- ---- -----
1 Default Web Site Started
2 Site2 Started
3 Site3 Started

You can also use the where-object command to filter objects to get only the sites that are Stopped, and then we want to Start them.

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.sites | where-object {$_.State -eq "Stopped"} | foreach-object { $_.Start() }

OK, now let's imagine I want to find all the applications that are configured to run in the Default ApplicationPool and move them to run in my NewAppPool. This is better to do it in three lines:

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.sites | foreach {
$_.Applications | where { $_.ApplicationPoolName -eq 'DefaultAppPool' } |
foreach { $_.ApplicationPoolName = 'NewAppPool' }
}
PS C:\ > $iis.CommitChanges()

Now let's say I want to find the top 20 distinct URL's of all the requests running in all my worker processes that has taken more than 1 second.

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.WorkerProcesses | foreach {
$_.GetRequests(1000) | sort TimeElapsed -descending |
select-object Url -unique -first 20 }

OK, finally let's say I want to display a table of all the applications running under DefaultAppPool and display if Anonymous authentication is enabled or not. (Now this one is almost on the edge of "you should do it differently, but it is Ok if you are only reading a single value from the section):

PS C:\ > $iis = new-object Microsoft.Web.Administration.ServerManager
PS C:\ > $iis.Sites | foreach {
$_.Applications | where { $_.ApplicationPoolName -eq 'DefaultAppPool' } |
select-object Path,@{Name="AnonymousEnabled"; Expression = {
$_.GetWebConfiguration().GetSection("system.webServer/security/authentication/anonymousAuthentication").GetAttributeValue("enabled")
}}
}

Again, the interesting thing is that now you can access all the functionality from M.W.A. from Windows PowerShell very easily without the need of compiling code or anything else. It does take some time to get used to the syntax, but once you do it you can do very fancy stuff.

Backgammon and Connect4 for Windows Mobile

CarlosAg — Sun, 06 Jan 2008 21:00:00 GMT

During the holidays my wife and I went back to visit our families in Mexico City where we are originally from. Again, during the flights I had enough spare time to build a couple of my favorite games, Backgammon and Connect4.

I've already built both games for Windows using Visual Basic 5 almost 11 years ago but as you would imagine I was far from feeling proud of the implementation. So this time I started from scratch and ended up with what I think are better versions of them (still not the best code, but pretty decent for just a few hours of coding). In fact the AI for the Backgammon version is a bit better and the Connect4 is faster and more suited for a Mobile device.

You can go with your PDA/Smartphone to http://www.carlosag.net/mobile/ to install both games or just click the images below to take you to the install page of each of them. Enjoy and feel free to add any feedback/features as comments to this blog post.

The one thing I learned during the development of these versions is that you do want to download the Windows Mobile 6 SDK if you are going to target that version (which is what my cell phone has), since it will add new Visual Studio 2005 Project Templates and new Emulator images which will help you a lot. For example I was trying to use buttons in my forms, and testing it in Pocket PC worked, but as soon as I tried them in my cell phone it crashed with a NotSupportedException. When I installed the SDK and switched to target that platform, Visual Studio immediately warned me that my platform didn't supported buttons which was great.

Bottom line I'm more and more amazed of how easy it is to build games in Windows Mobile and the things you can achieve with both Windows Mobile and the .NET Compact Framework.

Sudoku and Tetris Game for Windows Mobile

CarlosAg — Fri, 21 Dec 2007 21:20:00 GMT

During my last two business trips (to Barcelona for TechEd and Mexico for ReMix) I was way too bored on the plane and since I recently got my Motorola Q9 (which is a sweet Windows Mobile Phone) decided to write myself a Tetris game and to port my Sudoku game to Windows Mobile as a way to do my "first steps" in the .NET Compact Framework.

To my surprise it was really easy to write them and even more to port the desktop version of Sudoku to run in all the .NET Compact Framework platforms.

Since holidays are coming I thought of share them as a gift for this holiday's season.

Bottom line (with the risk of sounding like a marketing dude, which I'm not) .NET is a cool technology that makes it really easy to code for many devices, from high-end servers to hand held devices to mobile phones. In this case, I have tested these applications with a Pocket PC, Smartphone 2003, Windows Mobile 5 and Windows Mobile 6. And best of all, the code base is pretty much the same as the Desktop version.

You can install both games by browsing from your mobile device to http://www.carlosag.net/mobile/ where you will find instructions on how to install the .cab files, or just click the images below to go to the download page for each game.

Happy holidays!

Using LINQ with Microsoft.Web.Administration

CarlosAg — Thu, 25 Oct 2007 02:32:00 GMT

With the upcoming release of .NET 3.5 and LINQ I thought it would be interesting to show some of the cool things you can do with IIS 7 and LINQ. Everything that I will do can be done with C# 2.0 code but it would take me several lines of code to write them but thanks to LINQ you can do them in about a line or two.

Let's start with a very basic example that does not use LINQ but just M.W.A (Microsoft.Web.Administration) and then start adding interesting things to it.

The following code just iterates the sites in IIS and displays their name.

using System;
using System.Linq;
using Microsoft.Web.Administration;
class Program {
    static void Main(string[] args) {
        using (ServerManager serverManager = new ServerManager()) {

            var sites = serverManager.Sites;
            foreach (Site site in sites) {
                Console.WriteLine(site.Name);
            }
        }
    }
}

Now, let's say I wanted to have them sorted by their name. This is where LINQ starts being useful

    using (ServerManager serverManager = new ServerManager()) {

        var sites = (from site in serverManager.Sites
            orderby site.Name
            select site);

        foreach (Site site in sites) {
            Console.WriteLine(site.Name);
        }
    }

Say you want to start all the sites that are stopped:

    using (ServerManager serverManager = new ServerManager()) {

        var sites = (from site in serverManager.Sites
            where site.State == ObjectState.Stopped
            orderby site.Name
            select site);

        foreach (Site site in sites) {
            site.Start();
        }
    }

OK, now let's imagine I want to find all the applications that are configured to run in the Default ApplicationPool and move them to run in my NewAppPool. This would take me a lot more lines of code but now I can just do:

    using (ServerManager serverManager = new ServerManager()) {

        var apps = (from site in serverManager.Sites
            from app in site.Applications
            where app.ApplicationPoolName.Equals("DefaultAppPool", StringComparison.OrdinalIgnoreCase)
            select app);

        foreach (Application app in apps) {
            app.ApplicationPoolName = "NewAppPool";
        }

        serverManager.CommitChanges();
    }

Now let's say I want to find the top 20 distinct URL's of all the requests running in all my worker processes that has taken more than 1 second.

    using (ServerManager serverManager = new ServerManager()) {

        var requests = (
            from wp in serverManager.WorkerProcesses
            from request in wp.GetRequests(1000)
            orderby request.TimeElapsed descending
            select request).Distinct().Take(20);

        foreach (Request request in requests) {
            Console.WriteLine(request.Url);
    }
}

    using (ServerManager serverManager = new ServerManager()) {

        var items = from site in serverManager.Sites
            from app in site.Applications
            where app.ApplicationPoolName.Equals("DefaultAppPool", StringComparison.OrdinalIgnoreCase)
            orderby site.Name, app.Path
            select new {
                Site = site,
                Application = app,
                AnoymousEnabled = ((bool)app.GetWebConfiguration().GetSection("system.webServer/security/authentication/anonymousAuthentication")["enabled"])
            };

        foreach (var item in items) {
            Console.WriteLine("Site:{0,-18} App:{1, -10} Anonymous Enabled:{2}",
                item.Site.Name, item.Application.Path, item.AnoymousEnabled);
        }
    }

As you can see LINQ is an incredibly useful feature in C# 3.0 and in conjunction with Microsoft.Web.Administration allows you to do incredibly complex operations in IIS with just few lines of code.

The new Configuration System in IIS 7

CarlosAg — Tue, 25 Apr 2006 23:48:00 GMT

Today I was planning on talking about the configuration classes that I purposedly skipped in my last post, but I realized it would be better to explain a little bit more about the new configuration system used in IIS 7.

First of all, many of you (as me) will be extremely happy to know that the old "monolithic-centralized-admin only" metabase is dead, we have got rid of it for a much better configuration store. Now, before you feel panic, let me assure you that we haven’t just killed it and forget about the thousands of lines of scripts or custom tools built using the old metabase API’s (such as ABO), for that we have created something we called ABOMapper which will allow all of those applications to keep running transparently, since it will auto-magically translate the old calls to the metabase to actually modify the new configuration system.

So what is this new configuration system? Well for those of you who have been working with ASP.NET for the past years, you will feel right at home and happy to know that we are moving to used the exact same concept as ASP.NET does .config files.

ApplicationHost.config

At the root level we have a file called ApplicationHost.config that lives in the same directory of IIS (typically <windows>\System32\InetSrv\ directory). This is the main configuration file for IIS, this is where we store things like the list of sites, applications, virtual directories, general settings, logging, caching, etc.

This file has two main groups of settings:

system.applicationHost: Contains all the settings for the activation service, basically things like the list of application pools, the logging settings, the listeners and the sites. These settings are centralized and can only be defined within applicationHost.config.
system.webServer: Contains all the settings for the Web server, such as the list of modules and isapi filters, asp, cgi and others. These settings can be set in applicationHost.config as well as any web.config (provided the Override Mode settings are set to allow)

Administration.config

This is also a file located in the IIS directory where we store delegation settings for the UI, including the list of modules (think of it as a UI Add-in) available, and other things like administrators.

Web.config

Finally the same old web.config from asp.net has gotten smarter and now you will be able to include server settings along with your asp.net settings.

Why is this important?

Well, as I said at the beginning the old metabase could only be accessed by administrators, so in order for someone to change a settings as simple as the default document for a specific application (say you want to change it to be index.aspx), you would need to be an administrator or call the administrator to do the changes.
With this new distributed configuration system I can now safely modify the web.config within my application and have it my own way without disturbing anyone else. Furthermore, since it lives in my own web.config along with the content of my application I can safely XCopy the whole application and now even the web server settings are ready. No longer the case of going to InetMgr and start setting everything manually or creating a bunch of scripts to do that.

So how does this actually looks like:

In applicationHost.config my Sites section looks as follows:

This basically defines a site that has a root application with a virtual directory that points to \inetpub\wwwroot. This site is listening on any IP address on port 80.
Say I wanted to add a new application and make it listen also in port 8080.

Just by adding the previous markup, I can now browse to http://localhost:8080/MyApp
IIS Settings in web.config
More interesting I can now add a file called web.config to c:\MyApp\web.config, and set the content to be:

And with this change, my application now will respond using index.aspx whenever /MyApp is requested.
You can extrapolate from this that all the IIS settings for your application including authentication, authorization, asp and cgi settings, the list of modules, custom errors, etc can be configured within your web.config and never have to request changes to administrators again.

Of course this brings the question, isn’t this insecure? The answer is no, by default all the IIS sections (except DefaultDocuments) is locked at the applicationHost.config, meaning no one can change them within their web.config unless explicitly changed by the administrator. The cool thing is that the administrator can change it and customize it per application allowing certain apps to change settings while preventing others from doing it. All this can be done through plain config using Notepad or using the very cool NEW InetMgr (which I will blog about it later)
Finally, the following image shows the hierarchy of config files for each url.

Now that I have shown a high level overview of how configuration works in IIS 7, I will finally blog about the API to actually change this settings programmatically using Managed code and Microsoft.Web.Administration.dll

Microsoft.Web.Administration in IIS 7

CarlosAg — Mon, 17 Apr 2006 08:56:00 GMT

While creating the new administration stack in IIS 7, we were looking into the different ways users could manipulate the server configuration as well as the new runtime information available in IIS 7 (Internally we call this RSCA-Runtime State and Control API) from managed code, and we realized we needed to provide a simpler and more straight forward API that developers could consume from managed code. Microsoft.Web.Administration is the answer to this problem. This API is designed to be simple to code against in an “intellisense-driven” sort of way. At the root level a class called ServerManager exposes all the functionality you will need.

To show the power and simplicity of this API, let’s look at some samples below. To try this samples just create a new Console Application in Visual Studio and add a reference to Microsoft.Web.Administration.dll that can be found at IIS directory (%WinDir%\System32\InetSrv).
Please note that the following code is based on Windows Vista Beta 2 code and will likely change for the release candidate versions of Windows Vista since we have planned several enhancements to simplify the API and expose more features into it.
The following picture shows the main objects (excluding Configuration related classes).

Creating a Site

ServerManager iisManager = new ServerManager();
iisManager.Sites.Add("NewSite", "http", "*:8080:", "d:\\MySite");
iisManager.Update();

This basically creates an instance of the ServerManager class and uses the Add method in the Sites collection to create a new site named "NewSite" listening at port 8080 using http protocol and content files are at d:\MySite.
One thing to note is that calling Update is a requirement since that is the moment when we persist the changes to the configuration store.
After running this code you have now a site that you can browse using http://localhost:8080

Adding an Application to a site

ServerManager iisManager = new ServerManager();
iisManager.Sites["NewSite"].Applications.Add("/Sales", "d:\\MyApp");
iisManager.Update();

This sample uses the Sites collection Indexer to get NewSite site and uses the Applications collection to add a new http://localhost:8080/Sales application.

Creating a Virtual Directory

ServerManager iisManager = new ServerManager();
Application app = iisManager.Sites["NewSite"].Applications["/Sales"];
app.VirtualDirectories.Add("/VDir", "d:\\MyVDir");
iisManager.Update();

Runtime State and Control

Now, moving on to the new Runtime state and control information we also expose in this objects information about their current state as well as the ability to modify them. For example, we expose the list of W3WP processes running (Worker processes) and what I think is really cool, we even expose the list of requests currently running. Stopping a Web Site

ServerManager iisManager = new ServerManager();
iisManager.Sites["NewSite"].Stop();

Recyciling an Application Pool

ServerManager iisManager = new ServerManager();
iisManager.ApplicationPools["DefaultAppPool"].Recycle();

Getting the list of executing requests

ServerManager iisManager = new ServerManager();
foreach(WorkerProcess w3wp in iisManager.WorkerProcesses) {
    Console.WriteLine("W3WP ({0})", w3wp.ProcessId);

    foreach (Request request in w3wp.GetRequests(0)) {
        Console.WriteLine("{0} - {1},{2},{3}",
                    request.Url,
                    request.ClientIPAddr,
                    request.TimeElapsed,
                    request.TimeInState);
    }
}

Another big thing on this API is the ability to edit the “.config” files using a simple API, this includes the ability of modifying the main applicationHost.config file from IIS, web.config files from asp.net as well as machine.config and other config files (such as administration.config). However I will talk about them in a future post.