One of the things I try to regularly do is to read blogs that are not necessarily pro-Microsoft and one of my favorite ones is Miguel de Icaza's blog. The other day I was reading one blog post that caught my attention about a blog he says he is a "fan of" named "Linux Hater's blog". So of course I decided to give that a read and went and started reading the entries in there, and I just could not stop laughing and laughing, and before I noticed I had been reading for almost an hour. I do have to warn though, the vocabulary used is their entries is ...um... lets say fluid?.

Disclaimer: I'm not saying that their entries are right or wrong, I just literally couldn't stop laughing about some of the comments and their replies, and in some cases I do think they are a bit biased and in some cases they do have a good message that could help advance the software industry in general.

Anyway, if you want to read a very "funny-colorful-passionate" blog I think its worth a read: http://linuxhaters.blogspot.com/

DiscountASP.net published a very nice video that shows how you can enable IIS Manager and Database Manager and other modules for their customers.

If you don't use DiscountASP.net as your ISP at least its interesting to see how IIS 7.0 and its Remote Administration capabilities over HTTPS and Delegated Management look like. Also you can see the Database Manager in action that you can download for free from http://learn.iis.net/page.aspx/416/basics-of-database-manager/

First couple of minutes show how they expose this functionality to their customers, but If you just care to see the IIS 7.0 features running seek to minute 2:00.

http://iis7test.com/iis7_modules/iis7_modules.html

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)

Now if you have a sample page like the following:

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.

Today I read a question in one of the IIS.NET forums - although I'm not sure if this is what they really wanted to know - I figured it might be useful to understand how to do this anyway. Several times users does not like exposing their ASP.NET pages using the default .aspx file extension (sometimes because of legacy reasons, where they try to minimize the risk of generating broken links when moving from a different technology, to preserve the validity of previous search-engines-indexes and sometimes for the false sense of security or whatever).

Regardless of why, the bottom line, to map a different file extension so they behave just like any other ASP.NET page requires you to add a couple of entries in configuration, especially if you want those to be able to work in both Pipeline Modes "Classic and Integrated".

For this exercise lets assume you want to assign the file extension .IIS so that they get processed as ASPX pages and that you only want this to be applicable for Default Web Site and its applications.

The following Web.Config file will enable this to work for both Pipeline Modes:

The following command lines uses AppCmd.exe to enable this for both Pipeline Modes and basically generate the .config file above.

So what does this actually do?

Lets actually describe the AppCmd.exe lines since it breaks nicely the different operations.

1. Integrated Mode. When running in Integrated mode conceptually only the IIS Pipeline gets executed and not the ASP.NET pipeline, this means that the HttpHandlers section (in system.web) is actually not used at all.
1. So just by adding a new handler (ASPNETLikeHandler above) to the System.WebServer/Handlers will cause IIS to see this extension and correctly execute the page. Note that we use the preCondition attribute to tell IIS that this handler should only be used when we are running in an Integrated Pipeline Application Pool.
2. The second line only tells the ASP.NET compilation infrastructure how to deal with files with this extension so that it can compile it as needed.
2. Classic Mode. In classic mode the ASP.NET pipeline keeps running as previous versions of IIS as a simple ISAPI and the new IIS pipeline gets executed as well, this means that we first need to tell IIS to route the request to ASP.NET ISAPI and then we need to tell ASP.NET how to handle this extension as well by using the system.web/httpHandlers to process the request.
1. The first line adds a handler (ASPNETLikeHandler-Classic above) to IIS so that IIS correctly routes this request to the aspnet_isapi.dll. Note that in this case we also use the preCondition attribute to tell IIS that this only applies when running in an Application Pool in classic mode, furthermore we also use it to specify that it should only be used in an Application Pool running in 32 bit mode and that is using version 2.0 of the runtime. If you wanted to support also 64 bit application pools you would add another handler pointing to the 64bit version of aspnet_isapi.dll in Framework64 folder and use bitness64 instead.
2. The second line tells ASP.NET that the .iis extension is handled by the PageHandlerFactory, so that the ASP.NET pipeline understands what to do when a file with the .iis extension is requested.
3. Again, just as 2 in the Integrated Mode case we need to tell the ASP.NET compilation infrastructure how to deal with this extension.
4. Finally since we are adding a system.web/httpHandler entry and to make sure that this will not break when someone changes the App pool to integrated mode we tell IIS to "not complain" if we get run in Integrated mode since we also included the handler in the IIS sections in the right way.

Hopefully this helps understanding a bit how to re-map extensions to ASP.NET extensions, and in doing that learn a bit more about preConditions, Handlers and AppCmd.

DiscountASP.net who has been a very close partner of the IIS Team leading several offerings of our platform - including IIS Manager Remote Delegated Access to the Web Site and many other cool tools - has just built and released yet another cool module that extends the IIS Manager capabilities by having a GAC Viewer for their customers.

The GAC Viewer is still in Beta but I think it showcases some of the cool stuff that IIS 7.0 platform brings to the table providing extensibility from end-to-end, whether its Runtime, Configuration, IIS Manager, etc.

This is the way their GAC Viewer looks like:

And when you connect to their site and you don't have it installed our infrastructure will automatically download it as needed when the user accepts it:

Note that DiscountASP.net also offers other modules, including some of our recent modules like Database Manager, Request Filtering and others (I already had some of them installed and that is why it doesn't show in this list) and their own Web.config Backup and a Feedback Module.

All I can say is that it makes me extremely happy anytime I see someone take advantage of the platform in such interesting ways.

Keep up the good work!