I was drawn to an interesting question on StackOverflow recently about how to override a request for a non-existent .svc request using routing.

One useful feature of routing in ASP.NET is that requests for files that exist on disk are ignored by routing. Thus requests for static files and for .aspx and .svc files don’t run through the routing system.

In this particular scenario, the developer wanted to replace an existing .svc service with a call to an ASP.NET MVC controller. So he deletes the .svc file and adds the following route:
routes.MapRoute(
"UpdateItemApi",
"Services/api.svc/UpdateItem",
new { controller = "LegacyApi", action = "UpdateItem" }
);

Since api.svc is not a physical file on disk, at first glance, this should work just fine. But I tried it out myself with a brand new project, and sure enough, it doesn’t work.

Baffling!

So I started digging into it. First, I looked in event viewer and saw the following exception.

System.ServiceModel.EndpointNotFoundException: The service '/Services/api.svc' does not exist.

Ok, so there’s probably something special about the .svc file extension. So I opened up the machine web.config file located here on my machine:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config

And I found this interesting entry within the buildProviders section.
type="System.ServiceModel.Activation.ServiceBuildProvider,
System.ServiceModel.Activation,
Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
/>

Ah! There’s a default build provider registered for the .svc extension. And as we all know, build providers allow for runtime compilation of requests for ASP.NET files and occur very early in response to a request.

The fix I came up with was to simply remove this registration within my application’s web.config file.





...

Doing that now allowed my route with the .svc extension to work. Of course, if I have other .svc services that should continue to work, I’ve pretty much disabled all of them by doing this. However, if those services are in a common subfolder (for example, a folder named services), we may be able to get around this by adding the build provider in a web.config file within that common subfolder.

In any case, I thought the question was interesting as it demonstrated the delicate interplay between routing and build providers.

By now, you’re probably aware of a serious ASP.NET Vulnerability going around. The ASP.NET team has been working around the clock to address this. Quite literally as last weekend, I came in twice over the weekend (to work on something unrelated) to find people working to address the exploit.

Recently, Scott Guthrie posted a follow-up blog post with an additional recommended mitigation you should apply to your servers. I’ve seen a lot of questions about these mitigations, as well as a lot of bad advice. The best advice I’ve seen is this - if you’re running an ASP.NET application, follow the advice in Scott’s blog to the letter. Better to assume your site is vulnerable than to second-guess the mitigation.

In the follow-up post, Scott recommends installing the handy dandy UrlScan IIS Module and applying a specific configuration setting. I’ve used UrlScan in the past and have found it extremely useful in dealing with DOS attacks.

However, when I installed UrlScan, my blog broke. Specifically, all the styles were gone and many images were broken. It took me a while to notice because of my blog cache. It wasn’t till someone commented that my new site design was a tad bit bland, that I hit CTRL+F5 to hard refresh my browser to see the changes.

I looked at the URLs for my CSS and I knew they existed physically on disk, but when I tried to visit them directly, I received a 404 error with some message in the URL about being blocked by UrlScan.

I opened up the UrlScan.ini file located:

%windir%\system32\inetsrv\urlscan\UrlScan.ini

And started scanning it. One of the entries that caught my eye was this one.
AllowDotInPath=0 ; If 1, allow dots that are not file
; extensions. The default is 0. Note that
; setting this property to 1 will make checks
; based on extensions unreliable and is
; therefore not recommended other than for
; testing.

That’s when I had a hunch. I started digging around and remembered that I have a custom skin in my blog named “haacked-3.0”. I viewed source and noticed my CSS files and many images were in a URL that looked like:

http://haacked.com/skins/haacked-3.0/style/foo.css

Aha! Notice the dot in the URL segment there?

What I should have done next was go and rename my skin. Unfortunately, I have many blog posts with a dot in the slug (and thus in the blog post URL). So I changed that setting to be 1 and restarted my web server. There’s a small risk of making my site slightly less secure by doing so, but I’m willing to take that risk as I can’t easily go through and fix every blog post that has a dot in the URL right now.

So if you’ve run into the same problem, it may be that you have dots in your URL that UrlScan is blocking. The best and recommended solution is to remove the dots from the URL if you are able to.

Wow! It’s been a busy two months and change since we released Preview 1 of ASP.NET MVC 3. Today I’m happy (and frankly, relieved) to announce the Beta release of ASP.NET MVC 3. Be sure to read Scott Guthrie’s announcement as well.

Yes, you heard me right, we’re jumping straight to Beta with this release! To try it out…
Install it immediately via the Web Platform Installer (Web PI).
OR, Download the Installer files and install it manually.

As always, be sure to read the release notes (also available as a Word doc if you prefer that sort of thing) for all the juicy details about what’s new in ASP.NET MVC 3.

A big part of this release focuses on polishing and improving features started in Preview 1. We’ve made a lot of improvements (and changes) to our support for Dependency Injection allowing you to control how ASP.NET MVC creates your controllers and views as well as services that it needs.

One big change in this release is that client validation now is built on top of jQuery Validation in an unobtrusive manner. In ASP.NET MVC 3, jQuery Validation is the default client validation script. It’s pretty slick so give it a try and let us know what you think.

Likewise, our Ajax features such as the Ajax.ActionLink etc. are now built on top of jQuery. There’s a way to switch back to the old behavior if you need to, but moving forward, we’ll be leveraging jQuery for this sort of thing.
Where’s the Razor Syntax Highlighting and Intellisense?

This is probably a good point to stop and provide a little bit of bad news. One of the most frequently asked questions I hear is when are we going to get syntax highlighting? Unfortunately, it’s not yet ready for this release, but the Razor editor team is hard at work on it and we will see it in a future release.

I know it’s a bummer (believe me, I’m bummed about it) but I think it’ll make it that much sweeter when the feature arrives and you get to try it out the first time! See, I’m always looking for that silver lining. ;)
What’s this NuPack Thing?

That’s been the other major project I’ve been working on which has been keeping me very busy. I’ll be posting a follow-up blog post that talks about that.
What’s Next?

The plan is to have our next release be a Release Candidate. I’ve updated the Roadmap to provide an idea of some of the features that will be coming in the RC. For the most part, we try not to add too many features between Beta and RC preferring to focus on bug fixing and polish.

NuPack is a free open source developer focused package manager intent on simplifying the process of incorporating third party libraries into a .NET application during development.

After several months of work, the Outercurve Foundation (formerly CodePlex Foundation) today announced the acceptance of the NuPack project to the ASP.NET Open Source Gallery. This is another contribution to the foundation by the Web Platform and Tools (WPT) team at Microsoft.

Also be sure to read Scott Guthrie’s announcement post and Scott Hanselman’s NuPack walkthrough. There’s also a video interview with me on Web Camps TV where I talk about NuPack.

Just to warn you, the rest of this blog post is full of blah blah blah about NuPack so if you’re a person of action, feel free to go:
Download the latest build right away.
Read the Getting Started page to learn how to use it.

Now back to my blabbing. I have to tell you, I’m really excited to finally be able to talk about this in public as we’ve been incubating this for several months now. During that time, we collaborated with various influential members of the .NET open source community including the Nu team in order to gather feedback on delivering the right project.
What Does NuPack Solve?

The .NET open source community has churned out a huge catalog of useful libraries. But what has been lacking is a widely available easy to use manner of discovering and incorporating these libraries into a project.

Take ELMAH, for example. For the most part, this is a very simple library to use. Even so, it may take the following steps to get started:
You first need to discover ELMAH somehow.
The download page for ELMAH includes multiple zip files. You need to make sure you choose the correct one.
After downloading the zip file, don’t forget to unblock it.
If you’re really careful, you’ll verify the hash of the downloaded file against the hash provided by the download page.
The package needs to be unzipped, typically into a lib folder within the solution.
You’ll then add an assembly reference to the assembly from within the Visual Studio solution explorer.
Finally, you need to figure out the correct configuration settings and apply them to the web.config file.

That’s a lot of steps for a simple library, and it doesn’t even take into account what you might do if the library itself depends on multiple other libraries.

NuPack automates all of these common and tedious tasks, allowing you to spend more time using the library than getting it set up in your project.
NuPack Guiding Principles

I remember several months ago, Hot on the heels of shipping ASP.NET MVC 2, I was in a meeting with Scott Guthrie (aka “The Gu”) reviewing plans for ASP.NET MVC 3 when he laid the gauntlet down and said it was time to ship a package manager for .NET developers. The truth was, it was long overdue.

I set about doing some research looking at existing package management systems on other platforms for inspiration such as Ruby Gems, Apt-Get, and Maven. Package Management is well trodden ground and we have a lot to learn from what’s come before.

After this research, I came up with a set of guiding principles for the design of NuPack that I felt specifically addressed the needs of .NET developers.
Works with your source code. This is an important principle which serves to meet two goals: The changes that NuPack makes can be committed to source control and the changes that NuPack makes can be x-copy deployed. This allows you to install a set of packages and commit the changes so that when your co-worker gets latest, her development environment is in the same state as yours. This is why NuPack packages do not install assemblies into the GAC as that would make it difficult to meet these two goals. NuPack doesn’t touch anything outside of your solution folder. It doesn’t install programs onto your computer. It doesn’t install extensions into Visual studio. It leaves those tasks to other package managers such as the Visual Studio Extension manager and the Web Platform Installer.
Works against a well known central feed. As part of this project, we plan to host a central feed that contains (or points to) NuPack packages. Package authors will be able to create an account and start adding packages to the feed. The NuPack client tools will know about this feed by default.
No central approval process for adding packages. When you upload a package to the NuPack Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.
Anyone can host a feed. While we will host a central feed, we wanted to make sure that anyone who wants to can also host a feed. I would imagine that some companies might want to host an internal feed of approved open source libraries, for example. Or you may want to host a feed containing your curated list of the best open source libraries. Who knows! The important part is that the NuPack tools are not hard-coded to a single feed but support pointing them to multiple feeds.
Command Line and GUI based user interfaces. It was important to us to support the productivity of a command line based console interface. Thus NuPack ships with the PowerShell based Package Manager Console which I believe will appeal to power users. Likewise, NuPack also includes an easy to use GUI dialog for adding packages.
NuPack’s Primary Goal

In my mind, the primary goal of NuPack is to help foster a vibrant open source community on the .NET platform by providing a means for .NET developers to easily share and make use of open source libraries.

As an open source developer myself, this goal is something that is near and dear to my heart. It also reflects the evolution of open source in DevDiv (the division I work in) as this is a product that will ship with other Microsoft products, but also accepts contributions. Given the primary goal that I stated, it only makes sense that NuPack itself would be released as a truly open source product.

There’s one feature in particular I want to call out that’s particularly helpful to me as an open source developer. I run an open source blog engine called Subtext that makes use of around ten to fifteen other open source libraries. Before every release, I go through the painful process of looking at each of these libraries looking for new updates and incorporating them into our codebase.

With NuPack, this is one simple command: List-Package –updates. The dialog also displays which packages have updates available. Nice!

And keep in mind, while the focus is on open source, NuPack works just fine with any kind of package. So you can create a network share at work, put all your internal packages in there, and tell your co-workers to point NuPack to that directory. No need to set up a NuPack server.
Get Involved!

So in the fashion of all true open source projects, this is the part where I beg for your help. ;)

It is still early in the development cycle for NuPack. For example, the Add Package Dialog is really just a prototype intended to be rewritten from scratch. We kept it in the codebase so people can try out the user interface workflow and provide feedback.

We have yet to release our first official preview (though it’s coming soon). What we have today is closer in spirit to a nightly build (we’re working on getting a Continuous Integration (CI) server in place).

So go over to the NuPack website on CodePlex and check out our guide to contributing to NuPack. I’ve been working hard to try and get documentation in place, but I could sure use some help.

With your help, I hope that NuPack becomes a wildly successful example of how building products in collaboration with the open source community benefits our business and the community.

One of the most anticipated features of WordPress 3.0 was the ability to add your own custom post types to WordPress, which allows you to display and categorize different types of content outside of the 5 native WordPress content types (i.e. Post, Page, Attachment, and so forth). The addition of this feature is a big step forward in making WordPress a full-fledged CMS, extending outside its normal use as a blogging platform.

In this guide, we’ll go through the process of creating and using your own custom post type. More specifically, we will create an "Event" post type for your special events and dates, sort of like a calendar.
What is a Custom Post Type?

If you’re familiar with WordPress, then I’m sure you’ve already had some exposure to the default WordPress post types used for content creation: Post and Page. Almost all of the content in any WordPress site prior to 3.0 is composed of some combination of posts and pages.

Posts are generally used for content that is updated frequently (blog posts, for example), and pages are generally used for static content (such as the About page of a site).

Often, however, you may have a more specific type of data that you want to include on your site. This is where custom post types come in.

We’re going to create a custom post type that we’ll call "Event". This content type will let us add events such as birthdays, holidays, conference dates, and so forth.

We’ll be working with the default TwentyTen theme that comes with WordPress 3.0 so that we have a uniform code base, but the concepts and techniques will be applicable to any theme.