Quick Tip: Accessing MapPath method When HttpContext.Current is null

If you ever tried to use the HttpContext.Current.Server.MapPath method from a thread or within a Sitecore EventHandler, you will notice, that the HttpContext.Current is null.

How do you get the absolute path of a file when you only know the relative path? Well, you can’t use HttpContext.Current.Server but you can use the alternative:

HostingEnvironment.MapPath("~/App_Config/MailTalkServices.config");

Located in the namespace: 

System.Web.Hosting;

.NET Developer on a Macbook Pro running Windows 7

Yes I know, It is strange but very true.

I am a Microsoft .NET programmer and I use a 17” Unibody Macbook Pro Mid 2009 model, with a 2.66 GHz CPU, 8 GB RAM, and a Intel X-25m 160GB SSD hard drive. On top of that, I'm running Windows 7 as my primary OS spending 99% of my time on it, and using 90% of my time in Visual Studio 2008, Outlook 2010 Beta or Google Chrome.

And I am happy. Well now I am, but it has been a hassle. For a little over a year, I have been struggling to make this baby perform under Windows 7, and I has not been easy. I must have used 100 hours reading blogs, discussion forums and reading web pages on the subject. 

This is actually my second Unibody Macbook Pro. My first was a 15" but I sold that one and bought the 17” model instead. This proved to be a good decision. The 17” has a marvelous battery life and a fantastic screen compared to the 15” model. It is also a lot more silent and not as hot during intensive use.

I am besides being a .NET developer also a consultant. It has been quite funny to see how my customers make funny faces when I sit down around the conference table, introducing myself as a Microsoft specialist, pulling a Macbook Pro from my briefcase. However, some of them have told me that they actually had the same idea and I made a promise to one of them to explain how I made it perform under Windows 7. What better way of doing that than writing a series of blog posts.

I will over the next few days write about what I did to make it perform, and describe the one issue that remains to be solved: How to enable AHCI and thus SATA2 speeds in Windows 7. But more on that later.

Sitecore and .NET 3.5 SP1

Sitecore 6 was the victim of a bug in Microsoft .NET 3.5 SP1 – which meant that Sitecore 6 developers could not use Visual Studio 2008 SP1 or .NET Framwork 3.5 SP1.

You can read alle about it at Alexey Rusakov's blog

However, I just discovered that Sitecore just now released a patch addressing this very problem. I tested it, and it seems to work.

What you want to do, is download Update rev.080820 from sdn5.sitecore.net

Good work Sitecore :-)

Sitecore on .NET 3.5

I can report that using Sitecore with .NET 3.5 and C# 3.0 truly is a seamless transition.

This is especially good news for us developers who tried to upgrade from .NET 1.1 to .NET 2.0.
Back in the day, the transition supposed to be seamless, but surely was not. There was always some strange library containing some braking change, or a project model
who was removed - only to make life difficult for us developers.
This is by my experience NOT the case when upgrading from .NET 2.0 to 3.5.

I have been running a production environment of Sitecore in .NET 3.5 for a couple of weeks now (since we
Microsoft Gold Partners got VS2008) – and there have been no problems so far.
But why is that?


Well:

– There has been no change what so ever in the CLR runtime. It’s still 2.0. This was not the case coming from 1.1 to 2.0. MS had to update the CLR to include generics (parametric polymorphism)

– The C# Compiler has changed, but the target of the compiler remains.

– The library changes are purely additive. Meaning, that things you used in
.NET 2.0 remain the same - and all the new features have been added in new
.dlls, not changing the old ones.

So - Happy coding using C# 3.0 for Sitecore.


To finnish of, lets reflect on the different way to bind children of an Item to a repeater control in Sitecore:


(Wich one do you like the most ?)

//The sitecore way

childrenRepeater.DataSource = Context.Database.SelectItems("/sitecore/content/home/*[@@templatename='DisplayBox']");

//C# 1.0 way, using a standard foreach loop

ArrayList list = new ArrayList();

foreach (Item item in Sitecore.Context.Item.Children) {
if (item.TemplateName == "DisplayBox")
list.Add(item);
}
childrenRepeater.DataSource = list;

//C# 2.0 way, using the iterator pattern (yield statement),and anonomouse delegate

childrenrepeater.DataSource = delegate {

foreach (Item child in Sitecore.Context.Item.Children) {
if (child.TemplateName == "DisplayBox")
yield return child;
}
};

//C# 3.0 way using the query syntax
childrenRepeater.DataSource = from Item child in Sitecore.Context.Item.Children
where child.TemplateName =="DisplayBox"

select child;

childrenRepeater.DataBind();

MailMonitor Sitecore Edition

I have been working on a product called Mail Monitor for years now. It is my pet project and has been for the last 3-4 years or so.

Mail Monitor is an E-mail /SMS campaign tool written in C# hosted on ASP.NET and uses all the cool stuff released from Microsoft within the last years. (Except Silverlight, for now). It is a tool written by a super nerd (me) and is therefore highly extendable using Providers, web-services, Remoting and GoF patterns.

But MailMonitor is not new – but the fact that I made a version for Sitecore is.

For now check out these screenshots.

.NET Remoting Removed from Sitecore

Some time ago I blogged about how Sitecore would include .NET Remoting, a feature that would make Sitecore more scalable and flexible.

Introducing Remoting support was a fundament for creating integration to Sitecore from applications that would not be hosted on the same process as the CMS – a scenario that is very likely in the enterprise. It would also open up the possibility of creating custom tools that could be run from any machine not running Sitecore, even supporting the creation of a Windows Power Shell client.

In essence, the only big different was the all classes in Sitecore.Kernel ultimately would implement MarshallByRefObject something that does not have any impact on the performance of the system, the rest was configuration. It means that supporting .NET Remoting is nearly effortless and free, whereas the benefits are great and powerful.

I just realized, to my great surprise, that none of the classes that used to implement MarshallByRefObject during the Beta period of Sitecore 5.3 still do.
I simply do not understand why Sitecore made this change, and would love to hear their input on this.

Using the ObjectDataSource with Singleton and/or Interface instances

When using Visual Studio 2005 to configure the ObjectDataSource, you will only be presented the option to bind against classes that implement the class System.Web.UI.WebControls.ObjectDataSource. The ObjectDataSource will pr. default create its own instance of your ObjectDataSource class using reflection and use this that instance to retrieve objects that are to be bounded to you data control (for example the GridView).

As a consultant I often see developers having their own data retrieval classes, but when they want to use them in an ObjectDataSource, the class is wrapped in another class implementing the System.Web.UI.WebControls.ObjectDataSource only to satisfy Visual Studio. This leads to twice the complexity – and replication of code. The technique cowered in this blog post might be trivial to some, but I believe that the point cannot be made clear enough.

A better approach is to configure the ObjectDataSource tag to make use of the already present data retrieval class and tell the ObjectDataSource to use exact the instance of you class that you want it to use. This can be necessary if you have decided to only expose interfaces to you client, or if you data access class is implemented as a GoF Singleton or Factory design pattern (thus not letting the ObjectDataSource create an instance of your data retrieval class).

<asp:ObjectDataSource ID="_transactionData" runat="server"
    TypeName="MailMonitorServer.Locator.ITransactionLocator"
    DataObjectTypeName="LinkTrackerServer.ITransaction"
    SelectMethod="Find" 
    OnObjectCreating="ObjectDataSource_ObjectCreating" 
    OnSelecting="ObjectDataSource_Selecting" 
    EnableCaching="false" >
</asp:ObjectDataSource>

This code shows how I use the ITransactionLocator to locate transactions. The thing to notice here is that the ITransactionLocator (TypeName attribute of the ObjectDataSource) is in fact an interface (we cannot create instances of it from the client application) and the only way of getting an instance of this interface is through a Singleton pattern (more about that later).

The DataObjectTypeName defines that the type of the objects that are returned by the ITransactionLocator are of type ITransaction. In order to instruct the ObjectDataSource to use exactly your instance of the ITransactionLocator, and therefore not use reflection to create its own instance, I hook into the OnObjectCreating event.

protected void ObjectDataSource_ObjectCreating(object sender, ObjectDataSourceEventArgs e) {
    e.ObjectInstance = InstanceHelper.Instance.TransactionLocator;
}

Here I assign the singleton instance of my locator class to the arguments ObjectInstance property. This way the ObjectDataSource uses only this instance.

In this case the ITransactionLocator’s Find method needs a special parameter (not covered by the standard <selectparameter> tags. To customize the parameter sent to the Find method I hook into the OnSelecting event.

protected void ObjectDataSource_Selecting(object sender, ObjectDataSourceSelectingEventArgs e) {
    IDealer dealer = (IDealer) Session["dealer"];
    e.InputParameters.Add("account", dealer.Account);
}

In this manner I also have complete control of the parameters that are sent to my ITransactionLocator.

I hope this little code will give you a new idea of now flexible the ObjectDataSource implantation really is.