April, 2008

  • CarlosAg Blog

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


    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:

    1. 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.
    2. 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:

    1. Static Files Web Server - Supporting only static file downloads, good for HTML scenarios and other simple sites.
    2. Dynamic Web Sites
      1. ASPX Pages
      2. WCF
      3. Custom set of Http Modules and Handlers
    3. 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.


    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);
    Console.WriteLine("Server Started!... Press Enter to Shutdown");


    Console.WriteLine("Shutting down");

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. many, many more...

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


    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.

  • CarlosAg Blog

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


    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.

  • CarlosAg Blog

    IIS 7.0 Talk at ASP.NET Connections at Orlando


    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:

    1. First Demo: ApplicationHost.config, Web.config and Tools.
      1. Showed the Application Pools list and how Visual Studio 2008 now provides IntelliSense for all the configuration of IIS.
      2. Added a new Application Pool using Notepad, and IIS Manager shows it.
      3. Showed the Sites section and created a new /Temp Application to my c:\temp directory.
      4. 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.
      5. Created a new Web.config where I enabled system.webServer/directoryBrowse and showed how this immediately applied the changes.
      6. 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.
    2. Second Demo: Pipeline Mode and Application Migration
      1. Showed the Application Pools created by IIS, explained some of the differences in Classic Mode versus Integrated Mode.
      2. Showed how to create a new Application Pool and where to specifythe pipeline modes.
      3. 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>.
      4. Showed how assigning it to a Classic Mode immediately makes it run in the same way as before.
      5. 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.
      6. 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
    3. Third Demo: Leveraging the Integrated Pipeline
      1. 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.
      2. 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.
    4. Fourth Demo: Output Caching
      1. 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.
      2. Enabled Output Caching using IIS Manager for .aspx pages.
      3. 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.
    5. Fifth demo: Extensibility
      1. 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.
      2. 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 :)

  • CarlosAg Blog

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


    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";


    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,

Page 1 of 1 (4 items)