Aaron Lerch » asp.net

Rock the iPhone with ASP.NET MVC

aaron — Sun, 08 Jun 2008 23:30:06 +0000

With much fanfare Apple announced the availability of the iPhone SDK. I downloaded it and someday plan to play around with it, though with the SDK already having gone through 4 or 5 beta releases (each a ~2GB download) I’ll probably wait a long time before cracking it open. However, for web applications the best way to integrate with an iPhone is still through the browser.

Unfortunately Apple didn’t provide much help in the form of html or css to make your website “iPhone-y”. They provide documentation on elements like iPhone specific events (“onorientationchange”) and details about how Safari works on the iPhone in terms of zooming, etc., but nothing that offers guidance on how to make an application look like it belongs on the iPhone.

Enter Joe Hewitt and iUI. iUI takes HTML that follows a simple set of conventions and does all the heavy lifting to enable you to easily build a version of your site that is tailored for the iPhone experience. I first started using iUI before ASP.NET MVC was publicly introduced, and I specifically remember thinking how much iUI was built for “webforms unplugged“. Let’s take a quick look at an example of how iUI works, and how to use it with ASP.NET MVC.

If you’re the type that likes to get their hands dirty first, download the code here.

CSS Zen Garden

iUI is literally nothing more than some javascript, some css, and a bunch of image assets. It’s how things are supposed to work with HTML and it’s beautiful, like the CSS Zen Garden. It also has some simple conventions that I’ll summarize like so: “write HTML the way it was intended”.

for dialogs and pages. Easy enough, right? There’s not a ton to iUI but for this post I’ll start simple. Let’s create a list of products that we want to display like so:

This is the HTML behind the list itself (not including the top toolbar, though the “title” attribute of the list controls the text shown in the center of the toolbar):

<ul id="products" title="Products">
    <li><a href="/products/index/1">Alice Muttona>li>
    <li><a href="/products/index/2">Aniseed Syrupa>li>
    <li><a href="/products/index/3">Boston Crab Meata>li>
    <li><a href="/products/index/4">Camembert Pierrota>li>
    <li><a href="/products/index/5">Carnarvon Tigersa>li>
    <li><a href="/products/index/6">Chaia>li>
    <li><a href="/products/index/7">Changa>li>
    <li><a href="/products/index/8">Chartreuse vertea>li>
ul>

iUI does the heavy lifting to format the list in the iPhone style, and will dynamically load any linked content using an AJAX call and render it in-place, replacing the current list (“products”). iUI handles sliding in the new content from the right-hand side, just like a native iPhone application.

You could also reference another list defined within the same page, for example if you had a very short list of items and had each list item’s “linked content” also included in the page, like this:

<ul id="products" title="Products">
    <li><a href="#subproduct1">Product 1a>li>
ul>

<ul id="subproduct1" title="Related Products">
   <li>Sub Item 1li>
   <li>Sub Item 2li>
ul>

The Root Page

iUI will dynamically render partial content into the current view, but it needs an initial root page describing the main layout. The easiest way to figure out what is needed is to look at one of the examples that iUI includes, but in a nutshell you’ll probably need at least two elements: the toolbar (the heading) and some content. To support the example above of a product list, our entire root page could look like this:

DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Northwind Explorertitle>
    <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>
    <style type="text/css" media="screen">@import "../../Content/iui/iui.css";style>
    <script type="application/x-javascript" src="../../Content/iui/iui.js">script>
head>
<body>
    <div class="toolbar">
        <h1 id="pageTitle">h1>
        <a id="backButton" class="button" href="#">a>
    div>
    <ul id="products" title="Products" selected="true">
        <li><a href="/products/index/1">Alice Muttona>li>
        <li><a href="/products/index/2">Aniseed Syrupa>li>
        <li><a href="/products/index/3">Boston Crab Meata>li>
        <li><a href="/products/index/4">Camembert Pierrota>li>
        <li><a href="/products/index/5">Carnarvon Tigersa>li>
        <li><a href="/products/index/6">Chaia>li>
        <li><a href="/products/index/7">Changa>li>
        <li><a href="/products/index/8">Chartreuse vertea>li>
    ul>
body>
html>

The site will initially show the list of products, and when the user clicks on a product, the

… element will be wholesale replaced with the content loaded by an AJAX call to “/products/index/[number]”.

Hooking up iUI to MVC

First things first – download the latest iUI assets from the google code repository trunk. You’ll get the latest bug fixes and features, which I’ve found to be helpful. As a side note, you can view some samples directly from the repository itself – like the music example. Put the downloaded files in the Content directory:

Define your main page—the main entry point to the site. I chose /home/index in my example. This is where you’ll reference the iUI javascript and css assets, and define the initial structure of your page.

One big catch that I already mentioned with iUI is that it expects links (whether AJAX-loaded or in-page references) to return HTML fragments. It literally takes the results of an AJAX call to a given URL and sets the innerHTML of the content to replace.

This means that every other page in our application should return partial content. For example, when I click on “Products” this is the only content of the view page that lists the products:

As you can see, it’s simply building the list itself and rendering the partial HTML content as a response.

You can connect with an iPhone on your local network with a wifi connection, but it’s much easier to install and test with Safari for Windows. Both Safari for Windows and the iPhone’s mobile Safari use the WebKit engine so the rendering experience is about as close as you can get. Shrink the browser to approximately the size of the iPhone screen and you’d never know you didn’t spend the $400+ on an iPhone.

You can download the first version of my example project here.

Up Next

In future posts I’ll explore some more of iUI’s features such as adding a product page to view details of a product in a friendly way (I’ve included this in the example project already), rendering partial lists (allowing the user to expand the list incrementally), detecting the user agent and loading iPhone views vs. “normal” views, and more. I’ll update the example project as we go!

Automatic formatting of inline ASP.NET tags

aaron — Tue, 08 Apr 2008 05:26:08 +0000

I don’t know whether it’s Resharper and/or Visual Studio 2008 that messes up the auto-formatting of inline ASP.NET tags, but it sucks. I usually start "prettying" it up, but usually give up halfway through, because every time I add anything else, the formatting is shot again. Is it just me? Is there a setting I’m missing?

Testing TempData, and Mocking SessionState

aaron — Thu, 13 Mar 2008 00:07:10 +0000

About a month and a half ago Ben Scheirman wrote about testing TempData in ASP.NET MVC. It’s good stuff, and aside from changes between Preview 1 and Preview 2, it still works fine. (See Scott Hanselman’s post for some Preview 2-friendly mock helpers using Rhino Mocks.)

While I can easily understand what Ben’s code is doing, what I couldn’t figure out is why it worked. If you reflect over TempDataDictionary (the type of the Controller.TempData property), you’ll see that the data type it persists to the session is an internal structure.

Ben’s code, however, mocks out the Session to return the expected TempDataDictionary object. By all counts, that should fail, since the TempDataDictionary won’t be getting back the values it expects–it expects the internal map structure.

Well, it turns out I was glossing over one very important fact. TempDataDictionary was written to be smart enough that if the underlying session store either didn’t work, or didn’t provide the right data, TempData will continue to operate as normal–for the current request only. You can see below that if the session data was null or wasn’t the right type, it just creates a new internal map.

(image cut off for space)

One of the benefits of TempData is the cross-request persistence via the session. You might not have known it, but when you call RedirectToAction in your controller action, for example, it’s actually resulting in a 300-level HTTP redirect, which means an entirely new HttpContext for the next request. It’s basically deferring to the browser to perform the redirect.

So, while Ben’s code will definitely work, here’s an extension method that can help with mocking out the session a little more “correctly”:

public static void NullifySessionState(this HttpSessionStateBase session)
{
    SetupResult.For(session[null]).IgnoreArguments().Return(null);
    session[null] = null;
    LastCall.IgnoreArguments();
}

Displaying [foo] on every page of an ASP.NET MVC application

aaron — Sat, 26 Jan 2008 15:15:16 +0000

Frequently in web applications there’s a requirement like this: “Every page should display [foo].” Where “foo” can be literally anything: a list of favorites, sponsors, news, or whatever – it’s data. In what I’ll call “normal, by a long shot” ASP.NET cases, universally displayed data will probably be encapsulated in a user control and put on a master page. The master page includes the user control on all pages, and the user control loads the data and renders it, and it was all declared Good.

The MVC world (ASP.NET “unplugged”) turns everything on it’s head. Maintaining a clean separation of concerns means the controller is responsible for ensuring the appropriate data is made available to the appropriate view. The view does not load data on it’s own, nor does it know or care where the data came from. And the view was declared Dumb.

Views aren’t really dumb, of course, they have to render data, and the MVC framework does give them some tools to help. For example, the ViewMasterPage base class exposes helpers for constructing links, accessing the view data, etc.

So what do you do in the ASP.NET MVC world when you’ve got a “user control” embedded in your master page that needs specific data? Let’s say that hypothetically speaking you’re working on a CodeCampServer project, and you need to, oh I don’t know, display a list of code camp Sponsors (ahem, “Contributors”) on every single page?

The way I see it, you’ve got three options:

1. “Global” data for global display

Data can be loaded at a low level for each and every request. Something like:

protected void Application_BeginRequest(object sender, EventArgs e)
{
    this.Context.Items["FooData"] = new FooData();
}

The pro is that FooData will be available to every view (though not through the standard ViewData). Unfortunately if this data is expensive to compute (or even if it isn’t) it’ll be loaded for every request, no matter what. Oh, and no one in their right mind would actually do it this way. There’s that, too.

2. Controller.OnPreAction

The main Controller class exposes a virtual OnPreAction method which offers a hook just before an action is invoked. For global data, all controllers in your application could derive from a common base controller class which loads the necessary data.

protected override bool OnPreAction(string actionName, System.Reflection.MethodInfo methodInfo)
{
    ViewData["FooData"] = new FooData();
    return base.OnPreAction(actionName, methodInfo);
}

Views will be able to access the data via the ViewData property, as normal. With single inheritance in C#, a required base class just for common data can potentially cause problems.

3. Call “RenderAction” from the view

RenderAction is an extension method that allows a view to reference a Controller and Action and have the results be rendered in-place within the view.

The “Tags” controller and “Cloud” action would render a view that generated an HTML fragment that would fit within the current view. This approach has advantages of only loading data when absolutely necessary and changing your view doesn’t necessarily require changing the application code to match.

There could be questions about separation of concerns: a view is determining what data to include regardless of what it’s controller gave it. But the same is true for the other solutions as well – this is just more dynamic.

Another advantage to this approach is that if you set it up right, with no extra work your “viewlets” (the views that render fragments) can return JSON serialized data for an AJAX call, for example.

I’m pro-RenderAction, but in discussions I’ve had with people it hasn’t been as big a hit with them. What are your thoughts? Am I missing some pros or cons? Are there more options that I didn’t include? Is it really just an app-by-app decision, or is there an emerging convention that should be followed?

Unifying Web "Sites" and Web Services with the ASP.NET MVC Framework

aaron — Wed, 02 Jan 2008 03:10:53 +0000

(For those who’d rather just download the code, the link is at the end.)

Lately I’ve been delving into the ASP.NET MVC framework, the timing of which has been interesting as I am about to finish reading RESTful Web Services by Leonard Richardson and Sam Ruby. It’s an excellent book that I’d highly recommend to anybody designing and creating services for the web, or just interested in it.

This quote from the book description on Amazon.com succinctly describes what’s been floating around in my head for a while:

You’ve built web sites that can be used by humans. But can you also build web sites that are usable by machines? That’s where the future lies, and that’s what RESTful Web Services shows you how to do.
[Emphasis mine]

Why do we have to build web "sites" for humans and different web services for machines? I can create an ASP.NET site, a SOAP-based ASMX web service, or a SOAP or REST (with .NET 3.5) WCF service and while they can share business logic, there’s still a lot of "endpoint code" (for lack of a better term) that has to be implemented, and if I want a human friendly front end + a web API, I have to build a site that essentially wraps another service, since the site itself really is a service.

With the ASP.NET MVC Framework, though, I see the opportunity to unify services and "sites" (human-readable services). Imagine visiting http://www.example.com/books/ and being able to receive back HTML, POX, or JSON, depending on what you asked for–with no additional code required outside of following a convention or two. Web browsers ask for HTML, returning a human consumable page that gets rendered. AJAX or custom clients can request JSON or XML, whatever they know how to interpret best.

The separation of concerns and extensibility that the ASP.NET MVC framework exposes lets us accomplish this with surprisingly little code. At least for read-only services (which is as far as I took it for now.) If you’re not familiar with how the ASP.NET MVC framework works, check out Eilon’s excellent ASP.NET MVC design philosophy post (he also includes many good reference links).

Approach

Outside of the ASP.NET MVC framework itself, from an HTTP perspective I simply want to alter my response format depending on what the incoming request asked for. I decided to keep it simple and only support the "text/html", "application/xml", and "application/json" media types.

I started off trying to use the "Accept" HTTP header as an indicator for what response format the client preferred. After all, that’s what the Accept header is for: "The Accept request-header field can be used to specify certain media types which are acceptable for the response." But I quickly ran into a snafu when I found that Firefox prefers XML over HTML.

That means that every request Firefox makes would result in the uber-friendly XML view.

And because of that snafu, I read up some more on the Accept header – namely what they had to say about it in an appendix of RESTful Web Services:

Hiding this information inside the HTTP headers is a good idea for web browsers, but it shouldn’t be the only solution for web service clients. I recommend exposing different representations using different URIs. … If you want to support Accept on top of this, that’s great (Rails does this too).

There was also some pragmatic advice in the chapter on Representations.

It’s RESTful to keep this information [file format types] in the HTTP headers, and it’s RESTful to put it in the URI. I recommend keeping as much of this information as possible in the URI, and as little as possible in request metadata. I think URIs are more useful than metadata. URIs get passed around from person to person, and from program to program. The request metadata almost always gets lost in translation.

I tend to agree with that. To make it easy and somewhat intuitive, I chose to base the response format on the existence of a querystring parameter named "format". It can specify "xml" or "json", for example http://www.example.com/books/?format=json. But really, you can use any method you want to allow format specification.

Implementation

Formatting the response is the responsibility of the View in the MVC architecture. Since processing requests for HTML content didn’t need to change from the default ASP.NET MVC behavior, all I need to do is override the default WebFormViewFactory functionality and return my own "SerializedView" if the URI indicated xml or json formatting. SerializedView is an abstract base class that encapsulates common functionality and allows sub-classes to perform the serialization, or handle custom error reporting.

When a Controller passes control to a View, it calls the "RenderView" method on the Controller base class, passing in the view name and some optional data – including something called "ViewData" – an object that represents the content the view should render.

Here’s the best part: creating an ASP.NET MVC site+service using my approach means passing a serializable object as ViewData. It’s as simple as that, nothing else needs to change (ok, you need one additional line of code in your Application_Start handler – more on that later). In your ASPX view, you can access the object via ViewData and use all the HTML helpers, UserControls, etc. that you want to build out your HTML, javascript, and who-knows-what.

Unfortunately, the current CTP of the ASP.NET MVC framework does not expose a way to "inject" a different IViewFactory (my subclassed version) into the default Controller created by the ControllerBuilder class. So, that means implementing the IControllerFactory interface and duplicating (ouch!) the code that ControllerBuilder executes, with one somewhat nasty addition.

Yuck! The ViewFactory property is specific to the Controller class, not the IController interface, hence the specific processing — and that also means my approach won’t work for other IController implementations. Not without some extra work, anyway.

This is where the only change you need to make comes in. My IControllerFact
ory implementation needs to be registered as the default controller factory, which is done in the Application_Start handler – the same place your routes are configured.

Serializable Types

For various reasons, you should use the WCF [DataContract] and [DataMember] attributes to tag your objects as serializable. For one, you gain all the serialization benefits these attributes offer, plus you can use the same contract types across multiple endpoints if you need to. And for another, serializing to JSON via the System.Runtime.Serialization.Json.DataContractJsonSerializer requires the DataContract attribute. If you use the older [Serializable] attribute, you get some interesting results.

The deprecated System.Web.Script.Serialization.JavaScriptSerializer works correctly for objects tagged with [Serializable] but it’s, well, deprecated.

Example

Using the default ASP.NET MVC Application templates, I registered the default ControllerFactory in my Application_Start handler, defined a Books controller with a default action, and a "List" view that prints out some Author and Title information. I also created the following definition of a book.

My controller implementation is no different than it normally would be. I get a list of books and render the "List" view, explicitly specifying the book list as the ViewData. You might notice that I pass the ControllerContext into the GetBooks method. I am experimenting with returning URIs to related resources as part of the data. I’m still playing around, but for now you get my latest attempt.

Requesting the appropriate URI in Firefox yields the expected result from my List view:

And altering the URI returns the appropriate response types, xml or json.

Summary

This ended up being a longer post than I intended, but I hope it was worth it. I’ve put the full source for the "MvcServiceLibrary" and an example up on my Tools page – but here’s the direct download link. I’ll also be checking if this is worth putting into the MvcContrib open source project.

I think that the ASP.NET MVC framework is a huge step forward in creating RESTful web sites, and hopefully now also RESTful web services! Let me know what you think, I love getting feedback.

Writing web apps for the iPhone

aaron — Sat, 27 Oct 2007 04:01:21 +0000

I’ve been working on a web app for the iPhone the last few days. It’s been a little while since I’ve done ASP.NET (I miss it!) so it’s fun to jump back in. I came across iUI – a very well done, lightweight and visually beautiful “mini-framework” for creating web sites that behave just like native iPhone applications. Digg.com used an early version of iUI to create their iPhone interface.

Unfortunately, to use the HTML structure and navigation paradigm that iUI supports out of the box, I feel more like I’m coding in classic ASP, not ASP.NET. iUI (as it currently stands) is all about replacing the current page fragment with one returned from the server via an Ajax call. Sort of like a bunch of UpdatePanel’s that keep replacing each other–except that the last instance isn’t removed, just hidden. So if you navigate to a “sub page” (or sub menu) and perform an action that causes a state change such that an already-loaded higher level menu should be updated, it won’t be. It’s cached.

Alas, these are the issues I’m working around. I’m working on some possible tweaks to iUI to help support some of this functionality. I’ll probably post something when my app is done with a quick tutorial on how to use the toolkit from ASP.NET–assuming I figure it out.

Has anybody out there used iUI and have advice for me? I’m interested! I’ll pay big bucks… I’ll take you out for a fancy fast-food meal. How can you pass that up??

Technorati Tags: iPhone, iUI, ASP.NET

Creating Comet applications with ASP.NET

aaron — Sun, 08 Jul 2007 02:47:00 +0000

Sometimes it’s useful to hijack a particular technology to do something it was never intended to do. Comet does exactly that, and it’s not for the faint of heart. In a nutshell, “Comet-style” applications use features of the HTTP request-response communication model to morph it into a streaming context whereby the server can essentially push data to the client (instead of the client request data from the server). Wikipedia puts it well:

Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. It allows creation of event-driven web applications which are hosted in the browser.

When faced with the need for a real-time web application, there will always be trade-offs between performance and scalability. One possibility is to implement a pull architecture that periodically polls the sever. The benefits include higher scalability per server with the trade-off of increased latency and lower performance (in terms of information availability). On the other side of the coin is a persistent connection which allows the server to push streaming data to the client. Benefits include great performance (low latency), but low scalability since every client connection is held open for long periods of time which today’s web servers are not optimized for. Lightstreamer.com has a good white paper describing the pros and cons of the various approaches (including some hybrid methods), and, of course, why theirs is the best and you should buy it. Truth be told, I think they have a very compelling product offering. (I haven’t tried it, though, just read about it.)

So how can a Comet ASP.NET application scale? Very poorly. Since each client connection holds open a dedicated thread from the ASP.NET thread pool, there are really only two ways to scale:

Increase the number of threads in the thread pool to the maximum. This is done in the element located under . Set the maxWorkerThreads attribute to the max of 100. This is a per-CPU value, so assuming you ran this on a quad-processor server, your application has the potential to scale to 400 concurrent users per server. Assuming you grab a barebones Dell PowerEdge 4-proc server for $10,000 USD, you’ll be paying $25 per concurrent user. Fantastic numbers! Not.
Add more servers – in real-time applications it’s typically not feasible for each client connection to end up on different servers. Once the initial connection has been made, the client is “pinned”. In cases like these, additional servers can be added but they have to live behind some “sticky load balancing” routers.

The other option is to write a custom web server that is optimized for concurrent connections. I wonder if WCF could handle the challenge, and while it seems like it could do better than IIS+ASP.NET, it appears you wouldn’t necessarily get a huge bang for your buck. Some real-world testing would be much more definitive however. Here’s a few links talking about streaming data back over an HTTP connection with WCF:

Just for fun I’ve created a very brief ASP.NET sample application that demonstrates a basic Comet implementation. It streams the current server time back to the web browser, which just displays the value. Most of the work is in javascript on the client page. The key ASP.NET components are simply the disabling of output buffering, and flushing the response stream as appropriate. I didn’t use any “fancied up” javascript libraries so as not to exclude anybody who isn’t familiar with any particular library.

And now, after having bashed my own approach, here it is. Create a new Web Site in Visual Studio 2005. Add a page called simply “Service.aspx” and put this code in the code-behind:

public static string Delimiter = "|";

protected void Page_Load(object sender, EventArgs e)
{
    Response.Buffer = false;

    while (true)
    {
        Response.Write(Delimiter
            + DateTime.Now.ToString("HH:mm:ss.FFF"));
        Response.Flush();

        // Suspend the thread for 1/2 a second
        System.Threading.Thread.Sleep(500);
    }

    // Yes I know we'll never get here,
    // it's just hard not to include it!
    Response.End();
}

Add a new HTML page to the project (I called mine “ajax.html”) and overwrite the contents with this: (Explanation to follow.)
(NOTE: The formatting got screwed up during a blog import to Wordpress – download the zip file linked below for “readable” code. )

<html xmlns="http://www.w3.org/1999/xhtml" ><head>    <title>Comet AJAX Sampletitle>    <script language="javascript">      function getData()      {          loadXMLDoc("Service.aspx");      }var req = false;

function createRequest()      {        // branch for native XMLHttpRequest object        if(window.XMLHttpRequest && !(window.ActiveXObject))        {          try {            req = new XMLHttpRequest();          } catch(e) {            req = false;          }        // branch for IE/Windows ActiveX version        } else if(window.ActiveXObject) {          try {            req = new ActiveXObject("Msxml2.XMLHTTP");          } catch(e) {            try {                req = new ActiveXObject("Microsoft.XMLHTTP");            } catch(e) {                req = false;            }          }        }      }

function loadXMLDoc(url) {          try          {              if (req) {                  req.abort();                  req = false;              }

createRequest();

if (req) {                 req.onreadystatechange = processReqChange;                 req.open("GET", url, true);                 req.send("");              }              else {                  alert('unable to create request');              }          }          catch (e) {              alert(e.message);          }      }

function processReqChange() {          if (req.readyState == 3) {              try              {                  ProcessInput(req.responseText);

// At some (artibrary) length                   // recycle the connection                  if (req.responseText.length > 3000) {                      lastDelimiterPosition = -1;                      getData();                  }              }              catch (e) {                  alert(e.message);              }          }      }

var lastDelimiterPosition = -1;

function ProcessInput(input)      {          // Make a copy of the input          var text = input;          // Search for the last instance of the delimiter          var nextDelimiter =                 text.indexOf('|', lastDelimiterPosition+1);          if (nextDelimiter != -1) {              // Pull out the latest message              var timeStamp = text.substring(nextDelimiter+1);              if (timeStamp.length > 0) {                  lastDelimiterPosition = nextDelimiter;                  ProcessTime(timeStamp);              }          }      }

function ProcessTime(time)      {          var out = document.getElementById('outputZone');          out.innerHTML = time;      }    script>head><body onload="getData()">    <b>Server Time:b>  <span id="outputZone">span>body>html>

It works by making a connection to the server and processing the response as it streams back. “getData()” will initiate an AJAX request for the service page, which will continue to stream data back. When new data is available, the client parses out the new data beginning from the last location in the response that was processed. If the response text gets too large, the connection is severed and a new one made (semi-polling — one of the hybrid approaches) as processing an ever increasing response body can ultimately slow down the web browser unnecessarily.

There is a lot more to a successful Comet implementation, obviously, and I encourage you to read the information available at Wikipedia including the reference links.

Download the 3 files (ajax.html, Service.aspx, Service.cs) here: ASP.NET Comet Example.zip

ASP.NET 2.0 Page Lifecycle

aaron — Sat, 15 Jul 2006 00:27:00 +0000

I think just about every single ASP.NET candidate I’ve interviewed knows practically nothing about the page lifecycle, except for “Page_Load” of course—and they always say that: “Page Load”. They never say “Load” which is the actual event name. (That’s being a little picky though.)

Here’s something every web developer should be familiar with—not necessarily memorized (otherwise why would we enjoy diagrams like this?)—but at least familiar!

Debugging ASP.NET

aaron — Tue, 20 Dec 2005 12:30:00 +0000

Jim Cheshire has posted a helpful resource (with links to helpful resources) for debugging ASP.NET applications. Not VS.NET debugging, but really debugging.

(link to his blog)

VS 2005 and Web Projects

aaron — Tue, 22 Nov 2005 18:44:00 +0000

Here is an indispensable tool for building and deploying Web Projects in Visual Studio 2005.
(on msdn.microsoft.com)

Also, I have run into this sticky situation: I have several projects in my solution (a few class library projects, the website project, and the web deployment project), where one or more class libraries make use of web services. The web service endpoint binding is set to “dynamic” which means the URL is placed in an app.config file. That’s great, but when those class libraries are used in the website, the configuration information is read from the web.config file, not the individual app.config files.

Unless I am missing something on how to automatically link the app.config files to the web.config file, I have to manually import the required settings. I originally thought that the web deployment project options would save me here, because there is an option to “Enable web.config file section replacement” where you pull the section from another .config file, however it seems to be failing on anything except for the section (in the app.config file the dynamic web service binding is saved in the section).

It works if I manually update the file, but I’m disappointed that the deployment project won’t handle it. Yeah yeah, I know it’s only Beta Preview, but still!