The Microsoft Web Farm Framework is a free product that enables you to easily provision and mange a farm of web servers. It enables you to automate the installation and configuration of platform components across the server farm, and enables you to automatically synchronize and deploy ASP.NET applications across them. It also supports integration with load balancers – and enables you to automate updates across your servers so that your site/application is never down or unavailable to customers (it can automatically pull servers one-at-a-time out of the load balancer rotation, update them, and then inject them back into rotation).
The IIS Search Engine Optimization Toolkit makes it easy to analyze and assess how search engine friendly your web-site is. It pinpoints SEO violations, and provides instructions on how to fix them. You can learn more about the toolkit and how to best take advantage of it from these links:
- IIS Search Engine Optimization Toolkit Home (including download link)
- Walkthrough: Using Site Analysis to Crawl a Website
- Walkthrough: Using Site Analysis Reports
- Carlos Aguilar Mares’ IIS Search Engine Optimization Blog Post (he is the guy who built it!)
The IIS Search Engine Optimization Toolkit is free, takes less than a minute to install, and can be run against any existing web-server or web-site. There is no need to install anything on a remote server to use it – just type in the URL of the site and you’ll get a report back a site analysis report with actionable items that that you can use immediately to improve it.
With the release of URL-rewrite module for IIS 7.0 and the inclusion of ASP.NET routing into the .NET Framework 3.5 SP1, there have been a lot of questions from ASP.NET developers about how these two features relate to each other and when to use each.
Differences between URL Rewriting and ASP.NET Routing
Based on the above explanation you can see that the main conceptual differences between URL rewriting and ASP.NET routing are the following:
- URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
- ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are the following functional differences between IIS URL rewriting and ASP.NET routing:
- The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
- The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
- The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
- In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
- The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.
Which Option Should You Use? Read more @ IIS URL Rewriting and ASP.NET routing : Using URL Rewrite Module : Installing and Configuring IIS 7.0 : The Official Microsoft IIS Site
IIS UR Rewriting
An Introduction to URL Rewriting
One of the greatest things about dynamic Web sites is the fact that you can build one page and based on the parameters that are passed to that page it can display any number of different results. For example, let’s say that you’re building a Web-based grocery store. Instead of creating a separate static HTML page for each category of product you carry, you can simply create a single
Category.aspxfile and pass it a parameter indicating what category of products you want to display:
While the resulting Web pages are all generated by the single script, they’ll each display a very different lists of items. This type of power is great for us as developers, but it’s not so good for users and even worse if you’re trying to get the pages indexed by search engines. While I created the examples above to be as user-friendly as possible, they’re still not all that simple to the average user. These are simpler and much more intuitive:
So, ever since developers started building dynamic pages and confusing users and search engines, people have been trying to find a way to get the best of both worlds. One of the most common solutions is URL rewriting. URL rewriting is where a user can request a page via the user-friendly URL:
and the Web server figures out to actually use the the script located at:
to build and return the resulting Web page.
Introducing Microsoft URL Rewrite Module for IIS 7.0:
The first step is to make sure you can use the module. You’ll need to make sure you’re running IIS 7.0 or later (which means Windows Server 2008 or Vista). You’ll also need interactive access to the server to run the install routine. If you meet the above requirements, you can download the version of the module that matches your server’s platform from the IIS 7.0 Web site:
Shared Hosting, VPS, Dedicated Server
Dmitry has posted the new source code for Cassini v2.0. Very cool stuff if you would like to learn how to build a web server that hosts ASP.NET
New to Cassini v2:
- Cassini v2 uses new ASP.NET v2 hosting APIs (System.Web.Hosting: ApplicationManager, IRegisteredObject, etc.).
- Grab the Cassini web server source code from Dmitry’s website.
Note: You may also want to check out UltiDev’s own incarnation of Cassini which runs as a Windows Service and comes with a easy distribution package for Visual Studio 2005
The more I delve into distributed architectures, the more I’m feeling like Microsoft just isn’t providing much of a path forward to scalable distributed systems. Case in point: state management.
By default, session state in ASP.NET is stored in the web server’s memory. To share state across servers – which you would want to do in a server farm – you need to store it in SQL Server or in the .NET state service. This is fine for small solutions, but once you bump up against the need to partition state across many servers or multiple hosting locations, things start to get complex and expensive.
Using JavaSpaces from .NET
3rd Parties: ScaleOut, NCache, GigaSpaces
As of Jan 2nd 2008