As hardware costs drop, and the need to control IT costs increases, we’ve noticed that colocation is becoming a viable option for many small and medium-sized businesses (SMB). Whether you're using a Microsoft or Linux-based system,  here’s the bottom line:

Dedicated server(s): You’re renting servers from someone on a server-by-server basis.

With dedicated servers, you pay a premium for not worrying about the hardware: If there are any hardware issues, someone else replaces/fixes it.

Colocation: You’re renting space for your server from someone.

In the case of colocation, you get an allotted amount of physical space in a facility that provides your hardware with power and bandwidth, as well as an ideal environment (e.g. climate control, power supply management, facility security), but what you put in your space is up to you.

What’s Best for You?

Of course, there’s no "one-size-fits-all" answer, but here are some things to consider:

1. In general, for short-term projects (less than a year), dedicated servers are cheaper and easier. But if your hosting requirements are more than two years in duration, you’ll likely see significant cost-savings in going with colocation.
2. In the past, it used to be that if you needed only one or two servers, and after factoring for Microsoft license costs, you were left with the non-choice choice: You went dedicated. But today, with MS Small Business Server, and Essential Business Server being really cost-effective alternatives for SMB, we’ve seen a dramatic shift. Now, you can run a Small or Essential Business Server offsite using colocation, which is something that many dedicated server providers won't do for you. This has dramatically shifted the landscape for SMBs looking to implement MS server solutions.
3. Also, a lot depends on your technical experience and abilities. If you, or a member of your team, is comfortable with computers, then colocation is a reasonable choice. If you know and/or care little about servers, switches, networking, and firewalls, then you may need to factor in the cost of outsourcing this portion of your IT administration.
4. Finally, if you want to have physical access to your machine, then colocation is the obvious answer for you. More...

If you are anything like me, then you spend a significant amount of your professional life thinking about "what ifs". What if a system's user does this? What if a hacker does that? What if the good people at Google mistakenly sell FeedBurner to some evil people, who in-turn take my redirected RSS (or ATOM) blog or news feed hostage?

Whether your using Wordpress, BlogEngine.NET, or another syndication CMS, many administrators look at moving their feeds to FeedBurner to monetize their feed using AdSense, or to gain access to some great syndication and analysis tools.  Some of these people happily redirect their subscribers directly to FeedBurner's feeds at http://feeds.feedburner.com, without a second thought. 

BE FOREWARNED: If at some point you are unhappy, and decide to leave, you can't simply redirect your feed elsewhere, again. This would be known as "committing blogicide", as you won't be taking your old subscribers with you; you're just redirecting the new subscribers. This is obviously less than ideal.

As it stands today: Don't worry, you may be OK. If you decide to leave FeedBurner, as of this post's publish date, the good people at Google have provided tools to transfer your feed elsewhere. Having said this, if you've linked directly, you'll be relying on their system to exist in the future to do the transfer. Everything else being equal, I'd prefer to have control, rather than give it away and rely on someone else. After all, it's my feed. I should own it.

Here's how you keep control of your feed:

1. Determine if your hosting provider will allow you to create a CNAME entry in your site's DNS records. This may sound complicated, but it's not. If you're using a shared hosting account, you may be able to do this through your control panel, or you may have to email your helpdesk to do it for you. Check you provider's knowledge base, or email their helpdesk directly to get a straight answer.
2. You'll also need to be able to add subdomains to your site. It is common to name your feed subdomain something like "feeds.mysite.com" or "rss.mysite.com". You don't need to add the subdomain, yet. We'll do this in step 5. But, if you are in doubt about if/how to do this, check it out with your helpdesk, too.
3. If step 1 & 2 are doable, log into your Google's FeedBurner account. If you haven't already set up a FeedBurner feed for each of your existing feeds, do so now. Just so there is no confusion, I'm going to rephrase what we're doing here: In this step we're telling FeedBurner where you currently publish your xml feed files on your site.
4. While still logged into FeedBurner,  go to My Account > Services > MyBrand. Here you'll find the critical CNAME entry snippet. It will look something like:
   
   
   feeds CNAME xxxxxx.feedproxy.ghs.google.com
   
   
   where "xxxxxx" will be replaced by your FeedBurner account's unique ID. More...

Intro | Part 1 | Part 2

So we're on the third instalment of this three-part tutorial series, where you and I are building an AJAX Contact Us form in ASP.NET, a couple of different ways. If you need a recap, here are the links to the introduction and the partial-page updates method. In this article we’re going to put the "less is more" principle into action by initiating our network callbacks directly from client-side JavaScript code, and we'll also build an AJAX-enabled web service to handle our call. As in Part 1, I’m going to assume that you are comfortable using Visual Studio.

You can download the source files for this project AJAXEnabledContactForm.zip (45.6 kb).

So we're going from partial-page updates using the asp:UpdatePanel, to network callbacks through a web service using HTML controls. The main reason you'd go this way is to drastically reduce your data transfer between the client and server. And why is this? Well, for two reasons: First, unlike partial-page updates, we're not passing all the form's data back to the server, just the required parameters in an XML wrapper. Second, we're not executing the page's full life-cycle back on the server from the postback, either. So if you're looking for efficiency, this is the way to go.

We'll be continuing on with the project that we created in Part 1, which we called “AjaxEnabledContactForm”. Let's start with the our web service, which is going to provide the service methods that our Contact Us form calls. So I`ve created a new web service called "ContactUs.asmx". Since we've already seen the some of this code in Part 1, I'll give you the full page first, and then we'll walk through it.

The nice thing about doing our Contact Us form through a web service is that we can have both as a separate applications in our production evironment, so if there is a problem in our main application, the service is still available for other applications, or vice-versa. More...

Intro | Part 1 | Part 2

As promised in the intro of this three-part series, you and I are going to build an AJAX Contact Us form in ASP.NET, a couple of different ways. Today we’re going to look to Visual Studio’s built in ASP.NET AJAX controls to do dynamic partial-page updates, and we’ll leave client-side network callbacks through a web service for a future post. To keep things moving, I’m going to assume that you are comfortable using Visual Studio. If you need to brush up, there are some great tutorials at ASP.NET.

You can download the source files for this project AJAXEnabledContactForm.zip (46 kb).

To start, I created a new AJAX Enabled Web Application in Visual Studio (you can find the free Visual Studio Express Edition here). I called the project “AjaxEnabledContactForm”, but you can call it whatever you want.

Next, I implement a Specified Pickup Directory method to test our contact form, and allow our web app to save notification emails to our c:\Temp\ folder. You can find the specifics of adding this to your own project in my post on The SMTP Alternative, but to keep this short, the code you need to add to your web.config file is as follows:

Now, we need a page for our Contact Us form. I created a new page, called it "PartialPageUpdate.aspx", and added the following content to the body. More...

Out of the box, Visual Studio is a wonderful environment for creating and testing ASP.NET applications. This includes Microsoft's free Express Edition, which is, as some of you know, a great place to start building sites. One thing that can be challenge to test are a site's email related subroutines. A standard and effective approach is to configure the SMTP server on your test machine. Unfortunately, if you send a project to somebody that doesn't have the identical SMTP test environment set up (which is pretty much never), you're going to have problems.

If you only need to test that your project can create an email, an alternative is to use the Specified Pickup Directory method, which simply has your test environment save the email, instead of actually sending it. To accomplish this, you need to add or replace the default mail settings in your project's web.config file:

As you can probably guess, you can change the pickup directory for your email to anything you want, but take note: The directory has to exist, otherwise you'll get an error. This is particularly important if you are sending your project to somebody else, and don't want them to be stuck debugging your application. So, the temp folder is actually a decent place to store and access test emails.

The great thing about using the Specified Pickup Directory method is that you can use your production email settings throughout the project, and simply swap out the web.config mailSettings when your done testing. You can also send your email enabled projects to somebody else and have it work as expected.

Specified Pickup Directory is not a silver bullet, because sometimes you actually do want to do a test send, as opposed to just saving the email. However for most situations, particularly preliminary testing, this method will probably fit your needs.

Happy emailing,
James Fielding

Intro | Part 1 | Part 2

When it comes to building a Contact Us page in ASP.NET, then a page with a form tag, some text boxes, and a submit button is the classic and straightforward way to go. If this isn’t what you want to hear, then you’ve come to the right place.

Sure, a simple form may be the easiest, and arguably a more secure way of collecting user feedback, but it just doesn’t have that AJAX sparkle...and what’s the fun in that?!! Over the next two blogs, I’m going to be building an AJAX Contact Us form in ASP.NET using two different methods:

1. Using Visual Studio’s built in ASP.NET AJAX controls to do dynamic partial-page updates.
2. Using client-side network callbacks through a web service.

Just a couple of disclaimers before we start: I’m going to keep this as simple as possible, so let’s just say that the UI design is basic, the database/email hookup will be incompete, and we won’t be dealing with any major security concerns. So you’ll obviously want to bolster things before you drop this into a production environment. The point of this is not to provide an enterprise-class solution, but to give you a step-off point to building a great system.

Having said that, let’s get going with Partial Page Updates.
James Fielding

In ASP.NET, we often use site maps to set up navigation, particularly for menus. By default, the ASP.NET  site-map provider  uses the "Web.sitemap" file. Here is an example of this file for a simple site:

So our basic menu will look like this: More...

Have you ever been left scratching your head after getting an error like this:

Configuration Error
Parser Error Message: Could not load file or assembly 'MyUnrequiredAssembly' or one of its dependencies. The system cannot find the file specified. (C:\Inetpub\wwwroot\child\web.config line 89)

It’s common to have child sub-applications under the root application in an ASP.NET web site. It’s also common to have inheritance problems in a child because of what’s in the root application’s web.config file. To stop the child application from throwing a configuration error, you’ll often find that the previous developer has added assemblies to the GAC, or to every child application’s /bin folder in addition to the root folder’s /bin. You’ll also see similar stop-gap fixes with other resources, particularly in the App_Theme folder. Fortunately, if you are running at least .NET 2.0, or better, there’s a number of ways to fix things that won't throw the next guy working on the site for a loop.

The simplest way to handle this is to:

1. Remove the offending assembly in the system.web section of the child application's web.config file.

If you can't seem to get rid of the offending assembly, check for httpModules:

Sometimes, it is easier to start the child application with a clean slate. In that case: More...

Yesterday, I attended a training session, where Derek Brown from Pronto Marketing shared some advanced strategies for SEO with us. Derek’s presentation was great…amazing in fact. One of the items that he breezed by, but seemed to really emphasize, was hCards and how Google and Microsoft have really starting to embrace microformats in general. I’d heard about microformats before, but had not really taken the plunge. Having said this:

Microformats are a practical way to make data items (such as events, contact details or geographical locations) recognizable to Search Engines, without breaking existing page formatting that is easily read by humans. This is done by adding a set of "class" attributes that can be added to divs and spans in an HTML page to tag content with semantic meaning. For example, my hCard looks like a standard block of text:

To get this, I used the following HTML:

Adding this small amount of markup can have significant SEO results. Moreover, you can style this block with CSS by using the class names directly, or by adding a second styling class like this to any of the tags: More...

“What will happen if the date/time on a machine is reset or is in a different time zone?” is a question that we sometimes run into, particularly from professionals whose documents are particularly date/time sensitive. Fortunately, this question can easily be handled by setting up one or more virtual machines.

Having said this, out of the box, Virtual PC virtual machines synchronize their date with the date of the hosting operating system. This means that no matter what control panel you alter in the guest OS, the date/time reverts back to the host OS settings, which can be really frustrating. To prevent this default action from occurring, you can add the following XML section to the .VMC file for the image that you’d like to desynchronize:

Happy testing,
James Fielding