Pfft, I'm sure I'm not infected.
Don't be so certain. F-Secure is calling the attack's scope "amazing," having infected 6.5 million PCs in four days, and compromising almost 9 million total computers in its first two weeks on the Internet. Such a widespread outbreak has not been seen in many years.
Really? How could I have contracted this horrible virus?
Conficker gets into your system through a bug in a service that runs on Windows Server family operating systems. This means that if you use Windows 2000, Windows XP, Windows Vista, Windows Server 2003, or Windows Server 2008, you have been vulnerable to this worm.
Microsoft did release a security patch for this exploit back in October, but some reports say that up to half of vulnerable Windows machines have not been updated to use the latest security updates. Did you? Do you remember if you did? I do not.
Dammit. Maybe I do have it. What does this thing do?
Simply put, Conficker is a worm and what it does is try to spread to other machines. It has a few ways of spreading to other systems, but the most powerful way, which sidesteps many of the known security solutions as well as disabling Windows Automatic Update, Windows Security Center, Windows Defender, and Windows Error Reporting, does not activate until April 1st (tomorrow!).
So, if you have it now, it probably tried to spread to some other machines. If you have it tomorrow, your security is screwed and you're going to be contributing to a much more massive spread than the current epidemic. It is also rumored to be able to download new malware to your system.
Whoa! How do I get rid of it?
I thought you'd never ask.
To start with, get the update from Microsoft that fixes the security hole. Otherwise, you're just going to be infected again tomorrow. In fact, everyone should make sure they have this to immunize themselves!
To actually clean the virus, use the Malicious Software Removal Tool from Microsoft, or (if you think Microsoft software is malicious enough) you can get a cleaning tool from Symantec.
Aliases and More Information
Conficker is also known as W32/Conficker, "Downup", "Downadup", and "Kido". How do people come up with these things?
More information is available from McAfee at their Virus Alert page.
What is URL rewriting and why should I care?
As I said before, URL rewriting is a practice that lets you publish a cleaner URL to the world, but that may not be clear. In other words, you can "point" or redirect any URL a user accesses to an existing ASP.NET page in your application. Take a look at this URL:
http://www.joshjordan.com/index.php?i=321
That is my standard, ugly URL. Now look at this one, which is the result of URL rewriting:
http://www.joshjordan.com/google-chrome-beta-20-released-321
Which one looks better to your eye? Probably the second one. It gives the user some important information about what might be on that page. Which one looks better to a search engine? Definitely the second one. Search engines actively try to ascertain information about the contents of a page based on many criteria, and the URL is no exception. Google, Yahoo, and Live Search all pull common keywords out of the URL, and if you want traffic on your site (and lets face it, who doesn't?), you want to have a good page ranking with these search engines. Search engine optimization is a rapidly changing field, but providing search engine-friendly URLs is a practice that is going to consistently drive traffic to your site by making your page's search relevancy higher.
One worry that you may have is that we are only redirecting the user to a new page with URL rewriting. This would result in a few problems. Firstly, the URL shown in the user's browser would change to the ugly URL as soon as the access the page, and thus, our highly-guarded secret is exposed. Worse, they might link that URL to another person, which means they are giving out the ugly URL, and our effort would've been wasted. Finally, a search engine would see both the clean URL and the ugly URL, which could result in splitting your page ranking between the two of them. Don't worry, your ugly URL will not be exposed. URL rewriting in ASP.NET (at least the way I'll show you) does not redirect the HTTP request to another page, it actually answers the request at the clean URL with one from whatever page you'd like, all without any knowledge of the rewriting on the user's side.
Okay, URL rewriting is a good idea. How do I do it?
Well, that's simple. Just call the HttpContext.RewritePath() method from the Application_BeginRequest() event handler in your Global.asax file. What is that you say? You don't have a Global.asax file? Okay, I'll walk you through an example.
I am currently working on a project where my site has a county-based taxonomy. That is, the main page for a county is the primary unit of organization. Thus, I want to provide a provide a URL that includes the name of the county. Unfortunately, my otherwise well-designed data driven application will only provide me with something like this by default:
http://www.myproject.com/County.aspx?ID=5
However, I'd like it to look something more like this (for my home county of Rensselaer):
http://www.myproject.com/Rensselaer
I could, of course, just make a directory or Aspx page for Rensselaer, but I already have my application working so nice and cleanly! I don't want to create more pages that I have to maintain. So, I choose to use URL rewriting to handle this situation.
To get started with URL rewriting, create a Global.asax file. A Global.asax file is a set of event handlers for application-level events, such as client sessions beginning, client sessions ending, and (ah-ha!) URL requests beginning. To create this file, add a new file to your project and select Global Application Class. Leave the filename to its default.
Note that you will be unable to select Global Application Class if a Global.asax file already exists in your project. Now that we have this file, we want to add code to the Application_BeginRequest() event handler that handles our URL rewriting. In this example, I will simply route based on the contents of the incoming URL. If the URL contains one of my keywords, I will route it appropriately. If not, I will do nothing and the request will be processed normally (either landing on some existing page, or producing a 404 error).
protected void Application_BeginRequest(object sender, EventArgs e)
{
//Friendly URL keywords
string[] counties = { "Albany", "Rensselaer", "Montgomery" };
//Loop through keywords
for(int i=0; i<counties .Length; i++)
{
//Check to see if the URL contains this keyword
//Remember to use case-insensitive logic!
if (Request.Url.ToString().ToLower().Contains(counties[i]))
{
//If a keyword was found, rewrite and break out
Context.RewritePath("~/County.aspx?CountyID=" + i);
return;
}
}
}
I use the string.Contains() method and a string array in this simple example. I route to the indices of the string in the array. Note that the incoming URL could have a mix of capital and lowercase letters, so you should always use string.ToLower() when performing comparisons in this case. In a more realistic example, a Dictionary of strings and integer ID's may be necessary, or even a connection to a database to retrieve keywords. Some useful objects you should play with to extract data from the incoming request:
- Request.URL: The entire incoming URL, used above.
- Request.QueryString: The parameters, provided as key-value pairs, beyond the "?" in the URL. Note that this object has string and int-based indexers.
- Request.URL.ToString().Split('/'): A string array split into tokens based on forward slashes. This is useful because it allows you to look at the individual directories and files requested beyond the domain.
Advanced Routing
Since you can write any code you like in the Application_BeginRequest() method, there is a lot you can do here. As I mentioned, you could use values from a database, or parse the URL into multiple different pieces to control your routing. If there is sufficient demand, I will write another few articles that talk about advanced topics in URL rewriting, touching up on those topics as well as setting up virtual directories, preserving the query string, handling image requests by wrapping them with HTML, efficiency in URL rewriting, etc. Please give me some feedback if you want more!
Other URL rewriting methods for ASP.NET
Other methods exist for URL rewriting, but I didn't mention them here both because I haven't tried them and because they seem much less ideal than the solution I gave above. If you are looking for other ways to do this, be on the look out for rewriting using the Request.PathInfo object, which uses a URL that looks something like this (which is still ugly to me):
http://www.myproject.com/county.aspx/Rensselaer
There are Web.config approaches, but they are less programmatic and do not give you dynamic control over your routing. I want to write code to do this! If I was doing it statically, I might as well just use new Aspx pages. Finally, you can use ISAPIRewrite to have your IIS server do the routing for you. Again, this is too static for me. For more information on these approaches, check out this amazing post on Scott Guthrie's blog.
Notes
I just wanted to point out what a big deal URL rewriting is becoming these days by pointing out that it is one of the main concepts behind the ASP.NET MVC framework approach. Every ASP.NET MVC tutorial I've seen has started with the routing module, which provides a facility for automatically tokenizing the URL into separate pieces to decide how to route the request to the View, including default values for each piece. Can you tell I'm excited about ASP.NET MVC?
The beta stamp was removed from Google Chrome back in December of 2008, but they have a new release and that stamp has come out of retirement. Google Chrome 2.0 (actually, 2.0.169.1, if you're curious) was released on March 17th, and has some cool new features:
- form autofill
- full page zoom
- autoscroll
- side-by-side view for tabs
- a big speed increase
Form autofill is probably the most anticipated feature on my wishlist. Form autofill is where your browser records your form input (for non-password fields) and gives you a list of items to choose from when filling in a similar form in the future. It actually uses the HTML client id of the text box to determine what previously entered items to show you, so it's at least marginally intelligent. It may not seem like much, but once you're used to it from Internet Explorer or Firefox, form autofill is tough to live without. It used to save me a lot of time, and I'm looking forward to finally using it again with Chrome. More information on autofill at Google Chrome Help.
Full page zoom is an improvement over the fairly standard text-based zoom offered by most browsers. When you use full page zoom, both text and images are scaled up or down. It didn't make sense for the browser to disciminate between those two anyway, did it? This is a good accessibility feature.
I suppose you're wondering what I meant by side-by-side view for tabs. Google Chrome 2.0 will allow you to drag a tab out of the main tab bar on your browser, just like Chrome 1.0 did (which happens to be a feature I love). However, now, if you hover your cursor over the middle left or right side of another tab, Chrome will automatically lay out your tabs next to one another. This is great for comparison, or referencing some material while doing data entry in another tab. Still don't know what the hell I'm talking about? Watch this video provided by Google:
Ah, I mentioned a big speed increase. Here's are the benchmarks Google provided when they released Chrome 2.0:
Pretty impressive. Will it really go that fast? Who knows. They are claiming it is between 25 and 35% faster than their current stable version. I'm looking for an even bigger speed increase, though, because I was using the old beta. I can be slow to adapt sometimes.
I did run into an issue during install where the version of Chrome that the installer ran when complete was still my old version. Restarting and running the installer again solved it, though. If you think you're having the same problem, find out what version you are using by opening the about box like so:
On the window that appears, look for version 2.0, shown here:
That's it! I'm looking forward to whatever the Chrome team has in store for us in the future. There are still some standard features that Chrome is lacking, but they are catching up, and continually delivering fun, new ideas for browsing.
Links
The Google Chrome blog entry annoucing Beta 2.0 on March 17th.
Download Google Chrome Beta 2.0
I recently wrote an article about the release of the ASP.NET MVC Framework that was released on the same day. Like the ASP.NET MVC release, the Web Platform Installer (or Web PI) release was announced at Mix '09. Again, good timing here on Microsoft's part that allowed them to get this beta version out to lots of people that will be downloading new stuff (ASP.NET MVC and Silverlight 3, just to name a few).
Mix '09 is an annual conference on web design and web development. The 2009 conference was held March 18th to March 20th in Las Vegas. Microsoft made a few announcements regarding new product releases this year. A vast amount of information from the conference is available at the main Mix '09 website.
I actually didn't realize initially that the Web PI 2.0 beta came out today (although I should've, since it was mentioned in the haacked article I found the link on). So, I opened up the Web PI site and stared at it for a moment. Should I download 1.0 or 2.0 beta? Decisions, decisions. I decided to shoot the breeze and go for the new stuff.
Using Web Platform Installer 2.0 beta
Hold on. So you want me to download and install a program to... download and install stuff?
I know, I know. I was skeptical, too. But hey, live a little! If this is the biggest risk you're taking this week, you need to get out more.
So I downloaded & installed Web Platform Installer 2.0 beta and was greeted with this elegant, web 2.0-reminiscent screen:
I like what I see so far. I downloaded this thing so that I could install ASP.NET MVC, and there it is. Good. I'm also intrigued by this "SQL Server 2008 Management Studio Express" thing. I know I've heard of it before, but it was probably when I was in shock from seeing so many SQL Server tools, and was thus ignored. I noticed there was a little blue information icon, so I clicked on it.
Cool. A little information the tool was just what I needed. With this in hand, I can decide whether or not I want to install this thing (I did). One other thing I just noticed while writing this: the release date listed is 3/17/2009. The guys over at Microsoft must've been working their asses off to get all this stuff out in time for a release simultaneous with Web PI and Mix '09.
Clicking "Web Platform" on the left gives me a better list of stuff I can install (and a better idea of what this "Web Platform" encompasses. Components are listed in these categories: Web Server, Frameworks and Runtimes, Database, and Tools.
This is cool, but I notice that the checkboxes indicate a partial install for a few of those items. What happens if I click on this "Customize" link? Hmm...
Ah, there we go. That's what I was looking for. They really hit this one out of the park. I really like the granular control here. A lot of these IIS components are not necessary for my local development machine, but I am itching to run Web PI on the server sitting in my closet and make sure it has all the components I want it to have. Web PI seems to provide a great one-stop solution for installing most of what you need on your server without having to remember them or hunt them down on the web.
After clicking on "Install," you have to agree to the various license associated with the products you selected. Blindly clicking right through that, I find the installation screen:
Nice. It is intelligent enough to start installing as soon as the first component is downloaded, and continues to download the other packages while it does so. I like. My download speed may be a bit high here, but the download went much faster than the installation. That's pretty much what I've come to expect from Microsoft though - long installs are just part of the territory.
My (eventually) installation finished and I was presented with this final screen confirming the components that were installed successfully. Woohoo!
The Silverlight Debacle
You'll notice above that my "Silverlight 3 Tools for Visual Studio Beta" install unfortunately failed. I must admit that I left a bit out before so that the article flowed well, but there's no hiding it from you now, is there?
When I first tried to select to install the Silverlight 3 tools, I was greeted with this error message:
Oh, come on. The tool is not smart enough to give me an automatic or one-click uninstall of Silverlight 2 in order to install Silverlight 3? Wait, why is that even necessary? Boo.
So I head over to my Add/Remove Programs panel and uninstall my "Microsoft Silverlight 2 SDK." Nope. Not it. Still getting the error. Digging a little deeper, I find a rather cryptically labelled Visual Studio 2008 SP1 tools for Silverlight 2 (I can't remember the wording exactly). I uninstalled this, too, and then I was able to proceed with my Silverlight 3 tools installation, which means that the first thing I uninstalled was wrong. Great.
So, of course, after Web PI was finished, I got the failure message shown way above. I clicked on the log, which was a not-so-useful, but that's okay. Maybe this is because I uninstalled the wrong Silverlight component, or maybe this piece is a half-baked. In either case, it could use some lovin', but I do understand that this is Web PI 2.0 beta, so I won't complain (much).
Web PI refused to install the Silverlight 3 tools for me, and I ended up grabbing them from here.
Keeping up-to-date with Web PI
One of the selling points about Web PI is that it will let you keep your Web Platform components up-to-date. How does it do this, you ask? I was wondering, too. I opened up Web PI again to look for the answer, and found the answer staring back at me:
Simple enough! Web PI loads its list of Web Platform software everytime you run it. So, all you need to do is run Web PI periodically to make sure you have the latest versions and all the fun, new stuff Microsoft has been putting out lately.
Now I understand the Web PI model a little bit better, too. At first, I was surprised that Microsoft wanted me to download this program I would only use once (like you were, because of that question you asked, remember?) However, now I see that they want you to run it frequently and have it installed for future occassions when you want to download Web Platform goodies. Clever. If you're having trouble finding Web PI on your Vista machine, try typing "web platform" into your Start Menu, like so:
Final Thoughts
Overall, I liked what I saw. As a developer, the idea of having a tool to keep my tools up-to-date is appealing. As an adminstrator, having a one-stop-shop tool I can run on my server to get all the components I need is appealing. Barring the issues I had with the Silverlight 3 tools (which I'll chalk up to this being a beta release), I give it two thumbs up. I look forward to the release candidate.
Download the latest Web Platform Installer from Microsoft.
It's good timing, too. If you're like me, you were waiting for the beta to end before really getting into ASP.NET MVC because you were afraid that each release would break your projects. Between preview 2 and preview 3, for example, the MVC architecture changed drastically due to community feedback. Well, I guess its time to really dive in and I'm excited to do it.
ASP.NET MVC still has a long way to go. For example, we can expect to see fun stuff like design mode support and the ability to use controls declaratively in ASP.NET MVC 2.0. I know those sound like essential features, but they are part of the problem that ASP.NET MVC tried to address by providing the developer with tighter control over their markup. Plus, you can always instantiate a control and call its rendering method if you want to use it so badly.
This announcement was made at Mix '09 today by Scott Guthrie, the same guy who wrote the e-book tutorial I recently wrote about. If you're interested in learning more about ASP.NET MVC, check out the website here.
Download
You probably want the download link. Very greedy of you. Well, fine. Here you go: Download ASP.NET MVC Framework 1.0 from Microsoft
*No software is ever done.
When I say "fade," I mean that I want to color an image based on another. Some people call this blending, or simply layering one image on top of the other and setting the opacity/transparency of the upper image. I'm not really sure what the formal term for it is, but this is basically accomplished by averaging the pixel values between the two images where they overlap. Don't be intimidated if you're unfamiliar with images or pixels - read on. The effect produced is pretty cool.
Up until now, I hadn't used any image manipulation classes in .NET, but I had done some simple image splicing in Java (using the excellent Graphics package). So, I was excited to see what facilities were going to be provided by .NET for doing similar operations. Honestly, I didn't even know what class to use, so I set out by dropping a PictureBox control onto a Windows Forms application. One of the properties I saw in the Property Editor for this control was the Image property, which was of type System.Drawing.Image. Bingo!
I switch to my C# code and set about creating an Image instance. Now, if I know the .NET framework (and I do), I'd be willing to bet System.Drawing.Image is an abstract base class, but its a good starting point nonetheless. Indeed, creating an instance using the new keyword fails because, as expected, it is an abstract class.
The next thing I generally do is check to see if there is a static Factory method within the base class that will create an instance for me. I type Image. (note the dot) and let Visual Studio's Intellisense go to work for me.
It looks like the FromFile() method will do what I want. I call this method with the filename of an existing image, and move on to the next line. Again, I will use my trusty Intellisense to find out what I can do with this Image object. To my horror, I find that the Image class does not provide me any information about the pixels (individual colored dots) in the underlying image, nor does it show the robust list of image transformations I expected to be able to perform. Hell, it doesn't even let you set the Width and Height properties. Who are you, and what have you done with .NET?
This is obviously going to take a little bit more research. You might've noticed in the first screenshot that the abstract Image class provides functionality for its descendants (as is the purpose of an abstract class), including System.Drawing.Bitmap. I was in a sporting mood, so I decided to check out the class hierarchy. Normally, this would be done using a combination of the Object Browser and the Image class summary, which gives us the hint that its descendent classes are System.Drawing.Bitmap and System.Drawing.Imaging.Metafile. However, an addin I use called Resharper allows me to right click on the Image class in my code and find all types that derive from it, like so:
This confirms that Bitmap and Metafile are the only classes that inherit from Image in the .NET framework. I refer to the Object Browser again to inspect these classes, starting with Bitmap.
From this, I can see that the Bitmap class is intended to be used where it is necessary to work with pixel data, and also that it has methods for getting and setting individual pixels (as well as some of the other more complicated image manipulation behavior I expected to see in Image). This looks promising, so I can move forward from here by instantiating both of my Images as Bitmaps, and attempting to fade their pixel data together.
Given that I have two Bitmap objects that I want to fade together, aptly named image1 and image2, I can use the following code to "average" the overlapping area of the images:
for (int i = 0; i < image1.Width &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; i < image2.Width; i++)
{
for (int j = 0; j < image1.Height &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; j < image2.Height; j++)
{
Color image1Pixel = image1.GetPixel(i, j), image2Pixel = image2.GetPixel(i, j);
Color newColor = Color.FromArgb((image1Pixel.R + image2Pixel.R)/2, (image1Pixel.G + image2Pixel.G)/2, (image1Pixel.B + image2Pixel.B)/2);
image1.SetPixel(i, j, newColor);
}
}
Let me walk you through what's going on here. Each Bitmap is essentially a two-dimensional array of pixels (represented in your code by a System.Drawing.Color object). Thus, we use a nested loop to iterate through them. Note that our for loop will only proceed while both i and j are within the bounds of both images. This will make our code look a little nice by not requiring us to check if each pixel we extract is within its image's bounds (the code can be easily extended to handle non-overlapping areas, if required). Anyway, within our loops, we extract the pixels present in both images at our current position to Color objects by calling GetPixel(i,j) on each image. Then, we construct a new Color object using the Color.Argb() factory method. The overload of the Argb() method I used takes in three integer parameters: a red, a green, and a blue, to determine the overall color of the pixel. These are given by the R, G, and B integer properties of the two Color objects we created, so we simply average them, respectively. Finally, we set the pixel value at that location with this new Color object (I arbitrarily chose to do so in image1 here, overwriting its contents).
Simply enough, yes? This will give us a nice overall average for the two images, or what I'm calling the "fade" effect. Since this worked out so nicely, what if we got a little bit deeper? The project I'm doing actually requires my "fade" effect to be weighted heavily in favor of one of the images, which is the same as giving less transparency to the image that is laid on top of the other. I know that my idea of averaging the two pixel values worked out just fine, so I should be able to calculate a weighted average just as easily, given some parameter to tell me how strongly to do so.
I extracted this code to a static method in another class. It could've been done simply with a helper method, or by subclassing Bitmap, but I prefer to have this helper class present in case I decide to add any further functionality. I specify that I'll take two Bitmap objects and an integer parameter, which will represent how heavily to weight the first image over the second. I have also changed the code to be slightly more "proper," in that I create a new Bitmap object instead of changing image1's data. Finally, you'll see that I compute the new RGB values using a weighted average algorithm, where the original values are multiplied by their weights and their sum is divided by the total weight.
I thought for a moment here about whether or not I could get an integer overflow here. However, it turns out that image file formats store, at most, 32-bits of information per pixel. Since these 32-bits are divided up across the red, green, and blue components of the pixel, we are usually going to be working with 8-bit integers (which range from 0-255). The int data type is 32-bit, so we should never run into this problem.
The updated code looks like this:
public static Bitmap Fade(Bitmap image1, Bitmap image2, int opacity)
{
Bitmap newBmp = new Bitmap(Math.Min(image1.Width,image2.Width), Math.Min(image1.Height,image2.Height));
for (int i = 0; i < image1.Width &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; i < image2.Width; i++)
{
for (int j = 0; j < image1.Height &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; j < image2.Height; j++)
{
Color image1Pixel = image1.GetPixel(i, j), image2Pixel = image2.GetPixel(i, j);
Color newColor = Color.FromArgb( (image1Pixel.R * opacity + image2Pixel.R * (100 - opacity) ) / 100, (image1Pixel.G * opacity + image2Pixel.G * (100 - opacity) ) / 100, (image1Pixel.B * opacity + image2Pixel.B * (100 - opacity) ) / 100);
newBmp.SetPixel(i, j, newColor);
}
}
return newBmp;
}
One thing to note in the code that will call this method is that you no longer need to use the Image.FromFile() method. If you do, you'll have to cast that Image instance down to Bitmap, like so:
pictureBox1.Image = ImageFader.Fade((Bitmap) Image.FromFile(label1.Text), (Bitmap) Image.FromFile(label2.Text), trackBar1.Value);
Instead, you can use the more natural Bitmap constructor:
pictureBox1.Image = ImageFader.Fade(new Bitmap(label1.Text), new Bitmap(label2.Text), trackBar1.Value);
Well, that about wraps it up. I didn't touch the rather robust GDI+ Graphics class (which is what I was familiar with from Java), and it certainly isn't the fastest code I've ever written. However, for a first stab at the problem, I am pretty happy to have such a simple solution. I'll look more into using a Graphics object to speed up execution in the future, but for now, if anyone has any suggestions on improving this code, I'm all ears (eyes?) Here's a screenshot of the Windows Forms application I built to test this algorithm out:
Download
The source code and Windows binary for this project can be downloaded here: Image Fader Windows Forms Project
Links
Since the .NET framework is closed source, check out the Microsoft Developer's Network for class documentation and examples:
Anyway, I use Resharper so that article caught my eye. Phil Haack points out that there was recently a hotfix made to Visual Web Developer and Visual Studio to allow ASP.NET MVC to play nicely with add-ins such as Resharper, Azure, Power Commands, etc. He didn't talk about what problems people were having that prompted the fix, but he did mention that it isn't working for all add-ins.
Digging a bit deeper, I found that people were getting crashes in Visual Studio and Visual Web Developer when viewing pages in design mode, or just trying to install ASP.NET MVC. Apparently this was all taken care of with a CLR fix. Thanks Visual Web Developer blog!
So, if you're having any problems with ASP.NET MVC, or you use Visual Studio add-ins and are planning on using ASP.NET MVC in the future, I recommend you download and install this hotfix from Microsoft connect here.
Scott is a Corporate Vice President at Microsoft, and heads up the teams for ASP.NET, Silverlight, IIS, and so forth. He's also been working pretty closely with ASP.NET MVC, so I was really interested in what he did with this tutorial. While there are a number of how-to videos out there on ASP.NET MVC, the end-to-end (full application) tutorials are few and far between, so I was really excited to see this posted.
The tutorial itself shows you how to create the aptly named "NerdDinner" application, whose purpose is to enable themed social gatherings. I haven't gotten all the way through it yet myself, but I've liked the parts that I've done a lot. Scott does a good job walking you through the application and explaining why he's doing what he's doing. This is a good way to have ASP.NET MVC laid out for you in a logical way that shows the importance of the features it gives you. Scott starts by building the data model, and then moves right on to the controllers and the views. A real gem here, though, is his section on CRUD, which really highlights some of the cool ways ASP.NET will save you a little time now, and a lot of time later. Check it out.
As a slight aside, I also really appreciate the way the book shows screenshots and textual (ie. copy-and-pastable) code with Visual Studio syntax highlighting. This book is a model of how I want my own tutorials to look. For example, see how he highlights each click and gives you full code below? I admire his ability to do that so succintly.
This e-book is actually the first chapter of an ASP.NET MVC book that Scott has been working on alongside Scott Hanselman, Phil Haack, and Rob Conery. The publisher agreed to release the first chapter for free in exchange for Scott writing this chapter for free. Go figure. If you're interested in the full book, it is already listed on Amazon for pre-order.
Links
You can download the full e-book tutorial here as a 14mb PDF. The source code and unit tests are also provided. You can take a look at the pre-production Amazon listing for the book, and if you want to learn more about ASP.NET MVC (including video tutorials), check out the ASP.NET MVC site.
In this article, we'll look at some advanced use of events. Did you notice that in Part 2, I showed you how to create event handling methods for the default (most commonly used) event associated with a control, but never how to do so for other events? We'll get to that this time. In addition, we'll learn about postbacks (communication with the server that lets us handle events) and debugging with Visual Studio to understand what is happening within our application.
How will we learn this? I'm glad you asked. You're going to learn about these things the way I learned about them: trial by fire. Well, not really, I am going to purposefully lead you into a few problematic situations. Hopefully, this will get you thinking about why we ran into the problem and how to solve the problem. More importantly, it'll teach you to expect it and deal with it when you're creating your own applications. We're going to create a mock Employee Management application, similar to something your Human Resources department might use. Of course, we're going to limit it to some very small functionality: listing employees.
Create a new Web Application project in Visual Studio. If you don't remember how to do this, refer to Getting Started with ASP.NET Part 1. From here on out, you are free to use Source, Design, or Split mode in your IDE, but there will be certain times when one or the other is required. You should probably get used to moving between them, or using Split mode. In the Default.aspx page, drop in a DropDownList and a BulletedList. We'll use the BulletedList to list our employees out, and the DropDownList to filter them. We won't change any of the default properties in our ASPX page, so the markup should look similar to this (yes, I added some labels):
< %@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="PostbacksAndDebugging._Default" %>
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
Filter:
<asp :DropDownList ID="DropDownList1" runat="server">
</asp>
<br />
Employees:<asp :BulletedList ID="BulletedList1" runat="server">
</asp>
</div>
</form>
</body>
</html>
Switch to the C# code in Default.aspx.cs. As we did in the previous article, add some ListItems to the DropDownList's Items collection. In this case, add "Male", "Female", and "Both" to specify the filters that we'll use for our employee list. The goal here is to make it so that when the user makes a selection from this list, we will display only the employees that match those criteria. Since we've already taken discussed the page's Load event, I'll just skip right to showing you what my Page_Load() method looks like:
protected void Page_Load(object sender, EventArgs e)
{
DropDownList1.Items.Add("Male");
DropDownList1.Items.Add("Female");
DropDownList1.Items.Add("Both");
}
This straightforeward code will set up our DropDownList. If we ran the application at this point, we'd see that the list displays our options, but our application is not yet what we set out to create. Create two strings arrays in the page's class to hold the strings that represent employees of different genders. In a "real" application, I'd probably use a List of strings, or some other generic collection. Of course, if this were production code, we'd be using a database instead of simulated data. Let's keep things simple, though. Add some names (strings) to each array, as below.
public partial class _Default : System.Web.UI.Page
{
//Hardcoded data to simulate an employee database
string[] males = {"Robert","Johnathon","William"};
string[] females = {"Linda","Mary","Sarah","Barbara"};
Here's the interesting part. Switch back to Default.aspx and click on DropDownList1 while in Design mode. Take a close look at the Property Editor. Find the "Events" button, represented by a lightning bolt, and click on it.
Visual Studio will now show you the events that are associated with this control. We don't have to worry about most of them now, but do notice that it has a Load event, just like a page. In fact, although these events live in the Control class, the Page class inherits from Control, so pages are controls. Mind blowing, huh? For now, focus on the SelectedIndexChanged event. Since Visual Studio's description of the event is nearly useless, let me tell you that it occurs whenever a different item is selected from the drop down box. Double click in the box next to SelectedIndexChanged to automatically generate a method in the code-behind to handle this event.
In this method, we'll populate the BulletedList to match the filter selected in the DropDownList. Make sense? The code I've written to do this is listed below. It should read fairly easily if you're familiar with C#, but let me walk you through it. The first line of the method clears out any items that are already in the list. We must remember to do this because the event may occur more than once. That is, we must keep in mind the current state of the control which may already have some ListItems. Next, I check to see what value is selected in the DropDownList. Note that I originally wrote code that checked against each possible value ("Male", "Female", and "Both"), but it turns out that the "Both" option shares code with the other two, so I have simplified the conditionals. Based on that value, we loop through the appropriate string array(s) and create ListItems in the BulletedList for each employee. You can copy the code I've written into your code-behind by clicking on the "Copy" button in the top right of the code block.
using System;
namespace PostbacksAndDebugging
{
public partial class _Default : System.Web.UI.Page
{
//Hardcoded data to simulate an employee database
string[] males = {"Robert","Johnathon","William"};
string[] females = {"Linda","Mary","Sarah","Barbara"};
protected void Page_Load(object sender, EventArgs e)
{
//Add filters to the DropDownList
DropDownList1.Items.Add("Male");
DropDownList1.Items.Add("Female");
DropDownList1.Items.Add("Both");
}
protected void DropDownList1_SelectedIndexChanged(object sender, EventArgs e)
{
//Clear any previous values in the employee list
BulletedList1.Items.Clear();
//List male employees if applicable
if(DropDownList1.SelectedValue!="Female")
foreach(string employee in males)
BulletedList1.Items.Add(employee);
//List female employees if applicable
if (DropDownList1.SelectedValue != "Male")
foreach (string employee in females)
BulletedList1.Items.Add(employee);
}
}
}
So, our code is written and our application should work just fine, right? Let's run it (I shouldn't have to tell you by now, but press CTRL+F5).
Our DropDownList is populated correctly, but nothing appears to happen when we select an item from it. Hmm... I knew this wasn't going to work. This is because we have not triggered a postback with our DropDownList. A postback is when the entire page (by default) is sent back to the server, along with information about whatever event is taking place. Then, the server will make changes and send back HTML, much like when the page is initially loaded. Okay, I played a little trick on you here. DropDownLists don't cause postbacks by default because they are more commonly used simple as form choices, whose values are accessed during other events (like a button click).
However, we can enable postbacks on this control very easily. There is a boolean property of DropDownLists named AutoPostBack, which defaults to false. If we simply set it to true, the control will start causing postbacks and our event handler will run just as we expected. Set this to true using the property editor or the ASPX source.
Now, run the application again and you will see that it is functioning just as we expected.
Well, mostly. The first thing you'll notice is that nothing is shown in the employee list initially, even though "Male" is selected. This is behaving as we programmed it, believe it or not. The event we used was SelectedIndexChanged, so our method is only executed when the user makes a change to the DropDownList. To keep things simply, we're not going to fix that little "bug." You may or may not have noticed the other issue this application has. If not, try to make a second change to the DropDownList. You'll notice that each time our event handler occurs. What's up with that?
We're going to find out, using debugging. Visual Studio possess some powerful debugging tools. I won't get into all of them here - there will be another article that touches on the advanced features, like the Immediate Window. For now, know that debugging allows us to stop our code at each line, before it executes, so we can see what is going on in the application's memory. Why did this if-statement come out true? What numbers are being returned by that new method? Hell, why does our DropDownList have so many extra items? The debugger has your answer.
Switch to Default.aspx.cs. Click the margin next to the Page_Load() method header to place a breakpoint.
A breakpoint is a point in the applications execution that will be intercepted by the debugger. Now, any time the Page_Load() method is called, control will be given to the debugger. Since you control the debugger, this means you are in control of the execution, line by line, and you can find out what's going on. Run the application and see what happens. Whereas we were pressing CTRL+F5 before to Start without debugging, now press F5 to Start with debugging.
Internet Explorer appears, but before any HTML is rendered and sent to the browser, Visual Studio pops back up. The yellow arrow in the left margin shows the current point in the application's execution. None of the lines in the method have been executed yet. Since the page is still loading and we know that the DropDownList populates correctly initially, we expect that each of them will execute correctly. The debugging toolbar will help you control execution.
If the debug toolbar is not displayed in your IDE, enable it by clicking "Debug" on the View -> Toolbars menu, like this:
For now, press the play button (or F5) to return control to the application. Internet Explorer appears and the page is shown. Cause the event to occur by selecting a different item in the DropDownList.
Control will return to the debugger because the Page_Load() method is begin called again. Ah! This will shed some light on our problem. Press the Step Over button (F10) and watch what happens. The calls to DropDownList1.Items.Add() are repeated, even though DropDownList1.Items already contains data. Press F10 a few more times and you will see that the DropDownList1_SelectedIndexChanged() method is then called, as expected.
So, it makes sense that when Page_Load() is called a second (and third, and fourth...) time, the values are added to the DropDownList again, giving us those extra items in the list. But why is Page_Load() being called? The answer is not immediately obvious: the ASP.NET page lifecycle takes place everytime a page is generated, and a page is being generated anew during a postback. In other words, the page is not changing, it is being generated again, and therefore Page_Load() is called.
The fix for this is a simple one. Stop debugging by pressing Shift+F5. In the source code, add a check to the page's IsPostBack property before adding items to the DropDownList, like so:
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
//Add filters to the DropDownList
DropDownList1.Items.Add("Male");
DropDownList1.Items.Add("Female");
DropDownList1.Items.Add("Both");
}
}
There you go! Another run of the application will show that we have fixed this bug, thanks to the debugger showing us what was being executed.
The debugger is a powerful tool. We'll look at advanced debugging, combined with something called tracing in the future to better understand what's going on under the hood of our application. The lesson we learned about postbacks and the Page_Load() method is a useful one. Anytime we expact that postbacks will be occuring on our page, we must take care not to put any initialization code in Page_Load() that would not also be appropriate for a postback, unless we wrap it in the conditional shown above. We have also learned to write event handlers for any event that may be occuring for any control. This is a fundamental skill, because these events are the only points where we can inject our C# code to programmatically control the application. Furthermore, while the standard ASP.NET controls have few events, many third party controls have a very extensive list.
This concludes our three-part series on Getting Started with ASP.NET. I hope that it helps a few of you on your road to rapid application development using the powerful tools provided by ASP.NET, and I'm looking forward to any feedback you have.
Previous article: < < Getting Started with ASP.NET Part 2: Code-behind and Events
< %@ Page Language="C#" AutoEventWireup="true" Inherits="HelloWorld._Default" CodeBehind="Default.aspx.cs" %>
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp :Label ID="Label1" runat="server" Text="Hello World!"></asp>
</div>
</form>
</body>
</html>
If we examine line #1, we see that the page has an attribute called CodeBehind whose value is Default.aspx.cs. This indicates that there is a file by that name that holds the C# source code associated with this page (the extension would be .vb if we had selected a Visual Basic web application). Let's open that page up and see what it contains. In the Solution Explorer, double click on Default.aspx.cs. It may be necessary to expand the tree node (+) next to Default.aspx.
Doing so will present us with the (hopefully familiar) C# source code editor. We are shown one class, named Default, which inherits from a Page class, and has a single method, Page_Load(). This file is the code-behind for Default.aspx.
using System;
namespace HelloWorld
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}
In this code-behind file, we can write standard C# code to respond to various events associated with our page. We already see that an empty method has been created to respond to the page's Load event. This event fires as the controls on the page initialize, before their HTML is rendered and sent to the browser. Thus, we see that while we are used to writing procedural code, we will be writing largely event-driven code in our ASP.NET code-behind files. Add the following two lines to the Page_Load() method:
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("The current time is: ");
Label1.Text = DateTime.Now.ToString();
}
The first line invokes the Write() method of the implicit Response object, which contains data about the HTTP response that is sent to the client (HTML and metadata). When we write to this Response object, we add to the HTML the browser will see. We will use this to prove that the Load event fires before the page's controls are initialized. The second line sets Label1's Text property to the current time. From this, we see that each control placed on our page can be treated like an object in our code-behind. Note that the Text property is a string so we must turn the DateTime.Now object into a string in order to perform the assignment. Now, when the page is rendered, it should display the current time preceded by the string that we wrote to the HTTP response. Press CTRL+F5 to run the application, and you should see something similar to this:
Let's dig a little deeper to find out exactly what happened during the Load event, and when that event fired. View the source of the page that was sent to the browser. In Internet Explorer, this is accomplished as follows:
The source sent to the browser is as follows:
The current time is:
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>
</title></head>
<body>
<form name="form1" method="post" action="Default.aspx" id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUJOTczNTMyNjI5D2QWQg==" />
</div>
<div>
<span id="Label1">3/4/2009 10:12:13 PM</span>
</div>
</form>
</body>
</html>
Interestingly enough, the text we inserted into the HTTP response appears before any of the HTML code. This gives us a little information on when the Load event is fired, and confirms that it occurs before the HTML is rendered to the browser. This allows us to manipulate all the controls on our page and make modifications, preventing the client from ever seeing what their default values were. For instance, here we also change the label's text and that is displayed statically in the HTML. ASP.NET does not allow the client to see our code-behind or our ASP markup, so we are safe to write whatever logic we like.
There are many events that occur as the page is prepared and sent to the client. Load is one of them. We will examine these events further in an article about the ASP.NET page lifecycle, but for now, let's move on to handling some more interesting events. There are many events that can be generated by controls and then handled in our code-behind. We're going to pickup the pace a little bit, so if you're having trouble keeping up, refer to Getting Started with ASP.NET Part 1 to learn how to insert controls into your page.
Switch back to Default.aspx and add Listbox, TextBox, and Button controls to the page. To simplify things, we will not modify the ID (or variable identifier) of these controls, or touch their properties. In design mode, your form should appear like this:
If you'd like to copy-and-paste the code for the above, you may do so from the following code block. Overwrite the form1 element and its contents with this:
<form id="form1" runat="server">
<div>
<asp :Label ID="Label1" runat="server" Text="Hello World!"></asp>
<br />
</div>
<asp :ListBox ID="ListBox1" runat="server"></asp>
<br />
<asp :TextBox ID="TextBox1" runat="server"></asp>
<br />
<asp :Button ID="Button1" runat="server" Text="Button" />
</form>
Now, we have more controls to work with in our code-behind. Visual Studio will automatically generate the most commonly used event for a control if we double click on it in design mode. For a Button control, this would be the event corresponding to the Button being clicked. In design mode, double click on Button1 to generate the Button1_Click() method that will be called when the event fires.
Our goal is to make it so that when Button1 is clicked, an item is added to ListBox1 corresponding to whatever text is typed into TextBox1. This is done by calling the Add() method on the ListBox's Items collection with the value of the TextBox's Text property. Without doing any error checking, that code looks like this:
protected void Button1_Click(object sender, EventArgs e)
{
ListBox1.Items.Add(TextBox1.Text);
}
Run the application using CTRL+F5. Type some text in the empty TextBox, then click on the Button. The text should appear as a list item in ListBox like so:
You should be proud and excited that you were able to build such functionality in just one line of code (not counting markup). This could've taken 15+ lines in many other web application programming languages. One interesting thing to note is that when the Button is clicked is the time represented by Label1 is updated. This is because the page's Load event fires each time a request is made to the server, which means that the Page_Load() method must be called everytime our code-behind handles an event. This is a good segue into our next topic, Postbacks. In the final article in this series, we will learn about Postbacks by exploring some more advanced event handling, as well as learn to debug our ASP.NET web applications.
Previous article: < < Getting Started with ASP.NET Part 1: "Hello World"
Next article: Getting Started with ASP.NET Part 3: Postbacks and Debugging >>