ScioSoft's Community Blogs

Hosting Your Server: Dedicated vs. Colocation

ScioJim — Thu, 22 Apr 2010 16:21:00 -0400

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:

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.
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 most dedicated server providers can’t do for you. This has dramatically shifted the landscape for SMBs looking to implement MS server solutions.
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.
Finally, if you want to have physical access to your machine, then colocation is the obvious answer for you.

Other Things to Consider

There are a couple of points-of-confusion that seem to always come up in the dedicated versus colocation debate. Here's some clarification:

Bandwidth

This probably causes the most confusion when comparing dedicated to colocation. When you’re coming from managed hosting, you’re used to thinking about your bandwidth quota as the total transfer limit for the month calculated in gigabytes (GB). Denoting bandwidth usage this way helps non-network-savvy people understand exactly how much data they can move in a month, but as a network administrator, you’re really concerned with the amount of data moving through your pipe at any given second, or your Mbit/s rate.

As such, when you move into colocation, the provider sells you bandwidth based on how they're billed - per mbps transferred, typically measured using 95th percentile billing (see below). So, given a colocation 1 Mbit/s transfer rate, and having it running at the limit each second for a month, you’d theoretically end up with:

(1,000,000 / 8bits * 60s * 60m * 24h * 30.5days) / 1,000,000,000 = ~330GB/month

“But what about 1Mbit/s actually equalling 1024Kbit/s,” you say? Well, as it turns out in data communications, signal pulses and have historically been counted using the decimal number system, so a megabit is 1,000,000 bits and a kilobit is 1,000 bits.
Of course, colocation bandwidth limits apply to metered usage accounts. Some providers have unmetered bandwidth, which comes with a price tag to match this convenience.

95th Percentile Billing

The 95th percentile is the mathematical calculation most widely used to determine billings for variable rate or "burstable" network bandwidth connections. It works like this:

You subscribe to a colocation service that includes a network bandwidth allowance stated in Mbit/s. As such, you’re permitted to consume as much bandwidth as you wish up to this limit. Since most networks are oversubscribed, there is often some room for some bursting without advanced planning, when it comes time to bill you for your usage, your provider ignores the top 5% of your peak usage, and bills your bandwidth transfer rate at the 95th Percentile.

As long as your 95th Percentile transfer rate is at or below your bandwidth allowance, there are no additional fees. If, however, you exceed your allowance then you are invoiced for the additional bandwidth you consume.

For example, for 100 transfer rate samples, if the top 10 records were:

Top 10 Records	Sample Rate	Comment
100	2180 Kbps	Ignored (top 5%)
99	1970 Kbps	Ignored (top 5%)
98	1800 Kbps	Ignored (top 5%)
97	1560 Kbps	Ignored (top 5%)
96	940 Kbps	Ignored (top 5%)
95	920 Kbps	95th Percentile
94	880Kbps
93	850 Kbps
92	780 Kbps
91	720 Kbps

In this case, even though you sometimes sustained traffic at speeds as high as 2180 Kbps, your actual 95th percentile consumption was 920 Kbps. If your subscription included 1Mbit/s of network traffic then your usage is below your subscription allowance.

Hopefully this overview will help you implement the best hosting solution for your business.

Happy Hosting,
James Fielding

Feed Control: Redirect RSS feeds to FeedBurner and AdSense using CNAME

ScioJim — Thu, 25 Mar 2010 11:02:00 -0400

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:

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.
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.
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.
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.
Go back to your hosting provider and, using the snippet, set up your feed subdomain and add the CNAME entry to it. I can't really walk you through this, as it as the steps are going to be hosting provider specific, but your helpdesk should be happy to walk you through it. If not, find another provider.
You may need to wait a few hours for the CNAME entry to propagate. You'll know it's propagated when you type in your new subdomain's address in your browser, and the page looks like you've arrived at FeedBurner. It will probably be showing an error, since we haven't activated the MyBrand service, yet. If it still hasn't propagated after 24 hours, check to make sure that your CNAME entry is identically to Google's snippet, and seek out your hosting provider's helpdesk for assistance.
Return to FeedBurner's MyBrand, enter your newly created feed subdomain, and activate the service.
Redirect your site's feed subscription buttons through your new feed subdomain. For example if your FeedBurner blog feed is http://feeds.feedburner.com/mysiteblog, and your new subdomain was http://feeds.mysite.com, then you'd redirect to http://feeds.mysite.com/mysiteblog.

NOTE: You can create additional FeedBurner feeds and access them all through your feed subdomain. For example, if you also have a news feed for your site, you could burn your feed to http://feeds.feedburner.com/mysitenews, and then have your subscribers access it at http://feeds.mysite.com/mysitenews.

So now, to your subscribers, it appears that your site is hosting your FeedBurner feed.

The great news is, if you've already given up your feed by linking subscribers directly to FeedBurner, you can still implement a CNAME redirect. It won't get you back full control, but it will be good for new subscribers going forward, and you may be able to use FeedBurner's transfer tools to get everything back (I've never used the transfer tools, so if you do, let me know how this goes).

As you can see, not only have we future-proofed our feed, but we've given our site a professional-looking feed subdomain, and a feed address that is likely more user friendly, Moreover, we've also future-proofed ourselves: At some point, if you don't like your blog engine, it's no problem. Just swap it out. You'll need to relink your Feedburner feed, but your subscribers won't know the difference.

All in all, I'd say what we've done today isn't bad for an hours work.

Keep the power,
James Fielding

Build an AJAX Contact Us Form using network callbacks in ASP.NET

ScioJim — Thu, 18 Mar 2010 13:53:00 -0400

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.

Imports System.Web.Services
Imports System.Web.Services.Protocols
Imports System.ComponentModel

<System.Web.Script.Services.ScriptService()> _
<System.Web.Services.WebService(Namespace:="http://xmlforasp.net")> _
<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
Public Class ContactUs
    Inherits System.Web.Services.WebService

    <WebMethod()> _
    Public Function Submit(ByVal strEmail As String, ByVal strComment As String) As Boolean
        System.Threading.Thread.Sleep(5000)
        Return SendMail(strEmail, strComment)
    End Function

    Private Function SendMail(ByVal strEmail As String, ByVal strComment As String) As Boolean
        Dim mailMessage As System.Net.Mail.MailMessage = New System.Net.Mail.MailMessage()

        mailMessage.From = New System.Net.Mail.MailAddress("myserver@mysite.com")
        mailMessage.To.Add(New System.Net.Mail.MailAddress("me@mysite.com"))
        mailMessage.ReplyTo = New System.Net.Mail.MailAddress(strEmail.Trim())

        'Set additional options
        mailMessage.Priority = Net.Mail.MailPriority.Normal
        mailMessage.IsBodyHtml = False

        'Set the subjet and body text
        mailMessage.Subject = "Contact Us Form from: " & strEmail.Trim
        mailMessage.Body = strComment

        'Create an instance of the SmtpClient class for sending the email
        'using web.config settings
        Dim smtpClient As System.Net.Mail.SmtpClient = New System.Net.Mail.SmtpClient()

        Try
            smtpClient.Send(mailMessage)
        Catch ex As System.Net.Mail.SmtpException
            Return False
        Catch ex As Exception
            Return False
        Finally
            mailMessage.Dispose()
        End Try

        Return True
    End Function
End Class

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. Web services also lend themselves well to being configured to record submissions to a database. Note: Our setup could be significantly improved by making the service multi-tier, and dealing with the service's security, but what we've done today will definitely get you started.

So to step through this code, the first thing we did was make our service methods callable by JavaScript. That's why we added the following attribute:

<System.Web.Script.Services.ScriptService()> _

This magic little snippet allows the ASP.NET AJAX extension runtime to know that we're going to call our web method from JavaScript.

For our Submit web method, we've got:

System.Threading.Thread.Sleep(5000)
Return SendMail(strEmail, strComment)

So first we're faking network latency (so remember to take this out in production) by having the service sleep for 5 seconds, before proceeding to run our SendMail function. I'm not going to explain the SendMail function, because it is basically the same as what we saw in Part 1. The main difference is that instead of a subroutine, we've got a function that returns true if sending the email works out, and false if it doesn't.

At this point, you can test out the web service if you'd like, by firing up Visual Studio debugging, with ContactUs.asmx as the start page.

Great. So now we need a Contact Us page. We'll create a new .ASPX page and call it "NetworkCallback". The body tag for the page is as follows:

<body>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server" />
        <div>
            <span>Email</span><br />
            <input id="txtEmail" type="text" /><br />
            <span>Comments</span><br />
            <textarea id="txtComments" cols="20" rows="4"></textarea><br />
            <input id="btnSubmit" type="submit" value="submit" title="Submit"
                onclick="return btnSubmit_onclick()" />
        </div>
    </form>
</body>

So, the page looks exactly the same as before, except we've swapped out the ASP controls for HTML. We didn't have to do this, but since we've gone from partial-page updates to network callbacks, we might as well save the server processing on our controls, too.

Just for fun, and to give our users some AJAX feedback, let's throw some progress updates into our HTML, right below our submit button:

<div id="divWaiting" style="display: none">
    <img alt="UpdateProgress" src="Images/SquareCircleLoader.gif"
        style="width: 31px; height: 31px" />
</div>
<div id="divSuccess" style="display: none">
    Thank you for your submission.
</div>
<div id="divFailure" style="display: none">
    There was a problem with your request.
</div>

In the above code we've got three divs: The first one is displayed after the user has submitted the form, and is waiting for it to be processed by the server. The second is displayed after the form has been processed. The third shows up if there is a problem. By default, none of these divs are visible to the user, so we obviously we need to wire these divs up somehow. Here's the JavaScript that makes things happen:

So before my SEO friends jump all over me, I realize that I put the JavaScript in the <head> tag in the source file download. The JavaScript should really go just before the end </body> tag of NetworkCallback.aspx. My apologies...old habits really do die hard. One more thing, on error you'll get an alert box describing the error. This is a handy JavaScript snippet for troubleshooting, but remember to take it out before you drop this into production.

Now to bring this all together, we've got our one and only instance of the ScriptManager on the page, just after the form tag. In order for our ScriptManager to access our web service, the ScriptManager needs to know about the web service. And to do that, we just need to tell the ScriptManager where to find our web service, and it will take care of the actual implementation:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Services>
        <asp:ServiceReference Path="~/ContactUs.asmx" />
    </Services>
</asp:ScriptManager>

So let's just walk through this. When our user clicks the submit button, the contents of the email and comments text boxes are submitted to our web service asynchronously using XML, and our page tells the user to wait as something is happening. When the web service finally sends the email, the client is updated with the good news. If there is a problem, the user is also notified. We could also tie this into Part 1, by adding some JavaScript redirects to our Success.aspx and Failed.aspx pages, but I'll leave that for you to implement as you see fit.

Go ahead and give it a try running the NetworkCallback.aspx page. After you fill in the text boxes and click the submit button, you should get 5 seconds of progress.

This is followed by an email delivered to your hard drive at c:\Temp\ (as just like in Part 1, we're using the Specified Pickup Directory method to handle our email so you'll need to add that to the web.config if you're building your own project), and a message saying that everything went well.

Well, now you've got two ways of building that amazing AJAXified Contact Us page you've been dreaming about. As before, at a minimum, you MUST add some server-side validation/security before you contemplate dropping this code into production, otherwise you're leaving the door wide open to hackers. You may also want to look at securing your web service, or risk becoming a spammer's delight. It's not production code, but your definitely on the right path.

Happy network callbacking,
James Fielding

Build an AJAX Contact Us Form using partial-page updates in ASP.NET

ScioJim — Fri, 12 Mar 2010 20:13:00 -0400

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.

This gives us a very basic layout: An email text box, a comment text box, and a submit button.

You can add any other fields you need, but for our purposes, this is addequate. Of course, to use AJAX controls, remember to include the ScriptManager tag.

To give our form that AJAX feel, and to give the user some feedback, I also added an UpdateProgress control below the UpdatePanel:

<asp:UpdateProgress ID="UpdateProgress1" runat="server">
    <ProgressTemplate>
        <img alt="UpdateProgress" src="Images/SquareCircleLoader.gif" style="width: 31px; height: 31px" />
    </ProgressTemplate>
</asp:UpdateProgress>

Moving to the page's codebehind file, we'll have the server email us on each submission, although you could just as easily have the server write our form's contents to a database. To the page load event, I've added a 3 second lag, to imitate network latency, only on postback. The code is as follows:

Public Partial Class PartialPageUpdate
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        If Page.IsPostBack Then
            'Disable this setting in production
            System.Threading.Thread.Sleep(3000)
        End If
    End Sub

End Class

Why only postbacks? Well, we're not trying to demonstrate network latency when the page loads for the first time, hence the "only on postback". Obviously, you'll take out this line in a production environment. But more importantly, the notable thing about using the AJAX UpdatePanel, and arguably one of it's problems, is that when you use this control on a page, you actually get a full page postback. At first, this seems rather odd, as we only had the submit button in the UpdatePanel, but this is how the UpdatePanel works. This is the main reason why you might opt for a straight client-side network callback through a web service. However, as long as you're not expecting thousands of postbacks a day, it's probably not going to have a noticable impact on your bandwidth usage.

Next, we're going to handle the submit button's click event by adding the following code to our PartialPageUpdate class in the codebehind file:

Protected Sub btnSubmit_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnSubmit.Click
SendMail()
End Sub

Finally, we'll add the code that actually sends the email. I'm not going to walk through every line, as this is fairly standard email sending code, but I should point out that I've used a session variable to store any errors that are generated, to add some basic error handling and help us troubleshoot any problems.

Private Sub SendMail()

    'Create an error session variable
    Session("myError") = Nothing

    Dim mailMessage As System.Net.Mail.MailMessage = New System.Net.Mail.MailMessage()

    mailMessage.From = New System.Net.Mail.MailAddress("myserver@mysite.com")
    mailMessage.To.Add(New System.Net.Mail.MailAddress("me@mysite.com"))
    mailMessage.ReplyTo = New System.Net.Mail.MailAddress(txtEmail.Text.Trim())

    'Set additional options
    mailMessage.Priority = Net.Mail.MailPriority.Normal
    'Text/HTML
    mailMessage.IsBodyHtml = False

    'Set the subjet and body text
    mailMessage.Subject = "Contact Us Form from: " & txtEmail.Text.Trim
    mailMessage.Body = txtComments.Text

    'Create an instance of the SmtpClient class for sending the email
    'using web.config settings
    Dim smtpClient As System.Net.Mail.SmtpClient = New System.Net.Mail.SmtpClient()

    'Use a Try/Catch block to trap sending errors
    'Especially useful when looping through multiple sends
    Try
        smtpClient.Send(mailMessage)
    Catch ex As System.Net.Mail.SmtpException
        Session("myError") = ex
        Response.Redirect("/Failed.aspx")
    Catch ex As Exception
        Session("myError") = ex
        Response.Redirect("/Failed.aspx")
    Finally
        mailMessage.Dispose()
    End Try

    Response.Redirect("/Success.aspx")

End Sub

So let's just walk through this. When our user clicks the submit button, the page posts back to the server the contents of the email and comments text boxes asynchronously, and our UpdateProgress control tells them to wait as something is happening. When the asynchronouslypostback is complete, the user's browser is redirected to the Success.aspx page (a good thing) or the Failed.aspx page (which isn't good). So we just need to create two new pages, Failed.aspx and Success.aspx, and we should be good to go.

Go ahead and give it a try running the PartialPageUpdate.aspx page. After you fill in the text boxes and click the submit button, you should get 3 seconds of progress, followed by an email delivered to your hard drive in the c:\Temp\ folder, and a browser redirect to the Success.aspx page.

I hope this gets you started on building that amazing AJAXified Contact Us page you've been thinking about. As I said before, at a minimum, you MUST add some server-side validation/security before you contemplate dropping this code into production, otherwise you're leaving the door wide open to hackers.

Our next stop is building a network callback Contact Us form.

Happy partial-page contacting,
James Fielding

Test sending email on Localhost in ASP.NET: The SMTP server alternative

ScioJim — Thu, 04 Mar 2010 09:43:00 -0400

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

Build an AJAX Contact Us form in ASP.NET

ScioJim — Fri, 26 Feb 2010 13:47:00 -0400

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:

Using Visual Studio’s built in ASP.NET AJAX controls to do dynamic partial-page updates.
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

Referencing external URLs in your web.sitemap in ASP.NET

ScioJim — Tue, 23 Feb 2010 09:57:00 -0400

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:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap>
    <siteMapNode title="Home" description="Home" url="~/default.aspx">
        <siteMapNode title="Services" description="Services we offer" url="~/Services.aspx">
            <siteMapNode title="Consulting" description="Consulting services" url="~/Consulting.aspx" />
            <siteMapNode title="Support" description="Supports plans" url="~/Support.aspx" />
        </siteMapNode>
        <siteMapNode title="About Us" description="About Us" url="~/AboutUs.aspx">
            <siteMapNode title="Company" description="Our people and offices" url="~/Company.aspx" />
            <siteMapNode title="Blogs" description="Blogs from us to you"
              url="http://blogs.mysite.com/default.aspx" />
        </siteMapNode>
    </siteMapNode>
</siteMap>

So our basic menu will look like this:

Home
    Services
        Consulting
        Support
    About Us
        Company
        Blogs

Notice that the "Blogs" node in the "About Us" section references an outside URL. This is not a problem, until you start adding role-base security to the site. Specifically, once you set you securityTrimmingEnabled="true" in the Web.config or the Web.sitemap file, the "Blogs" node disappears, and you're left scratching your head.

Home
    Services
        Consulting
        Support
    About Us
        Company

At this point, you'll find that some developers get rid of the web.sitemap, and start hard coding menu items. However, there is a really easy fix for this behaviour. Just allow everyone access to the Blogs node so that it doesn't get trimmed:

By adding roles="*", we've got our blog back. That was almost too easy.

Just for completeness, I'm going to mention that we could have also just disabled the security trimming in the Web.sitemap file by adding securityTrimmingEnabled="false" to the Blogs node. Although I'm not a big fan of this method, as I find it makes the Web.sitemap less clear on what we're trying to accomplish, which is never good for the next guy working on the site, but the choice is yours.

Happy referencing,

James Fielding

Stop Web.Config settings inheritance in ASP.Net

ScioJim — Sun, 07 Feb 2010 19:16:00 -0400

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:

2. Clear all the assemblies in the system.web section of the child application's web.config file.

You can then go ahead and add the assemblies that the child application needs.

To take a different approach, you can also disable child inheritance in the root application:

3. Wrap the system.web settings of the root application web.config file in a location tag.

Finally, you can apply specific resources to child applications in the root web.config by using the 'path' attribute:

Happy inheriting,
James Fielding

Using hCard Microformats for SEO (Search Engine Optimization)

ScioJim — Thu, 04 Feb 2010 13:09:00 -0400

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:

James C. Fielding

Sciosoft Systems

1037 Langford Rd.

Baysville, ON, P0B 1A0 Canada

705-571-1123

To get this, I used the following HTML:

<div id="hcard-James-Fielding" class="vcard">
  <a class="url fn n" href="http://www.sciosoft.com">
    <span class="given-name">James</span>
    <span class="additional-name">C.</span>
    <span class="family-name">Fielding</span>
  </a>
  <div class="org">
    Sciosoft Systems</div>
  <div class="adr">
    <div class="street-address">1037 Langford Rd.</div>
    <span class="locality">Baysville</span>,
    <span class="region">ON</span>,
    <span class="postal-code">P0B 1A0</span>
    <span class="country-name">Canada</span>
  </div>
  <div class="tel">
    705-571-1123</div>
</div>

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:

One big note on CSS styling, don’t try to hide the hCard. In general, Google doesn’t take kindly to you wrapping things in style="display: none; " tags, and microformats are no exception.

To get started, you can try out www.microformat.org’s hCard Creator which formats the hCard HTML for you.

Besides hCards, there are a number of other microformat open standard specifications (including hCalendar, rel-license, rel-nofollow, rel-tag) that are in use, as well as many more (including geo, hAudio, hMedia, hNews, hProduct, hRecipe, hResume, hReview) at various stages of acceptance.

Another great thing about microformats is that they can be readily integrated into XML data sources, but I think I’ll leave that for a future discussion.

Happy optimizing,
James Fielding

Stopping a Virtual PC image from synchronizing the date with your host OS

ScioJim — Wed, 03 Feb 2010 10:53:00 -0400

“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:

<integration>
    <microsoft>
        ....
        <components>
            <host_time_sync>
                <enabled type="boolean">false</enabled>
            </host_time_sync>
        </components>
        ....
    </microsoft>
</integration>

Happy testing,
James Fielding