Wednesday, 17 January 2007
Under ASP.NET 1.1, the ASP.NET engine is not (by default) responsible for the application's image, style sheet, and javascript files. These are served up directly by IIS. ASP.NET can be made responsible for these file types by playing with the ISAPI file mappings and maybe creating an HttpHandler or two.

This changes under ASP.NET 2.0.  The ASP.NET engine has responsibility for all these file types and is called when a request for one is made.

So what?  The files get served, the application works, who cares if IIS or ASP.NET does the work?

In many applications it wouldn't matter, but what happens if the application has been secured in web.config like so...

<authorization>
   <deny users="?" />
</authorization>

... and an anonymous user tries to access the site and gets redirected to the login page?

Under 1.1, since IIS was responsible for the css, javascript and image files, it wouldn't matter -- the page would be served as expected, showing all the images and properly referencing any stylesheets or script files.

Under 2.0, the anonymous user would see an unstyled page with blank image boxes. Any javascript calls to referenced files won't work either. Why? Because ASP.NET isn't going to serve up anything but the login page to an anonymous user -- because that is what it was told to do.

This is great for security, but can be a little frustrating when you KNOW you put the right path in for that image, and KNOW that the all h1 elements should be hot pink  and all you see is an unformatted mess.

Fortunately it is very easy to work around this so the public pages on a secured site show up properly.  All that needs to be done is to tell the application that anonymous users are allowed to access the content in certain folders. This can be done using a location element or two in the web.config file.  The following one allows anonymous users to access content in the unsecured_images folder...

<location path="unsecured_images">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

That's all there is to it.


Wednesday, 17 January 2007 22:29:44 (Eastern Standard Time, UTC-05:00)   #     Comments [1]  | 
Wednesday, 20 December 2006

Finally! .NET 2.0 has been out for a year.  Finally found the time to move our main application to 2.0. It's been a bit of an adventure.  There are 12 class libraries, 2 server control assemblies, a service, a web app and various utilities.  Two of the class libraries are in C++, one managed, one native. The truly insane can read about the little odyssey through those assemblies.  Everything else is written in VB.NET. 

The VB.NET class libraries converted easily.  The only issue was in the few classes that performed XSL Transformations where I had to change a couple of deprecated method calls.  These were no surprise.  Other than that there were only warnings for untyped functions or parameters (very naughty, and one of the dangers of working in VB with OPTION STRICT OFF) and a surprising number of unused local variables. 

The web application was a lot trickier than anticipated.  There are some fundamental differences between 1.1 and 2.0 web applications. One of the significant changes is in the coding model.  2.0 makes use of partial classes, so that a single class can be created from separate files, this cleans some things up.  There are no longer control declarations in the code-behind file, but it is a change. 

Here is a very handy resource that discusses most of the issues you will run into when converting from 1.1 to 2.0. 

In the standard out-of-the-box VS2005, the project file for web applications has also gone the way of the dodo, you create Web Site Projects.  Everything in the project tree gets put into the application. Fortunately, there is a feature to exclude files, which you will use. Since the Web Site Project includes ALL the files in the directory tree, files that you excluded in your 1.1 project will suddenly reappear like uncompilable ghosts in the 2.0 version. The other annoying "feature" is that these projects spew forth an assembly for every folder in your application, and couple of others for good measure, and the files are randomly named.  Hello deployment fun -- I'm sure there's good reason for this, but it is not intuitively obvious, it seems friggin' nutty.

This application model had been fine for the smaller projects I had converted, and I figured I would discover a way to deal with the assembly vomit, so I pushed on assuming that I was moments away from having a our application working in 2.0.

But it was not to be, this web application pushed the Web Site Project model over the cliff of despair.

The application has around 60 pages, 15 classes and 15 user controls spread amongst 10 directories. Most of the heavy lifting is done in the underlying libraries. I didn't think it was that large until I tried to compile it.  In VS 2003, it was up and running in under a minute, in VS2005 it was 5+ minutes, and the sucker was crashing every time I changed the base web page class that the pages inherited from.  I lived with this for about a day, googling while it compiled or restarted, toggling various settings, swearing and pruning previously exlcuded and unused pages ruthlessly. 

After one seemingly eternal cycle of rebooting, I seriously considered asking for a quad-core super box or retreating back to 1.1.  I decided to take one more look around the web for a solution and I stumbled across this article, which in turn led me to discover an alternate model to this lunancy, the Web Application Project! It was the old 1.1 compilation model, complete with a single assembly output -- hooray.  It required some VS update installations and yet another conversion from my original 1.1 application, but in a few hours I had a quickly compiling application.  Some testing and a small victory dance later, and it was time to start ripping out the facacta hand-rolled page templates and putting in the master pages!



Just a reminder kids, always use source code control, especially when undertaking a conversion.  It makes mistakes almost painless and recovery simple!


UPDATE:  MS has shipped the first service pack for VS 2005. This includes the Web Application Projects. If you have previously installed the Web Application update, you will have to uninstall it before installing the service pack.

Wednesday, 20 December 2006 23:04:59 (Eastern Standard Time, UTC-05:00)   #     Comments [0]  | 

Theme design by Dean Fiala

Pick a theme: