I’m sure that, like a lot of people working with EPiServer I have a play area that I use to try things out and start off any proof of concept work that I’m going to be implementing later on in  various projects.  For this, I use the SDK Installation of EPiServer CMS along with an instance of the Visual Studio Web Server when my laptop boots up so that it’s always running.

Today, I wanted to have a play with Composer with a view to knowing enough about it to be able to get sign-off some projects that can use it.  First thing is just install it and see what happens.  There were some pretty good videos on the EPiServer site that give you basic tutorials on what to do once it was installed, but installing it is a minor stumbling block if you’re running the SDK, as your site it not hosted in IIS.  Cunningly, the EPiServer Deployment Center seems to look at sites in IIS and you don’t appear to have the ability to connect to a different web server (please, someone correct me if I am wrong).

You can get past this little ‘glitch’ assuming that you have and instance of IIS installed locally and it’s pretty simple to get around if you follow the steps below:

1. Crack open the web.config file of your SDK site.  Remove the port from the siteUrl, uiUrl and utilUrl attributes in the siteSettings element. 
   More than likely the value is 6666, but note it down, as you will be putting it back later.
2. Open up IIS administration and create a new virtual directory with the same name as your SDK site.  Point thin new virtual directory at your SDK site installation folder and ensure that you create an application for it (if not automatically done).
3. IIS will now be able to server your site, but EPiServer will rightly inform you that you don’t have a license file.  Don’t worry too much about that, because we have no intention of really using IIS to serve the files and will be scurrying back to Visual Studio’s web server before too long.
4. Your next step is a potential setting change in the web.config again.  Look for the virtualPathMappings element (if there is one already) and make sure that the url attribute starts ‘~/’.  I had a full URL in here, but this could well have been to a previous bungled attempt at doing this.  It’s worth checking and making sure it’s right.  If you cant find it, don’t worry.
5. From here, you should be able to open the EPiServer Deployment Centre and see your site.  Select the site and install the Composer, and click ‘Next’ a couple of times until the installation  is complete. 
   After you have done this, maybe install the samples too for good measure – chances are you are about to have a play anyway.
6. Now that we have done that, we can reset the web.config to use the Visual Studio in-built web server by putting the port numbers back in.  You can delete the IIS virtual directory at this point, or leave it there for later use, possibly with other EPiServer extension installations.
7. If you now look at your website in the Visual Studio solution explorer, click ‘View All Files’ and add the ‘Composer’ and ‘Dropit’ folders to the project.  Also, a reference to each of the DropIt DLLs that now reside in your bin folder:
   • Dropit.ComponentArt.Web.UI.dll
   • Dropit.Extension.dll
   • Dropit.Extension.UI.dll
8. You should now be able to build your site without any problems, so cross you fingers and hit <CTRL>+<SHIFT>+<B>.
9. Assuming it all builds, your next step is to go and set up the Dropit.Extension plug-in.  To do this, start your site and go to the Config tab in the Admin section.  Select Plug-in Manager and edit the setting for Dropit.Extension.  If the first property (‘Set the page ID for the root Composer data container’) is not set, click the little button and select the [Extension data Container] page from the root of your site.  This should have been created during the installation of the Composer on your site.

That should be enough to get you running so that you can run through some of the sample videos on the EPiServer site and have a jolly good play.

It’s worth noting that I was running around in circles with a simple error until some nice fellow on twitter told me to check this article that contains logging information for composer (thanks, Mr. Hellstrom).  It’s worth having on at least whilst you are getting to grips with it.

This is what i tried, although I suppose it is probably not en exact science, but it certainly should be a stab in the right direction.

Now that I get to use EPiServer CMS v5, I’m having approximately 165.3% more fun that I was with version 4.6.  I can actually find information about 5 easily on the internet, brilliant!  What I do find dismally disappointing though is the state of the SDK.  A great deal of it just lists methods or properties with no description.  In honesty, I can find out more using reflector.net.

While I appreciate that the guys at EPiServer are doing some great work delivering a brilliant set of tools for us to work with, I can’t help but think that someone should be updating the SDK with a little more vigor.

I’ve been working on a couple of things lately in EPiServer that I want to be able to easily re-use on other projects.  From my point of view that means just dropping DLLs in folders and letting EPiServer do as much of the work as possible.  One of my little pieces  of functionality needs to happen when a page has been published.  There are a couple of ways to do this, and previously I have been doing it in globla.ascx.  Today I cam across an blog by Allen Thraen on discussing the subject of how to register DataFactory event handlers in EPiServer which describes in much better detail than I can about the different methods that can be used.

I ended up using the last method he mentions as I find it the cleanest way forward.  I would copy the code in here, but you should go read his blog about it in honesty as its full of interesting stuff as always.  The key point is that any class that inherits from EPiServer.PlugIn.PlugInAttribute and has a void Start() method will be called by EPiServer in the plug-in loading mechanism.

The thing to keep in mind is that (as per Allen’s example code), if you register a PublishedEvent handler, it will happen when any page is published.  That being the case, you’ll need to be inventive with filtering your exact requirements in the event handler making sure that you only do what you want when you want to!  Common sense I suppose. 

I then got to thinking, “Hey, if I can do this then how messy is this potentially going to get if anyone can register and event handler?”.  It would be pretty difficult to get a handle on what is going on.  Luckily, Andres Hattestad has got a solution for this that reports which events are registered, and where.  I’m trying that out just now, but I’m pretty certain it’s going to be awesome and make my life a lot easier over the coming weeks, as I have a lot of plug-ins that I want to build.

I strongly suggest that you going and read Anders’s and Allen’s posts and adorn them with due praise for being clever and of a sharing nature :)

Bah, I just found a much quicker and much simpler way of reading RSS while reading Mats Hellström’s blog article about Aggregating Feeds on the EPiServer Blogs.

Mats is talking about taking multiple feeds and adding them together, I’m still really only interested in on.  The key point I took from his blog is the SyndicationFeed class and all of its pals from the System.ServiceModel.Syndication namespace.  This makes most (read that as all) of my previous post on the subject pretty much irrelevant, as this is all nicely handled for us.

The code blow shows how I might do somethign similar to the previous post using nicer code:

using System;

using System.Linq;

using System.ServiceModel.Syndication;

using System.Xml;

namespace Using_Syndication_Feed

{

    class Program

    {

        static void Main(string[] args)

        {

            SyndicationFeed rssFeed = SyndicationFeed.Load(

                    XmlReader.Create("http://www.planet-f1.com/rss/0,16039,3213,00.xml")

                    );

            Console.WriteLine(

                String.Format(

                    "{0} > {1}",

                    rssFeed.Title.Text,

                    rssFeed.Links[0].Uri.AbsoluteUri

                    )

                );

            foreach (SyndicationItem rssItem in rssFeed.Items.Take(10))

            {

                Console.WriteLine(

                    String.Format(

                        "{0} - [{1}]",

                        rssItem.Title.Text,

                        rssItem.PublishDate.ToString("s")

                        )

                    );

            }

            Console.ReadLine();

        }

    }

}

Having had a glimpse on the BBC this morning, it looks like Microsoft are intending to shift Windows 7 without IE installed in Europe, it is now something users will have to go and download and install for themselves. 

In general, it looks like they’re leaving it up to the hardware vendors to decide what is installed on the machine and what is not, but what happens when user pop out and buy a copy of Windows 7 themselves?  I assume that means that there will just be a link on the desktop to go and download the file, otherwise, I can’t quite see how your average user is going to get on the internet in the first place to go and find a web-browser to download!  On the other hand, I can’t see your average user popping out and buying a copy of Windows.

What seems slightly risible to me is that Microsoft get slapped around by the European Commission for bundling things in to their OS, and Apple later on use the bundling of pre-installed software in the OS as a selling point with iLife.

Related Information:

• http://news.cnet.com/8301-13860_3-10262630-56.html?tag=newsLeadStoriesArea.1
• http://www.apple.com/ilife/