Thanks to staying at home with cold I had a chance to add a couple of new features to sdn5. I've also added a 'beta mode' so that they can be tested first. To enable the beta, just go to the http://sdn5.sitecore.net/?sdn5beta= - it will set the beta cookie and thats basically it. You can click 'back to normal' any time, but I'd appreciate if you also let me know whats wrong.

To the features:

It seems that web application project creates blank *.designer.cs files in total silence if you forget to reference assembly with the controls you have on the page. I've run into that while moving sdn5 msvs project into web application and forgetting to reference Sitecore.Webcontrols.

Previously:
* MSVS Web Application Project refresh
* All hail the web application projects

After another unfortunate accident at sdn, I had a strong desire to have at least a couple of simple tests to check that the sites are online and people can log in. With so many infrastructure changes it would hopefully help to reduce human element errors. Having the dense day schedule, it had to became a 'Thursday Night' project (thursay because I though of it at thursday and coudn't sleep until I try it)

Thanks to Scott Hanselman's blog, WATIR was the first thing that popped into my mind. WATIR stands for Web Application Testing in Ruby, and Ruby is being praised by its followers for elegance and joy most of all.

Cutting the long story short (it's actually a short story thanks to ruby) it worked out pretty well, and in a few hours I had tests that would check that

1. The homepage can be loaded and doesn't redirect anywhere else
2. It is possible to log in

WATIR uses Internet Explorer automation, so it will only work with IE available. Obviously it's not the tool of choice to have thorough UI tests, ensuring that everything works as it should in all browsers. However in my case, I think it does a great job with minimum effort.

[ruby source code]

Assuming that you have Ruby and Watir installed, you need to unzip it somewhere and start either cocrete tests (sdn5.rb, sdn4.rb..) or a complete suite (sdnSuite.rb). Double click the file and you should see IE window having its own life. Here's how the sdn5 test case looks like:

require 'Watir'
require 'SdnBase'
require 'test/unit'

class Sdn5 < SdnBase
   def setup
      super
      @homepage = "http://sdn5.sitecore.net/"
   end
 
   def test_homepage
      assert_homepage(/welcome/i)
   end
  
   def test_login
      go_homepage
      @browser.text_field(:id, /username/i).set(@username)
      @browser.text_field(:id, /password/i).set(@password)
      @browser.button(:name, /loginbutton/i).click
      assert(@browser.contains_text(/welcome ar@sitecore.net/i), "failed to log in")
   end
 end

Note that login tests will fail because I've removed my password in SdnBase.

Here's what will get you started:
1. Install Ruby for Windows. The simpliest way is Ruby one click installer
2. Install WATIR [http://wtr.rubyforge.org/]. Again, there's a windows installer available
3. Read WATIR user guide for starting steps
4. A great companion to WATIR would be either Firefox DOM explorer or IE web developer toolbar
[5]. If you want to get serious, Scott Hanselman has an NUnit-Watir integration guide

Another interesting thing to look at is Selenium:

"Selenium uses JavaScript and Iframes to embed a test automation engine in your browser. This technique should work with any JavaScript-enabled browser."

It supports xpath to access DOM elements, which is nice and familiar to Sitecore developers. I think it might even be reasonable to make Sitecore shell tests with something like that. It would definitely involve a combined effort, but might be worth looking at.

Html Agility Pack is shipped with Sitecore for a while, but now I actually needed something to process html fields. When you see a new API an API you haven't used before, write some code against it without looking into any reference (because the names are descriptive and/or somehow familiar) and it works the first time - doesn't it gives a kind of pleasant warm feeling inside?

HtmlField html = (HtmlField)item.Fields["text"];
foreach (HtmlNode node in html.SelectNodes("//img[@src]"))
{
  if (!string.IsNullOrEmpty(node.Attributes["src"].Value))
  {
    node.Attributes["src"].Value = ReplaceText(node.Attributes["src"].Value);
  }
}

Web application project has been a bless for me so far.. Although there's no migration wizard yet, converting the www.sitecore.net MSVS 2005 project (which I'm currenly working on) was a snap, and it was a huge relief from the first minute.

The project is basically a good old class library but with working asp.net designers, and thats good.

* Upgrading VS 2005 Web Site Projects to be VS 2005 Web Application Project
* Upgrading VS 2003 Web Projects to be VS 2005 Web Application Projects

Beware of Credential Cache

As I've told before, we're now using Microsoft CRM system to manage extranet users. When you log in, the user data is being fetched from sql table, a virtual user is assembled using the ID from CRM and given the Sitecore security roles based on CRM permissions.

There's one catch though - Sitecore maintains a credential cache (since around 5.1 I think), so that it doesn't have to repeatedly calculate effective permissions for a given user to a given item. Once the user accesses the item the first time, permissions are calculated and stored in cache. Sitecore also makes sure to clear the cache when required. In our case, however, the user is changed inside the CRM system, and its our responsibility to let Sitecore know about it. Failing to do so might result in permission changes only taking effect after application restart.

There are several options to handle that:

1) Clear the cache once any entities affecting access permissions were changed.

In the case with Microsoft CRM that would mean registering a callout on 'account' or 'contact' entities change. The web service on Sitecore side listens for notifications and clears the cache on demand.

Pro: Security updates are in effect immediately
Con: More complicated, requires an outgoing connection from CRM to Sitecore web server

2) Clear the credential cache for a user each time he logs in

Overriding Sitecore.SecurityModel.Domain.Login(string, string) will hook you up right in there - it gets called each time the user tries to log in suppling her login and password

Pro: Simple
Con: Security might not be updated until user session times out. Cache is clearead unconditionally

To be honest I've wasted time on both. The CRM callout didn't fit in because of the need of active outgoing connection, and we're now using the second one.

[CredentialCacheController]

Speaking of web application projects in MSVS, it looks like they had a brand new refresh with long awaited codebeside updater. Known issues look unsignificant, except for Migration Wizard, perhaps. Looking forward to try that.

It’s been a while since I’ve posted and the blank page looks scarier than ever.

SDN and SPN sites went live on Sitecore 5.2 two weeks ago, on January 30th; it’s not exactly ‘news’ at this point. It has been a significant change in a number of ways: moving to a latest Sitecore from 4.3.2.5, using asp.net 2.0 and weird web projects in MSVS.2005.

We’ve also integrated our security with Microsoft CRM 3.0 system - there are no extranet users in Sitecore itself, and everything being fetched from CRM database and turned into virtual users with appropriate roles assigned.

The last but definitely not least is the MondoSearch search engine and Behavior Tracking by MondoSoft that we’re now using on all three (sdn4/sdn5/spn) sites. More posts to come on this.

It looks like we did fine – there was no downtime during the change (although, uhh, server had run out of disk space last weekend... and, uhh, some exceptions were flying around a couple of times) and everyone had to bear with me and stop updating the site for less than two weeks only.

What we’ve gained from that is a better performing solution (no kidding) and a large amount of very-own-dog-food. The later is especially important even from my limited experience – hopefully I’ve did a number of good things along the way.

Database migration wizard received the most attention obviously, trying to make sure that it can handle all the little Sitecore 4 oddities I’ve encountered. However, It will not be released in it current form, becoming a component in new Data Transfer tool instead. It’s expected to be released pretty soon, from what I know.

The last few days were spent on capturing my ‘experience’ on paper; I’ll put up a draft soon, begging for feedback.

Now I need a bottom line, and it looks like “I RULE!” doesn’t fit. I’ll try this: if anyone is considering moving to Sitecore 5 from 4, let me know. Let me know what bothers you the most, let me know what areas you’d like to see covered in migration guide – I’m information hungry. Hopefully (for me) I’ll have something to share in return.

There's a number of options to speed up your Sitecore development installation:

1. Disable the indexes. Indexes are responsible for the little search bar in Sitecore taskbar. If you can happily live without it, then comment out the <indexes> section inside your database section in web.config (that is most probably /databases/master/indexes). The search will go away, along with index updates on each item create/update/delete operation.

2. Switch your site to the 'live' mode. Live mode completely eliminates the need for publishing, which can be pretty annoying in development scenarios, by taking all items directly from the content authoring database. To activate find your website in <sites> section of web.config (the site is called 'website' by default) and change database="web" to database="master". This is the way Sitecore client site works on core database. Naturally, by switching the publishing off you also lose the publishing restrictions, that is 'do not publish'/'publish date' stuff.

A new Sitecore blog by Mark Cassidy - welcome.
Metanauts - CMS discussion forum. You've probably seen this one in yahoo groups.