Early spring cleaning

So I was cleaning out my desk and found something that I would have blogged about had I had a blog when it happened :)

People tend to think of me as a BizTalk guy - but before that I was really an ASP and then ASP.NET guy.  On one of the early ASP.NET mailing lists Scott Guthrie challenged us to write an application that hosted ASP.NET outside of IIS (this of course if now all documented - but it wasn't at the time).  I was the first (or one of the first) people to do this (the only thing I remember is having to use PInvoke and LoadLibrary to load the aspnet_isapi.dll into the process for stuff to work) and he sent me a hat (which I still have somewhere) and a signed .NET Framework CD.  Fun days.

Also funny that my next post will likely be able hosting ASP.NET outside of IIS.

ASP.NET       Comments [0]   

Using WCF WebHttpBinding and WebGet with nicer Urls

I've been playing with the REST support in .NET 3.5.  I'm really enjoying the programming model, but I am not enjoying the .svc file extension in my URLs (I'm not the only person I know who has felt this way for quite some time).

IMO (from what little I know about the REST style) URLs shouldn't have things like extensions in them (or preferably not).  So with they way WCF endpoint hosting in IIS works (obviously if I am hosting a webHttpBinding in a non-IIS host I can totally control the URLs, but I am writing a REST API to something where I plan to be hosting inside of IIS).  This would end up being my url:

http://host/albumn.svc/instance/

and I want:

http://host/albumn/instance/

The .svc extension in the URL doesn't seem opaque to me.  I tried modifying the HttpHandler element for the svc file - but that didn't work for various reasons.  So I ended up writing a simple HttpModule to do URL re-writing (using HttpContext.RewritePath).  I didn't really want any config relating to URLs - so this module assumes you are serving up only REST based URLs from a web application.  If you were going to use it and serve up other handlers (like aspx files etc) it would need to be modified. Here is the module code:

public class RestModule : IHttpModule
{


public void Dispose()
{ }

public void Init(HttpApplication app)
{
app.BeginRequest += delegate
{
HttpContext ctx = HttpContext.Current;
string path = ctx.Request.AppRelativeCurrentExecutionFilePath;

int i = path.IndexOf('/', 2);
if(i>0)
{
string svc = path.Substring(0, i) + ".svc";
string rest = path.Substring(i, path.Length - i);
ctx.RewritePath(svc, rest, ctx.Request.QueryString.ToString(), false);
}
};

}


}

After configuring this in my web.config - I have the ability to type:

http://localhost/RestTest/Service2/Test?id=9999

and the module will translate it to Service2.svc as the handler file - which makes WCF happy.

If you are interested you can download the code here:

RestTest.zip (3.71 KB)

EDIT:  Christian pointed out that this approach alone will not work in IIS6 (my approach is for integrated mode of IIS7).  For IIS you have to add aspnet_isapi.dll to the Wildard Application Maps.  But then he goes on to tell me no one will do that .  So I say - good reason to move to IIS7 and Longhorn/Windows 2008 - since it has a go-live license.

ASP.NET | WCF       Comments [5]   

How I spend my Sunday afternoon - playing with Atlas

So before I spent all my time playing with BizTalk and Windows Workflow Foundation (WF) - I used to do quite a bit of ASP.NET (there are even a few old ASP.NET posts laying around on my blog :)).

Before that of course I used to do ASP/COM.  I joke that I started learning about and teaching AJAX back in 1999 (thanks to the brilliance of John Lam ).

I looked at Atlas a little last fall, but never got into it very deeply.  I decided to play with it over the weekend, and I have to say - I am really really impressed.  I decide to tackle what I thought would be a pretty interesting application - hosting the WF designer in an HTML only - AJAX based application.

I had already done the code to get images to be generated from the Workflow Designer on the server instead of hosting the designer in a browser as a control (see http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,28601754-c305-4597-a0a6-48f32be1eddb.aspx).

So I built a little teaser avi of the functionality.  Sorry no code yet - it needs some work before it is ready for public consumption - but even at this point I have to say I think it looks pretty cool .  I think building a real design app around it will be possible. 

So  you can download the avi of my Windows Workflow Foundation - AJAX based designer application built with Atlas  here - go ahead its only 411k .  I'd post images - but I've posted too many of them lately.  Hopefully I'll have time to get it done before TechEd next week. 

Anyone who is coming to TechEd - stop by the TLC Workflow booth - that is where I will be spending most of my time when not going to sessions or doing my session.  My session will be on Building Custom Activities with WF.  You can see the time here - http://www.msteched.com/content/sessions.aspx (you can find it by searching for Workflow - there are going to be a number of great talks you should attend if you are interested in learning more about WF).

ASP.NET | WF | Atlas       Comments [4]   

Seems to me

That not having the ability to add a Theme via  the Master Page in ASP.NET 2.0 (whidbey) is a big omission. Am I missing something?

ASP.NET | ASP.NET 2.0       Comments [0]   

OutputCache Substitution Weirdness

Substitution in ASP.NET 2.0 seems pretty cool.  You can designate part of a page as being substituted even when the rest of the page is being cached using the OutputCache directive.

Under the covers what is happening is a HttpResponseSubstitutionCallback delegate is getting wired up to each part of the page that you want to be dynamic when the rest of the page is being cached.  You can use either the Substitution control to do this for you or use inline code and call Response.WriteSubstitution.

The goofy thing about this though is that ASP.NET is trying to enforce that the target method of the delegate be static.  At first glance this seems pretty logical because if the target method is in a Page, then that Page instance would have to stay alive as long as the delegate stayed alive.

The problem with the implementation is that all it is doing is checking to see if Delegate.Target is of type control (which is will be if the HttpResponseSubstitutionCallback points to a instance method on a Page or other Control derived class).  I can create an instance of some other type and use one of its instance methods as the target method.  If my non-Control derived instance holds onto a reference to the HttpContext or the Page itself, the apparent reason to enforce static methods only is subverted.

Does anyone know why they don't check Delegate.Method.IsStatic instead?

ASP.NET | ASP.NET 2.0       Comments [0]