Recipe: Dynamic Site Layout and Style Personalization with ASP.NET

Recipe: Dynamic Site Layout and Style Personalization with ASP.NET

Problem:

You want to enable end-users visiting your web-site to dynamically customize the look and feel of it. Specifically, you want to enable them to choose different content layouts for the site, as well as different style experiences (colors, fonts, etc).

When building this customization system, you want to make sure you avoid duplicating logic throughout the multiple pages. Instead, you want to be able to author the dynamic personalization logic once and have all pages inherit it.

Solution:

ASP.NET 2.0 makes dynamically customizing the UI experience of a web-site easy. Specifically, it provides a flexible mechanism for defining page layouts using a feature called “Master Pages”. It also provides a flexible mechanism for defining a page’s style look and feel via a feature called “Themes”.

What is nice about both “Master Pages” and “Themes” is that they can be configured either statically (by specifying the Master Page or Theme to use within an ASP.NET Page’s <% Page %> directive), or dynamically at runtime by setting the Page’s MasterPageFile and Theme properties via code. This later approach can be easily used to enable dynamic user personalization of UI on a web-site. The below walkthrough demonstrates how to implement this. You can also download a complete sample that shows how to-do this here.

Step 1: Create a New Web-Site

Begin by starting a new web-site in either Visual Studio or Visual Web Developer (which is free). Create two master page files called “Site1.Master” and “Site2.Master” within it.

We will use these two master-pages to provide two alternative layout views for the site that end-users will be able to pick between. For the purposes of this sample we’ll keep each master file simple (although obviously you could add much more layout and content to each). Here is a trivial example of what you could have in “Site1.Master” to start with for the purposes of this sample:

After creating the two master-pages, add two new ASP.NET pages to the project – and choose to have them built using a Master Page. Call these two new pages “Default.aspx” and “Personalize.aspx”, and have them be based on the Site1.Master template above.

Step 2: Add Two Themes to the Site

Right-click on the Solution Explorer within VS and choose the “Add ASP.NET Folder->Theme” context menu option. This will create a folder called “App_Themes” immediately underneath your application root directory. You should then create two sub-folders underneath the “App_Themes” folder called “Blue” and “Red”. This will define two separate themes for the site. Within each theme folder you can add CSS stylesheets, images, and .skin files to customize the site’s appearance however you want.

For the purposes of this sample, we’ll add a “blue.css” stylesheet under the “Blue” folder and a “red.css” stylesheet under the “Red” folder. For now we’ll keep their implementations trivial and just set the background color for pages in them:

Once this is done, our site project layout should look like this:

Now we are ready to enable end-users visiting our site to dynamically personalize which Master Page file is used (allowing them to control the layout of the site), as well as which Theme/Stylesheet is used (allowing them to control the style of the site).

Step 3: Enable ASP.NET Personalization

We could save our visitors’ layout and style preferences in a variety of different places (within an http cookie, within a custom database, in a directory on the file-system, etc). For the purposes of this sample, I’m going to use the new ASP.NET 2.0 Profile Personalization feature. This allows me to easily save/retrieve information about users accessing the site with minimal code.

You can use the ASP.NET Profile Personalization feature in combination with any authentication mechanism (Windows Authentication, Forms Authentication, Passport, or any other authentication approach you want). For this sample I’m just going to use Windows Authentication to login and identify the user. If you aren’t familiar with how Windows authentication works, please read my previous Enabling Windows Authentication Recipe.

Once I’ve configured the site to use Windows Authentication, I can enable the ASP.NET Profile system by adding a section within my web.config file that lists the properties I want to store about users. For the purposes of this sample I’m going to store two string properties:

If you have SQL Express installed on your machine, then you are done. ASP.NET will automatically provision a new SQL Express database within your app_data folder at runtime that has the appropriate Profile tables configured to save your profile data above. You don’t need to take any additional steps to configure this.

If you don’t have SQL Express installed, and instead want to use a SQL Server to store the Profile data, you’ll need to create a database within SQL to store the ASP.NET Application Service tables, and update your web.config file to point at the database. The good news is that this is easy to-do. If you haven’t done this before, please read my previous Configuring ASP.NET 2.0 Application Services to use SQL Recipe that demonstrates how to do this.

Step 4: Building the Personalize.aspx Page

Now that we have enabled ASP.NET Profile Personalization, we can go to work building a Personalize.aspx page that we can use to enable end-users on the site to dynamically pick which Master Page and Theme they want to use. To do this we’ll add two controls to the page to enable users to select the appropriate choices:

Within the code-behind of the Personalize.aspx page we’ll then write this code to save and restore the selection to the ASP.NET Profile system:

Notice that ASP.NET automatically adds a strongly-typed “Profile” object to our pages that we can use to easily get type-safe access to the Profile collection we defined within our web.config file previously. It automatically handles saving/retrieving the user’s profile data from the configured profile database.

When the Personalize.aspx page is visited, an end-user will now be able to pick which layout and style choice they want:

When the end-user clicks “Update” their settings will be persisted in the ASP.NET Profile database automatically. When they revisit the Personalize.aspx page later, their preferences will be retrieved and populated within the dropdownlists.

Step 5: Building a Base Page Class to Personalize Page Content

We want to avoid having to repeatedly add the same logic to set the Master Page and Theme on every page of the site. We’ll instead create a base page class that encapsulates this functionality, and have each of the pages on our site inherit from it.

To-do this, we’ll create a new class called “MyBasePage” that will live within our app_code directory (if we are using the VS 2005 Web Site Project option):

The above class inherits the base ASP.NET Page Class (System.Web.UI.Page), and overrides the OnPreInit method (which is called when the “PreInit” event on a page executes). Within this method we then set the page’s “MasterPageFile” and “Theme” properties with the values the user persisted within the ASP.NET Profile Store.

Note that when accessing the Profile data in the code above, I’m accessing it via the “GetPropertyValue()” helper method. This code will work both within the web-site project, as well as any companion class-library projects I might want to use to store this base class in instead (enabling me to easily re-use it across multiple projects).

Step 6: Using the Base Page Class within Pages

Using the base page class we built above with pages is simple. Just open the code-behind file of any of the pages within the site, and update its base class declaration from:

Now when the pages within our site run, the OnPreInit method within our base class will execute, and we’ll dynamically update the Page’s Master Page and Theme to reflect what the user has personalized. For example:

Or:

This is all of the logic we need to enable dynamic layout and style personalization for the site. We can now pass off the master page templates and CSS style-sheets to a designer to customize to make them as rich and attractive as we want.

Summary

The above walkthrough illustrates the basics of how you can enable rich site layout and style personalization. It also demonstrates how you can encapsulate common page functionality within a base class that you can easily re-use across multiple pages in a site – a very useful approach that can be used far beyond just personalization.

Click here to download a complete version of the sample that you can run and examine locally.

Tip/Trick: How to Register User Controls and Custom Controls in Web.config

Tip/Trick: How to Register User Controls and Custom Controls in Web.config

I've been including this technique in my ASP.NET Tips/Tricks talks the last year, but given how many people are always surprised by its existence I thought it was worth a dedicated tip/trick post to raise the visibility of it (click here to read other posts in my ASP.NET Tips/Tricks series).

Problem:

In previous versions of ASP.NET developers imported and used both custom server controls and user controls on a page by adding <%@ Register %> directives to the top of pages like so:

Note that the first two register directives above are for user-controls (implemented in .ascx files), while the last is for a custom control compiled into an assembly .dll file. Once registered developers could then declare these controls anywhere on the page using the tagprefix and tagnames configured. This works fine, but can be a pain to manage when you want to have controls used across lots of pages within your site (especially if you ever move your .ascx files and need to update all of the registration declarations. Solution: ASP.NET 2.0 makes control declarations much cleaner and easier to manage. Instead of duplicating them on all your pages, just declare them once within the new pages->controls section with the web.config file of your application:

You can declare both user controls and compiled custom controls this way. Both are fully supported by Visual Studio when you use this technique -- and both VS 2005 Web Site Projects and VS 2005 Web Application Projects support them (and show the controls in WYSIWYG mode in the designer as well as for field declarations in code-behind files).

One thing to note above is the use of the "~" syntax with the user-controls. For those of you not familiar with this notation, the "~" keyword in ASP.NET means "resolve from the application root path", and provides a good way to avoid adding "..\" syntax all over your code. You will always want/need to use it when declaring user controls within web.config files since pages might be using the controls in different sub-directories - and so you always need to resolve paths from the application root to find the controls consistently.

Once you register the controls within the web.config file, you can then just use the controls on any page, master-page or user control on your site like so (no registration directives required):

Tip/Trick: Use the ASP.NET 2.0 CSS Control Adapters for CSS friendly HTML output

Tip/Trick: Use the ASP.NET 2.0 CSS Control Adapters for CSS friendly HTML output

Tired of having html

elements rendered by the built-in ASP.NET server controls and wishing you could use a pure CSS solution instead? If so, read on...

Last week we released Version 1.0 of the ASP.NET 2.0 CSS Control Adapters. These adapters take advantage of a new extensibility feature in ASP.NET 2.0 that we call the "Control Adapter Architecture", and which enables developers to override, modify and/or tweak the rendering output logic of an existing server control (without changing any of its properties, supported events, or programming model).

The ASP.NET 2.0 CSS Control Adapters that we released last week provide pre-built control adapters for 11 of the most common ASP.NET controls (GridView, DetailsView, FormsView, DataList, Menu, TreeView, Login, LoginStatus, CreateUserWizard, ChangePassword and PasswordRecovery). The CSS Control Adapters cause these ASP.NET controls to emit CSS friendly html output (eliminating things like inline styles and

elements), and can significantly help when using CSS on your web-site.

Click any of the links below to see a before/after example of how they change the markup generated by these built-in ASP.NET controls:

• Menu
• TreeView
• DetailsView
• FormView
• GridView
• DataList
• Login
• ChangePassword
• PasswordRecovery
• CreateUserWizard
• LoginStatus

The CSS Control Adapter toolkit includes both VB and C# source code for all of the above control adapters. You can use the source-code as-is (without having to modify anything) to get pure CSS output. Or if you want to tweak the output even further you can go in and modify the adapters to emit any custom markup you want:

I posted a nice tutorial two months ago that walksthrough how you can use the CSS Control Adapters that I highly recommend reading to learn how to get started.

Scott Mitchell earlier today also posted a nice CSS Control Adapters article on www.4guysfromrolla.com that covers how to use them as well.

You can ask questions and get help on how to use them on the CSS Control Adapters Forum on http://www.asp.net.

Hope this helps,

Scott

P.S. I'd like to pass along a special big thanks to Russ and Heidi for all of their awesome work in building these CSS Control Adapters and samples!

P.P.S. For additional ASP.NET Tips/Tricks blog posts of mine, please review my ASP.NET Tips, Tricks and Resources page.

Tip/Trick: Using Server Side Comments with ASP.NET 2.0

Tip/Trick: Using Server Side Comments with ASP.NET 2.0

Problem

You are coding away on an ASP.NET page, and are trying to isolate a problem within the page. You have some existing html/controls/markup/in-line code that is being used on the page, and you want to temporarily comment it out while you fix the problem.

Solution

ASP.NET supports a little known feature called “server-side comments” that you can use to completely disable code/controls/html in a page. Server-side comments in ASP.NET are delimited using a <%-- --%> syntax. For example:

One common question people ask is what the difference is between using client-side HTML comments and server-side comments. The key difference is that with client-side comments it is the browser which is ignoring the content within them. Code/controls within client-side comments will still be executed on the server and sent down to the browser. As such, if there is a server error caused within them it will block running the page.

With server-side comments, the ASP.NET compiler ignores everything within these blocks at parse/compile time, and removes the content completely when assembling the page (like its contents weren’t there at all). Consequently, any errors caused by mal-formed controls or issues with inline code or data-binding expressions within them will be ignored. The page is also just as fast with controls/code within server-side comments as if there were no controls/code on the page at all (there is no runtime performance overhead to them).

One tip/trick to take advantage of in the HTML source editor within Visual Web Developer and VS 2005 is the automatic comment/uncomment feature they support. You can use this by selecting some markup within a .aspx page, and then clicking the “comment” command button that is on HTML Source Editor Toolbar:

This will automatically wrap the selected content with a <%-- --%> block. You can likewise move the cursor within it and click the uncomment command to remove the comment. Keyboard short-cuts are also automatically enabled to do this purely from the keyboard. The exact keystrokes depend on what VS profile you have configured – but on my system it is “Ctrl-K, Ctrl-C” to comment a block and “Ctrl-K, Ctrl-U” to uncomment one.

Note that this comment/uncomment command in VS works not only in HTML – but also within regular VB/C# source files as well. It provides an easy and consistent way to comment out functionality everywhere within your project.

Tip/Trick: Url Rewriting with ASP.NET

Tip/Trick: Url Rewriting with ASP.NET

People often ask me for guidance on how they can dynamically "re-write" URLs and/or have the ability to publish cleaner URL end-points within their ASP.NET web applications. This blog post summarizes a few approaches you can take to cleanly map or rewrite URLs with ASP.NET, and have the option to structure the URLs of your application however you want.

Why does URL mapping and rewriting matter?

The most common scenarios where developers want greater flexibility with URLs are:

1) Handling cases where you want to restructure the pages within your web application, and you want to ensure that people who have bookmarked old URLs don't break when you move pages around. Url-rewriting enables you to transparently forward requests to the new page location without breaking browsers.

2) Improving the search relevancy of pages on your site with search engines like Google, Yahoo and Live. Specifically, URL Rewriting can often make it easier to embed common keywords into the URLs of the pages on your sites, which can often increase the chance of someone clicking your link. Moving from using querystring arguments to instead use fully qualified URL's can also in some cases increase your priority in search engine results. Using techniques that force referring links to use the same case and URL entrypoint (for example: weblogs.asp.net/scottgu instead of weblogs.asp.net/scottgu/default.aspx) can also avoid diluting your pagerank across multiple URLs, and increase your search results.

In a world where search engines increasingly drive traffic to sites, extracting any little improvement in your page ranking can yield very good ROI to your business. Increasingly this is driving developers to use URL-Rewriting and other SEO (search engine optimization) techniques to optimize sites (note that SEO is a fast moving space, and the recommendations for increasing your search relevancy evolve monthly). For a list of some good search engine optimization suggestions, I'd recommend reading the SSW Rules to Better Google Rankings, as well as MarketPosition's article on how URLs can affect top search engine ranking.

Sample URL Rewriting Scenario

For the purpose of this blog post, I'm going to assume we are building a set of e-commerce catalog pages within an application, and that the products are organized by categories (for example: books, videos, CDs, DVDs, etc).

Let's assume that we initially have a page called "Products.aspx" that takes a category name as a querystring argument, and filters the products accordingly. The corresponding URLs to this Products.aspx page look like this:

Rather than use a querystring to expose each category, we want to modify the application so that each product category looks like a unique URL to a search engine, and has the category keyword embedded in the actual URL (and not as a querystring argument). We'll spend the rest of this blog post going over 4 different approaches that we could take to achieve this.

Approach 1: Use Request.PathInfo Parameters Instead of QueryStrings

The first approach I'm going to demonstrate doesn't use Url-Rewriting at all, and instead uses a little-known feature of ASP.NET - the Request.PathInfo property. To help explain the usefulness of this property, consider the below URL scenario for our e-commerce store:

One thing you'll notice with the above URLs is that they no longer have Querystring values - instead the category parameter value is appended on to the URL as a trailing /param value after the Products.aspx page handler name. An automated search engine crawler will then interpret these URLs as three different URLs, and not as one URL with three different input values (search engines ignore the filename extension and just treat it as another character within the URL).

You might wonder how you handle this appended parameter scenario within ASP.NET. The good news is that it is pretty simple. Simply use the Request.PathInfo property, which will return the content immediately following the products.aspx portion of the URL. So for the above URLs, Request.PathInfo would return "/Books", "/DVDs", and "/CDs" (in case you are wondering, the Request.Path property would return "/products.aspx").

You could then easily write a function to retrieve the category like so (the below function strips out the leading slash and returning just "Books", "DVDs" or "CDs"):

Sample Download: A sample application that I've built that shows using this technique can be downloaded here. What is nice about this sample and technique is that no server configuration changes are required in order to deploy an ASP.NET application using this approach. It will also work fine in a shared hosting environment.

Approach 2: Using an HttpModule to Perform URL Rewriting

An alternative approach to the above Request.PathInfo technique would be to take advantage of the HttpContext.RewritePath() method that ASP.NET provides. This method allows a developer to dynamically rewrite the processing path of an incoming URL, and for ASP.NET to then continue executing the request using the newly re-written path.

For example, we could choose to expose the following URLs to the public:

This looks to the outside world like there are three separate pages on the site (and will look great to a search crawler). By using the HttpContext.RewritePath() method we can dynamically re-write the incoming URLs when they first reach the server to instead call a single Products.aspx page that takes the category name as a Querystring or PathInfo parameter instead. For example, we could use an an Application_BeginRequest event in Global.asax like so to do this:

The downside of manually writing code like above is that it can be tedious and error prone. Rather than do it yourself, I'd recommend using one of the already built HttpModules available on the web for free to perform this work for you. Here a few free ones that you can download and use today:

• UrlRewriter.net
• UrlRewriting.net

These modules allow you to declaratively express matching rules within your application's web.config file. For example, to use the UrlRewriter.Net module within your application's web.config file to map the above URLs to a single Products.aspx page, we could simply add this web.config file to our application (no code is required):

The HttpModule URL rewriters above also add support for regular expression and URL pattern matching (to avoid you having to hard-code every URL in your web.config file). So instead of hard-coding the category list, you could re-write the rules like below to dynamically pull the category from the URL for any "/products/[category].aspx" combination:

This makes your code much cleaner and super extensible. Sample Download: A sample application that I've built that shows using this technique with the UrlRewriter.Net module can be downloaded here. What is nice about this sample and technique is that no server configuration changes are required in order to deploy an ASP.NET application using this approach. It will also work fine in a medium trust shared hosting environment (just ftp/xcopy to the remote server and you are good to go - no installation required). Approach 3: Using an HttpModule to Perform Extension-Less URL Rewriting with IIS7 The above HttpModule approach works great for scenarios where the URL you are re-writing has a .aspx extension, or another file extension that is configured to be processed by ASP.NET. When you do this no custom server configuration is required - you can just copy your web application up to a remote server and it will work fine. There are times, though, when you want the URL to re-write to either have a non-ASP.NET file extension (for example: .jpg, .gif, or .htm) or no file-extension at all. For example, we might want to expose these URLs as our public catalog pages (note they have no .aspx extension):

With IIS5 and IIS6, processing the above URLs using ASP.NET is not super easy. IIS 5/6 makes it hard to perform URL rewriting on these types of URLs within ISAPI Extensions (which is how ASP.NET is implemented). Instead you need to perform the rewriting earlier in the IIS request pipeline using an ISAPI Filter. I'll show how to-do this on IIS5/6 in the Approach 4 section below.

The good news, though, is that IIS 7.0 makes handling these types of scenarios super easy. You can now have an HttpModule execute anywhere within the IIS request pipeline - which means you can use theURLRewriter module above to process and rewrite extension-less URLs (or even URLs with a .asp, .php, or .jsp extension). Below is how you would configure this with IIS7:

Note the "runAllManagedModulesForAllRequests" attribute that is set to true on the section within . This will ensure that the UrlRewriter.Net module from Intelligencia, which was written before IIS7 shipped, will be called and have a chance to re-write all URL requests to the server (including for folders). What is really cool about the above web.config file is that:

1) It will work on any IIS 7.0 machine. You don't need an administrator to enable anything on the remote host. It will also work in medium trust shared hosting scenarios.

2) Because I've configured the UrlRewriter in both the and IIS7 section, I can use the same URL Rewriting rules for both the built-in VS web-server (aka Cassini) as well as on IIS7. Both fully support extension-less URLRewriting. This makes testing and development really easy.

IIS 7.0 server will ship later this year as part of Windows Longhorn Server, and will support a go-live license with the Beta3 release in a few weeks. Because of all the new hosting features that have been added to IIS7, we expect hosters to start aggressively offering IIS7 accounts relatively quickly - which means you should be able to start to take advantage of the above extension-less rewriting support soon. We'll also be shipping a Microsoft supported URL-Rewriting module in the IIS7 RTM timeframe that will be available for free as well that you'll be able to use on IIS7, and which will provide nice support for advanced re-writing scenarios for all content on your web-server.

Sample Download: A sample application that I've built that shows using this extension-less URL technique with IIS7 and the UrlRewriter.Net module can be downloaded here.

Approach 4: ISAPIRewrite to enable Extension-less URL Rewriting for IIS5 and IIS6

If you don't want to wait for IIS 7.0 in order to take advantage of extension-less URL Rewriting, then your best best is to use an ISAPI Filter in order to re-write URLs. There are two ISAPI Filter solutions that I'm aware of that you might want to check-out:

• Helicon Tech's ISAPI Rewrite: They provide an ISAPI Rewrite full product version for $99 (with 30 day free trial), as well as a ISAPI Rewrite lite edition that is free.
• Ionic's ISAPI Rewrite: This is a free download (both source and binary available)

I actually don't have any first-hand experience using either of the above solutions - although I've heard good things about them. Scott Hanselman and Jeff Atwood recently both wrote up great blog posts about their experiences using them, and also provided some samples of how to configure the rules for them. The rules for Helicon Tech's ISAPI Rewrite use the same syntax as Apache's mod_rewrite. For example (taken from Jeff's blog post):

Definitely check out Scott's post and Jeff's post to learn more about these ISAPI modules, and what you can do with them.

Note: One downside to using an ISAPI filter is that shared hosting environments typically won't allow you to install this component, and so you'll need either a virtual dedicated hosting server or a dedicated hosting server to use them. But, if you do have a hosting plan that allows you to install the ISAPI, it will provide maximum flexibility on IIS5/6 - and tide you over until IIS7 ships.

Handling ASP.NET PostBacks with URL Rewriting

One gotcha that people often run into when using ASP.NET and Url-Rewriting has to-do with handling postback scenarios. Specifically, when you place a

control on a page, ASP.NET will automatically by default output the "action" attribute of the markup to point back to the page it is on. The problem when using URL-Rewriting is that the URL that the control renders is not the original URL of the request (for example: /products/books), but rather the re-written one (for example: /products.aspx?category=books). This means that when you do a postback to the server, the URL will not be your nice clean one.

With ASP.NET 1.0 and 1.1, people often resorted to sub-classing the

control and created their own control that correctly output the action to use. While this works, it ends up being a little messy - since it means you have to update all of your pages to use this alternate form control, and it can sometimes have problems with the Visual Studio WYSIWYG designer.

The good news is that with ASP.NET 2.0, there is a cleaner trick that you can use to rewrite the "action" attribute on the

control. Specifically, you can take advantage of the new ASP.NET 2.0 Control Adapter extensibility architecture to customize the rendering of the control, and override its "action" attribute value with a value you provide. This doesn't require you to change any code in your .aspx pages. Instead, just add a .browser file to your /app_browsers folder that registers a Control Adapter class to use to output the new "action" attribute:

You can see a sample implementation I created that shows how to implement a Form Control Adapter that works with URLRewriting in my sample here. It works for both the Request.PathInfo and UrlRewriter.Net module approaches I used in Approach 1 and 2 above, and uses the Request.RawUrl property to retrieve the original, un-rewritten, URL to render. With the ISAPIRewrite filter in Approach 4 you can retrieve the Request.ServerVariables["HTTP_X_REWRITE_URL"] value that the ISAPI filter uses to save the original URL instead.

My FormRewriter class implementation above should work for both standard ASP.NET and ASP.NET AJAX 1.0 pages (let me know if you run into any issues).

Handling CSS and Image Reference Correctly

One gotcha that people sometime run into when using Url Rewriting for the very first time is that they find that their image and CSS stylesheet references sometimes seem to stop working. This is because they have relative references to these files within their HTML pages - and when you start to re-write URLs within an application you need to be aware that the browser will often be requesting files in different logical hierarchy levels than what is really stored on the server.

For example, if our /products.aspx page above had a relative reference to "logo.jpg" in the .aspx page, but was requested via the /products/books.aspx url, then the browser will send a request for /products/logo.jpg instead of /logo.jpg when it renders the page. To reference this file correctly, make sure you root qualify CSS and Image references ("/style.css" instead of "style.css"). For ASP.NET controls, you can also use the ~ syntax to reference files from the root of the application (for example:

Tip/Trick: List Running ASP.NET Worker Processes and Kill/Restart them from the command-line

Tip/Trick: List Running ASP.NET Worker Processes and Kill/Restart them from the command-line

Problem

You want a quick way to kill a process on your system, or kill and restart an ASP.NET or IIS worker process.

Solution

Windows has two built-in command-line utilities that you can use to help with this: Tasklist and Taskkill.

Within a command-line window you can type "Tasklist" to obtain a listing of all of running Windows processes on your system:

TaskKill can then be used to terminate any process instance in the above list. Simply provide it with the PID (Process ID) value of the process instance to kill and it will terminate it:

ASP.NET on Windows 2000 and XP runs code within the "aspnet_wp.exe" worker process (when using IIS). On Windows 2003 it runs within the IIS6 "w3wp.exe" worker process. Both of these processes are launched from Windows system services, which means you must provide the "/F" switch to taskkill to force-terminate them:

As a short-cut, you can also just provide the process image name to "Taskkill" if you want to avoid having to lookup the PID value for a specific process instance. For example, the below command will kill all ASP.NET worker processes on the system:

ASP.NET and IIS will automatically launch a new worker process the next time a request is received by the system. So when you run the above command it will shutdown all active ASP.NET Worker processes. When you then hit the site again a new one will be automaticlaly launched for it (and it will have a new PID as a result).

Note that both TaskList and TaskKill support a "/S" switch that allows you to specify a remote system to run the commands against. If you have remote admin rights on one of your co-workers machines this can be a lot of fun.

Credits

The above tutorial was inspired by Steve Lamb's nice post here. I was surprised to discover that these commands work with Windows XP and Windows 2003 too. Since the mid-90s I've been using a private set of utilities I always install on my dev box to accomplish the same task, without realizing that somewhere along the way they've been built-into Windows. Many thanks to Steve for pointing them out.

Credit Card Payment Processing with ASP.NET

Credit Card Payment Processing with ASP.NET

Rick Strahl has published a excellent (and very comprehensive) new article on techniques to perform credit-card payment processing with ASP.NET. He also includes full source code examples (for both ASP.NET 1.1 and ASP.NET 2.0). You can check it out here.

If you are interested in ecommerce, then you should also check out the ASP.NET 2.0 PayPal-enabled Store Starter Kit that you can download for free from here (it is near the middle of the page). It provides a really easy way to get an e-commerce site up and running using ASP.NET 2.0, and has PayPal payment integration built-in.

VS 2008 JavaScript Intellisense for Silverlight

VS 2008 JavaScript Intellisense for Silverlight

In addition to shipping VS 2008 and .NET 3.5 Beta 2 last week, my team also shipped the first release candidate of Silverlight 1.0 (it was a busy week at the office!). You can download the Silverlight 1.0 RC here.

I blogged about our Silverlight plans and roadmap a few months ago. This first Silverlight 1.0 release is focused on enabling rich media scenarios, and delivers high quality video and audio streaming and XAML based vector graphics and animation support in the browser. Silverlight is cross browser and cross platform, and can be easily added to any HTML page. Silverlight 1.0 supports a JavaScript programming model that makes it easy to integrate into an AJAX based page experience (note: Silverlight 1.1 will then add a cross-platform .NET framework programming model and enable RIA support).

JavaScript Intellisense for Silverlight 1.0

Over the last few weeks I've blogged about the new VS 2008 JavaScript Intellisense and VS 2008 JavaScript Debugging features in Beta 2. In addition to using these JavaScript tooling features when building pure HTML AJAX solutions, you can also now take advantage of them when targeting Silverlight 1.0.

Justin-Josef Angel earlier today released an awesome Silverlight 1.0 JavaScript Intellisense CodePlex Project that helps dramatically with this. It includes some nice annotated JavaScript helper methods that provide the ability to work with any XAML element in Silverlight with full intellisense in VS 2008.

To use it, simply add his JavaScript library to the top of your page:

You can then use Justin's helper functions to take late-bound objects and indicate their JavaScript type:

This will then cause the VS 2008 JavaScript intellisense engine to automatically provide intellisense and syntax checking for you:

You can learn all about Justin's library via his excellent tutorial post here. You can then download and participate in the codeplex project here.

Tip/Trick: Supporting Full Screen Mode with Silverlight

Tip/Trick: Supporting Full Screen Mode with Silverlight

One of the nice features that Silverlight supports is the ability to go "full screen" and effectively take over the entire screen of a computer (hiding everything else from sight - including the browser frame). This can be very useful when building immersive UI experiences, games, rich video players, etc.

For a nice example of this feature in action, make sure to check out the Fox Movies Sample on www.silverlight.net:

Once the page loads and the movie starts playing, double-click on the video surface in the middle to switch into full-screen mode (note: the screen-shot above is not in full-screen but rather browser mode). You can then hit the escape key to switch back into normal browser viewing.

How to Implement Full Screen Mode with Silverlight 1.1 using .NET

One of the questions I've seen a few people ask is "how can you implement full screen-mode when building Silverlight applications using .NET?" The good news is that the answer is actually pretty easy:

1) First add an input driven event handler to your application (for example: a mouse down or keyboard event handler). For security reasons Silverlight doesn't allow developers to switch an application into full-screen mode on first application load (you don't want an application to spoof you). So you'll instead need to trigger full-screen mode in response to a user action.

2) Within your input event handler set the BrowserHost.IsFullScreen property to true (note: the BrowserHost class lives within the System.Windows.Interop namespace). This will cause Silverlight to switch into full screen mode. Setting this property to false will return it back to normal browser mode.

Simple Full Screen Mode Sample

You can download a simple Silverlight full screen-mode sample I put together written in C# here.

When you run the sample it will load a super simple Silverlight application within the browser and display a text message prompting you to click it to switch into full-screen mode:

If you click the "Click for Full Screen" text, the application will switch into full-screen mode - which will hide everything else running on the system and take over the entire screen:

When you switch into full-screen mode, Silverlight will display a user message blurb that will pop-up on the screen for a few seconds and instruct the user that they can press the escape key to switch back into browser mode. After a few seconds this message will disappear and only your content will be visible. In my sample above I also allow the user to click on the "Click to Return to Browser" text and switch back into browser mode as well.

Walkthrough the Simple Full Screen Mode Code

The code to implement the above sample is pretty simple.

To begin with we can open and edit the root .XAML file for the application, and add a UI element to it that we want to use to trigger the full-screen mode. In the sample above I used a control that I named "MyMessage". Below is all of the XAML for the entire application:

The below screen-shot shows the code-behind for the .XAML file above - and contains all of the code for the entire application:

Within the application's Page_Loaded() event handler above I am wiring up two event handlers:

MyMessage_MouseLeftButtonDown - This event handler will execute anytime a user clicks on the TextBlock message control I added into my XAML file. Within this event handler I'm simply toggling the BrowserHost.IsFullScreen property to true or false depending on whether or not it is already in full screen mode.

BrowserHost_FullScreenChange - This event handler will execute anytime Silverlight switches between full screen and browser mode. It provides a good place to add logic to update the UI when this happens. In the example above I am changing the text on the TextBlock control. I could also have optionally resized controls and/or moved them around the screen to new coordinate positions. Currently the Silverlight 1.1 Alpha doesn't have layout manager support, so controls won't automatically re-position unless you write code to manage this yourself (don't worry - layout manager controls for Silverlight like in the desktop WPF version are coming).

In addition to the IsFullScreen property, BrowserHost class has a number of additional properties and events that are very useful:

The ActualHeight and ActualWidth properties are particularly useful to lookup the screen dimensions when you switch into full-screen mode - which you can then use when positioning and scaling your UI controls on the page.

Summary

Supporting full-screen mode within Silverlight applications is pretty easy to enable, and offers the ability to provide a nice, immersive user experience.

To learn more about Silverlight, please read my comprehensive Silverlight announcement post as well as visit the www.silverlight.net community site.

To watch me walkthrough building a Silverlight application from scratch using .NET and Visual Studio "Orcas", please watch this video here.