Microsoft AppFabric Caching (non-Azure version)

Lately I've been researching Microsoft AppFabric Caching services as a way to manage session over an ASP.NET web farm. There are other options out there for handling shared session across load balanced web servers, but this is perhaps the newest one I've seen. By new, I mean it was officially launched on June 7th, 2010. AppFabric Caching grew up (in beta) under the name Velocity and has material on their old/dead blog dating back to June of 2008, so at least the concept has been around a while. At any rate, I was turned onto this technology by a coworker (our DBA in fact) and I've been able to spend a few cycles looking into it.

For anyone starting to look into this product here are a few links that may help.

1. The main AppFabric product page: http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
2. Another “Main” page: http://www.microsoft.com/windowsserver2008/en/us/app-main.aspx
3. AppFabric Installation Word Doc: http://go.microsoft.com/fwlink/?LinkID=184618
4. Managing Security for client access: http://msdn.microsoft.com/en-us/library/ff921012.aspx
5. Configuring ASP.NET: http://msdn.microsoft.com/en-us/library/ee790859.aspx
6. AppFabric on Twitter: http://twitter.com/appfabric
7. AppFabric Web Farm Guide: http://bit.ly/9u1vum

 

 

 

 

 

Posted via email from A Bit of Everything

What is Chrome trying to tell me?

This is the first time I've seen this little icon. Seems ominous. I believe it means that I have both secure and insecure content, but who knows, right?

Posted via email from A Bit of Everything

The Joy of Browser Testing

One of the things I dispise the most in web application development is testing different browsers. Firefox 2, Firefox 3, Safari 4, IE7, IE8, and my most hated browser IE6. I suppose now I also include the iPhone, Blackberry, Android (or MyTouch or whatever you call it now), and Palm. However, I put my displeasure aside simply because I have to. I can't be too upset since things continue to improve (think NN4 or IE5.5), but I sure don't love it.

Well, the joy of testing won't ever go away but a couple of coworkers of mine have shown me a tool that has helped tremendously (thank you Craig and Eric!). Xenocode has a browser emulation tool that has worked very well for us. Considering that you can't have IE6, IE7, and IE8 all installed on one system (same with some other browsers), a developer was left with one ugly choice...multiple systems. Multiple systems can be sliced several ways. From physical systems to dual boot or virtualization, the fact is that you have to maintain a lot for very little benefit. In fact, Microsoft even provides a monster virtual system downloads to support IE6, IE7 or IE8.

Enter Xenocode. I haven't dove into their virtualization and streaming methodology, but I can say that they have saved me time and energy maintaining other systems for testing. It does take a bit of time to get the the engine rolling (10 minutes or so the first time). For me, it's very worth the wait. Give it a shot sometime you want to view the world with IE6, Firefox 2, or Opera.

Posted via web from A Bit of Everything

Ugly .Net Bug - asp:hyperlink

Recently, my crew and I ran across one of those painful bugs that takes up too much time. Ultimately, we marked it up to an ASP.NET problem. Here are the details.

We have several environments set up at work ranging from our local/developer system to our production system. In only one of our environments, the navigation in our application would disappear when a postback would occur. We use master pages and several user controls throughout the site. However, since nearly every page that performed a postback experienced the problem, we narrowed our search to the master page. Why didn't we just attach and run the application in debug mode you ask? Well, as it turns out the local environment did not exhibit the behavior. Talk about bringing debugging back to the 90s.

Further logging and testing limited the focus to the Page_Load inside the master page. Setting test points throughout the method, we narrowed it down to some extremely inconspicuous code. Here is an example of that code (obviously not the real code):

hlNav1.NavigateUrl = hlNav1.NavigateUrl.Contains("xyz") ? hlNav1.NavigateUrl : hlNav1.NavigateUrl + "&xyz=123";
hlNav2.NavigateUrl = hlNav2.NavigateUrl.Contains("xyz") ? hlNav2.NavigateUrl : hlNav2.NavigateUrl + "&xyz=123";
hlNav3.NavigateUrl = hlNav3.NavigateUrl.Contains("xyz") ? hlNav3.NavigateUrl : hlNav3.NavigateUrl + "&xyz=123";
hlNav4.NavigateUrl = hlNav4.NavigateUrl.Contains("xyz") ? hlNav4.NavigateUrl : hlNav4.NavigateUrl + "&xyz=123";
hlNav5.NavigateUrl = hlNav5.NavigateUrl.Contains("xyz") ? hlNav5.NavigateUrl : hlNav5.NavigateUrl + "&xyz=123";

As it turns out, we tried several variations of that code. Checking for null, empty, converting to an if statement, blah blah blah. We even wrapped the code above in an "if (!Page.IsPostBack)," to no avail. Here is where it gets interesting. The first time this code executes, it works perfectly. However, in this particular environment, the code blanks out any child entities when you replace the NavigateUrl (only during a postback). We had a <div> inside of each asp:HyperLink which ended up being nuked.

The solution, get rid of asp:HyperLink and use a plain old <a href="" runat="server">. How Glamorous.

At any rate, I hope this keeps someone else from burning time.

Posted via email from A Bit of Everything