fredag, august 29, 2008
Sitecore and .NET 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 :-)
fredag, november 30, 2007
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();
torsdag, november 29, 2007
MailMonitor Sitecore Edition
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.
søndag, april 29, 2007
.NET Remoting Removed from Sitecore
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.
søndag, januar 14, 2007
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.
tirsdag, november 14, 2006
Visual Studio 2005 Build Performance
Then it hit me, ASP.NET web sites can run with both C# and VB code mixed so the Visual Basic compiler must run each time you build your website. To test this, I simply removed Visual Basic from my installation (seldom use it anyway) and bang ! – My website builds lightning fast again.
The lesson learned is this:
- Performance problems with compiling your website?
- Remove Visual Basic from your Visual Studio installation! (or apply the MS hotfix)
Resume of a lecture
First of all – it was a great lecture. He showed how all the language features of C# 3.0 together made LINQ possible and explained how they implemented LINQ using every one of these new language features. I must say that C# 3.0 is innovation on a high level, surely a something I will be waiting for with anticipation.
Besides from a great lecture, Anders revealed some information I want to share with you. (I hope MS don’t mind)
Concurrent Programming
The next step, after the release of C# 3.0 and LINQ – the language team will probably focus on concurrent programming. Anders believes that the available constructs for concurrent programming simply are to complex for the average programmer (Threads and so fourth) Therefore they will look at how they can improve the runtime and/or the language to better support concurrent programming, making it easier for developers to take advantage of multiple CPU’s that are getting more and more common in standard PC.
Release of C# 3.0 and LINQ
Anders revealed that the language team currently is improving some details of the compiler for C# 3.0 and we (the general public) will have a beta version of the next Visual Studio codename “Orcas” in about six months. He also ensured that there will be no more CTP – only Betas from now on.
UPDATE 2007-03-09
-----
Seams that Anders Hejlsberg was wrong :-)Last week a new CTP (March CTP) was released after all. I wonder if the Beta still will be available six months after the lecture ?
------------
Last note
There will finally be a Set collection implementation available in Orcas. Jubii.
