When developing using the SharePoint object model, certain operations has to be run with elevated privileges. For instance, setting information into the property bag of a site needs to be done with elevated privileges. This post shows how this is done, and also includes a helper method for making it easier and shorter to do this.

There is a method called SPSecurity.RunWithElevatedPrivileges in the object model that takes a delegate as argument. The delegate is then run with more permissions. An important note regarding this: You must not use old references to SPWeb or SPSite instances inside your delegate, since they are “contaminated” with lower permissions. What you have to do is to create new SPSite and SPWeb instances using the Ids of the sites and webs you already have a reference to, like this:

SPSecurity.RunWithElevatedPrivileges(delegate() 
{ 
    using (SPSite site = new SPSite(SPContext.Current.Site.ID)) 
    { 
        using (SPWeb elevatedWeb = site.OpenWeb(webId)) 
        { 
            //Your code here 
        } 
    } 
});

If you need to do these kind of operations in several locations, this is a lot of repeating code to include. A colleague of mine made a small helper method that does the setup for elevated privileges for you. Here’s the short code snippet:

private delegate void CodeToRunElevated(SPWeb elevatedWeb);
private static void RunElevated(Guid webId, CodeToRunElevated secureCode)
{
    SPSecurity.RunWithElevatedPrivileges(delegate()
    {
        using (SPSite site = new SPSite(SPContext.Current.Site.ID))
        {
            using (SPWeb elevatedWeb = site.OpenWeb(webId))
            {
               secureCode(elevatedWeb);
            }
        }
    });
}

To invoke this, you call on the method with the Id of your web as one argument, and a delegate taking an SPWeb as the other. When the method is invoked, the SPWeb argument will be “uncontaminated” and pushed to elevated privileges. This example sets the name, title, and description of a site.

RunElevated(web.ID, delegate(SPWeb elevatedWeb)
{
    elevatedWeb.Name = siteTitle;
    elevatedWeb.Title = siteTitle;
    elevatedWeb.Description = siteDescription;
    elevatedWeb.Update();
});

When creating custom webparts or other custom features in SharePoint that retrieves data from a SQL server, there are a few gotchas and pitfalls that you should be aware of. I spent a few hours battling a couple of problems, so I thought I’d document the things I found out here to spread the knowledge.

I was creating a custom webpart that retrieved data from a SQL server. On my development machine, I used a test SQL user with username and password directly in the connection string in the web.config and things worked as they should. The problems started when I deployed my solution to the test server.

On the test server, I changed the connection string to use integrated security instead, and when trying to access the page, I was greeted with an error message stating that I was not allowed to have a connection string with the words Integrated Security in it. This happens since SharePoint adds a tag mapping that replaces the normal SqlClient assembly with SharePoint’s own. Apparently that SqlClient does not support integrated security. So, what I had to do was to add the following line to my web.config in the tagMappings-section:

<remove tagType=”System.Web.UI.WebControls.SqlDataSource, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

After I added this line, things worked ok when I tried the page on the test server. However, when I asked a colleague to try out the page from his machine, another issue arose. He was greeted with the message: Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. This happens since SharePoint by default tries to impersonate the user browsing the site, so when using integrated security (if your environment is set up for impersonation multi-hop) SharePoint actually connects to the database as you. If impersonation-forwarding is not supported, you are instead greeted with the previously mentioned login failed message.

What I actually wanted to do in my webpart was to connect to the database as the SharePoint service user, not using impersonation. To fix this, I created two helper methods that turns off impersonation temporarily.

private WindowsImpersonationContext ctx = null;

public void UseAppPoolIdentity()
{
  try
  {
    if (!WindowsIdentity.GetCurrent().IsSystem)
    {
      ctx = WindowsIdentity.Impersonate(System.IntPtr.Zero);
    }
  } catch { }
}

public void ReturnToImpersonatingCurrentUser()
{
  try
  {
    if (ctx != null) { ctx.Undo(); }
  }
  catch { }
}
 

These calls are then placed around the code that should be run as the service user, for instance when retrieving information from the SQL database, like this:

UseAppPoolIdentity();

// Code to retrieve data

ReturnToImpersonatingCurrentUser();

Few weeks ago I had a problem how to combine the Silverlight Navigation Framework (now on NF) with Prism. It is a known fact that the Prism and the NF are not directly compatible. The main problem was that the Prism makes the UI composition with regions and the NF uses frames. I wanted to use the NF because it interacts with the Browser History journal.

I googled to find a good way to do this  but all the solutions where somewhat limited or required some kind of hack. I was not happy with those so I dived deeper to the NF. I found out that in Silverlight 4, the navigation framework allows one to write own content loaders for the Frame. This is great because I could build my own content loader using Unity.

Prism uses Unity as a default dependency injection container. I created new content loaded that loads the views to the frame by using Unity. To be able to do this, few things are needed:

• Views needs to be registered to the Unity container before using the NF
• Uri is the fully qualified name of the view.
• Uri mapping is used to get rid of the ugly fully qualified view name

Here is the content loader code:

public class UnityNavigationLoader : INavigationContentLoader
{
        private IUnityContainer _unityContainer;
        public UnityNavigationLoader(IUnityContainer unityCotainer)
        {
            _unityContainer = unityCotainer; 
        }
        public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState)
        {
            var result = new PrismContentLoaderAsyncResult(asyncState);
            string typeName = GetTypeName(targetUri);
            Type t = Type.GetType(typeName, false, true);
            result.Result = _unityContainer.Resolve(t);
            userCallback(result);
            return result;

        }
        public bool CanLoad(Uri targetUri, Uri currentUri)
        {
            //We are just happy at this point that the type can be resolved
            string typeName = GetTypeName(targetUri);
            Type t = Type.GetType(typeName, false, true);
            if (t != null)
                return true;
            else
                return false;
        }
        public void CancelLoad(IAsyncResult asyncResult)
        {
            return;
        }
        public LoadResult EndLoad(IAsyncResult asyncResult)
        {
            return new LoadResult(((PrismContentLoaderAsyncResult)asyncResult).Result);
        }
        private string GetTypeName(Uri uri)
        {
            if (!uri.IsAbsoluteUri)
                uri = new Uri(new Uri("something:///", UriKind.Absolute), uri.OriginalString);
            return Uri.UnescapeDataString(uri.AbsolutePath.Substring(1));
        }
    }

I created the  Uri mappings to the App.xaml:

<navigation:UriMapper x:Key="UriMapper">
    <navigation:UriMapping Uri="Home" MappedUri="/class, assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</navigation:UriMapper>

If you are using modules (like you usually do with Prism) which contains “links”, you need to add the Uri mappings in the module initialization

UriMapper mapper = (UriMapper)Application.Current.Resources["UriMapper"];
mapper.UriMappings.Add(new UriMapping()
{
    Uri = new Uri("Home2", UriKind.Relative),
    MappedUri = new Uri("/" + typeof(your class).AssemblyQualifiedName, UriKind.Relative)
});

I added a Frame called “MainFrame” to the shell and assigned my own content loader to it. Remember to set the UriMapper property to the Frame

<navigation:Frame x:Name="MainFrame" Source="Home" UriMapper="{StaticResource UriMapper}"/>

And code behind

MainFrame.ContentLoader = new UnityNavigationLoader(container);

Now only thing that is missing is the HyperlinkButton that tirggers the navigation

<HyperlinkButton Content="Home" NavigateUri="Home" TargetName="MainFrame"/>

Everything is now set. This solution also support parameters that can be passed with the Uri like you would normally do. Only thing you need to make sure is that the view inherits from a NavigationPage. That way you can use the Page_Loaded event to get access to the query paramaters of the Uri. Happy coding :)

You can download the UnityNavigationLoader code with PrismContentLoaderAsyncResult from here.

Triggered by a recent blog posting by Andreas Finne, I’ll share a convenient extension method that I have written.

First, let’s give an introduction the “why” that triggered me writing this extension method from the beginning. The List<T> generic class is a pretty good class for keeping a list of objects (which are strongly typed, because this is a generic type). The List<T>, in turn, implements the ICollection<T> interface, which has a method defined which looks like this:

void Add(T item);

Now, there is only one big problem with this method: it should really return an ICollection<T>. Why, oh why didn’t Microsoft think of that? That way, you could have written your code like this:

IEnumerable<Customer> customers = new List<Customer>()
    .Add(new Customer { CustomerNumber = 12345, Name = "Customer #1" })
    .Add(new Customer { CustomerNumber = 23456, Name = "Customer #2" });

The problem withthis code snippet is that the Add() method returns void, which in turns means that the “fluid” syntax above is not possible.

Not until you work around it, that is. :-)

The way we can solve this is by writing a generic extension method that works on an ICollection<T> object and does the Add() and then returns the collection itself. That way, we should be able to accommodate a similar syntax similar to this.

I prefer to place my extension methods in a class which is named “<class>ExtensionMethods”, where <class> is the name of the class which the extension methods operate on. Thus, I will call this class ICollectionTExtensionMethods. Here is the code:

public static class ICollectionTExtensionMethods
{
    /// <summary>
    /// Adds an item to the <see cref="System.Collections.Generic.ICollection&lt;T&gt;"/>.
    /// </summary>
    /// <typeparam name="T">The type of object which the collection contains</typeparam>
    /// <param name="collection">The <see cref="System.Collections.Generic.ICollection&lt;T&gt;"/> to operate on</param>
    /// <param name="item">The object to add to the <see cref="System.Collections.Generic.ICollection&lt;T&gt;"/></param>
    /// <returns>The <see cref="System.Collections.Generic.ICollection&lt;T&gt;"/> we are operating on</returns>
    public static ICollection<T> AddWithReturn<T>(this ICollection<T> collection, T item)
    {
        collection.Add(item);
        return collection;
    }
}

(I copied the XML documentation from the ICollection<T> interface definition metadata. :-)

Now, we can write some code that looks like this: (Remember to include a using-line for the namespace where you placed this ICollectionTExtensionMethods class.)

IEnumerable<Customer> customers = new List<Customer>()
    .AddWithReturn(new Customer { CustomerNumber = 12345, Name = "Customer #1" })
    .AddWithReturn(new Customer { CustomerNumber = 23456, Name = "Customer #2" }); 

Pretty nice, huh? :-)

Alright, this was it for this time. HTH!

I found some really nice code the other day. Unfortunately I cannot say that I wrote it myself, but I think it’s so cool that it needs to be published here. It was written by “mazzy maxim” as Community Content to MSDN. What it does is to extend the OrderBy method for IEnumerables. You provide the name of the property to sort by, and the sort order.

Without further ado, here is the code:

public static IOrderedEnumerable<T> OrderBy<T>(this IEnumerable<T> items, string property, bool ascending)
{
    var MyObject = Expression.Parameter(typeof(T), "MyObject");
    var MyEnumeratedObject = Expression.Parameter(typeof(IEnumerable<T>), "MyEnumeratedObject");
    var MyProperty = Expression.Property(MyObject, property);
    var MyLambda = Expression.Lambda(MyProperty, MyObject);
    var MyMethod = Expression.Call(typeof(Enumerable),
                                   ascending ? "OrderBy" : "OrderByDescending",
                                   new[] { typeof(T), MyLambda.Body.Type },
                                   MyEnumeratedObject,
                                   MyLambda);
    var MySortedLambda = Expression.Lambda<Func<IEnumerable<T>, IOrderedEnumerable<T>>>(MyMethod, MyEnumeratedObject).Compile();
    return MySortedLambda(items);
}

So what we have is a generic extension method for IEnumerables that creates a  lambda expression on the fly to sort the objects by the property with the given name.

Pretty cool or what?

Now, some of you may argue that sorting by the name of the property introduces magic strings and doesn’t feel “right”. I can agree with that to some extent, but it is not much different to NotifyPropertyChanged(“property”), and my opinion is that this extension method still can have its place.

I have used it when I needed the sorting of an object collection to be in the ViewModel rather than in the View. The reason for this was that the collection could be changed by a synchronization thread, and since the sort order was stored in the View, the ordering got reset. By using this method in the ViewModel, the sorting state was moved away from the View. The object collection was shown in a table, and the property to sort by was chosen by clicking on a column header. Clicking the header changed the OrderedBy property exposed by the ViewModel, and the collection was re-sorted accordingly.

Those of you that are familiar with eCraft and the types of applications we create, know that we mostly work with business applications and shuffle data back and forth between different back office systems or create applications that lets users interact with back office systems through more lightweight user interfaces tailored for their daily tasks. Therefore it was very interesting to be able to do yet another Microsoft Surface project, this time where the application was not data-centric but instead the focus was shifted towards the presentation end of the spectrum. We were given the opportunity to develop a Surface application to be used at the Nobel festivities with a very tight deadline for the development work. You can read a blog post about our involvement in the project here (in Finnish).

The design called for the Surface background to be sensitive to touch so that the users would be able to paint with their fingers on the screen and so that the paint would gradually fade out over time. The Surface SDK provides a SurfaceInkCanvas control that would easily handle the painting part, but achieving the kind of fade out that we wanted did not seem possible that way. Instead I started looking into the possibility of programmatically generating and updating a bitmap and discovered that it is possible through the use of the WriteableBitmap to do just that. In case you want to do this, make sure that you are using a recent version of the .Net Framework. At least .Net 3.5 and newer have implemented WriteableBitmap using double buffering and other techniques that guarantee it is performant enough for updating the bitmap often. We ended up using a bitmap image of size 1027x768 (Surface resolution) as the background of the application and any finger touch on this would start painting with a small 60x60 brush on the bitmap. We randomly used one of several slightly different brushes to achieve a more “alive” stroke as we painted. The brushes we used were 24-bit PNGs with about 50% alpha in the middle increasing to completely transparent towards the perimeter.

The following functions shows how we used WriteableBitmap to achieve the intended effect of blending together the brush bitmap with whatever was already on the background. Rows 6-11 make sure that in case the contact point is close to the edge of the background bitmap,only the correct part of the brush will be used to update the background. And in lines 26-47 we extract the Red, Green, Blue and Alpha values from both the background and the brush image and blend them together and construct the new image pixel.

private void UpdateBitmap(WriteableBitmap bitmap, BitmapImage brush, Point centerPoint)
{
    if ((int)centerPoint.X >= 0 && (int)centerPoint.X < bitmap.PixelWidth
         && (int)centerPoint.Y >= 0 && (int)centerPoint.Y < bitmap.PixelHeight)
    {
        int bitmapX = Math.Max((int)centerPoint.X - brush.PixelWidth / 2, 0);
        int bitmapY = Math.Max((int)centerPoint.Y - brush.PixelHeight / 2, 0);
        int brushX = Math.Max(brush.PixelWidth / 2 - (int)centerPoint.X, 0);
        int brushY = Math.Max(brush.PixelHeight / 2 - (int)centerPoint.Y, 0);
        int brushWidth = Math.Min(brush.PixelWidth - brushX, Math.Min(bitmap.PixelWidth - bitmapX, brush.PixelWidth));
        int brushHeight = Math.Min(brush.PixelHeight - brushY, Math.Min(bitmap.PixelHeight - bitmapY, brush.PixelHeight));

        Int32Rect brushRect = new Int32Rect(brushX, brushY, brushWidth, brushHeight);
        Int32Rect bitmapRect = new Int32Rect(bitmapX, bitmapY, brushWidth, brushHeight);

        int stride = (brushRect.Width * brush.Format.BitsPerPixel + 7) / 8;
        var brushPixels = new UInt32[brushRect.Width * brushRect.Height];
        var imagePixels = new UInt32[brushRect.Width * brushRect.Height];

        brush.CopyPixels(brushRect, brushPixels, stride, 0);
        bitmap.CopyPixels(bitmapRect, imagePixels, stride, 0);
        bitmap.Lock();

        for (int i = 0; i < brushPixels.Length; i++)
        {
            UInt32 brushA = (brushPixels[i] & 0xFF000000) >> 24;
            UInt32 brushR = (brushPixels[i] & 0x00FF0000) >> 16;
            UInt32 brushG = (brushPixels[i] & 0x0000FF00) >> 8;
            UInt32 brushB = (brushPixels[i] & 0x000000FF);

            UInt32 imageA = (imagePixels[i] & 0xFF000000) >> 24;
            UInt32 imageR = (imagePixels[i] & 0x00FF0000) >> 16;
            UInt32 imageG = (imagePixels[i] & 0x0000FF00) >> 8;
            UInt32 imageB = (imagePixels[i] & 0x000000FF);

            //(Rs As + Rd (1 - As), Gs As + Gd (1 - As), Bs As + Bd (1 - As), As As + Ad (1 - As))
            imageR = (brushR * brushA + 255 * imageR - imageR * brushA) / 255;
            imageG = (brushG * brushA + 255 * imageG - imageG * brushA) / 255;
            imageB = (brushB * brushA + 255 * imageB - imageB * brushA) / 255;
            imageA = Math.Max((brushA * brushA + 255 * imageA - imageA * brushA) / 255, imageA);

            imageA = imageA << 24;
            imageR = imageR << 16;
            imageG = imageG << 8;
            //imageB = imageB;

            imagePixels[i] = imageA | imageR | imageG | imageB;
        }

        // copy in the changed pixels
        bitmap.WritePixels(bitmapRect, imagePixels, stride, 0);

        // Specify the area of the bitmap that changed.
        bitmap.AddDirtyRect(bitmapRect);

        // Release the back buffer and make it available for display.
        bitmap.Unlock();
    }
}

In order to achieve the wanted fade out effect we had another function that we called from a timer that would adjust the alpha channel value of every pixel in the background bitmap.

private void FadeBitmap(WriteableBitmap bitmap, Int32Rect rect)
{
    var imagePixels = new UInt32[bitmap.PixelWidth * bitmap.PixelHeight];
    bitmap.CopyPixels(rect, imagePixels, bitmap.BackBufferStride, 0);
    bitmap.Lock();

    for (int i = 0; i < imagePixels.Length; i++)
    {
        UInt32 imageA = (imagePixels[i] & 0xFF000000) >> 24;
        imageA = imageA < 10 ? 0 : imageA - 10;
        imageA = imageA << 24;
        imagePixels[i] = imageA | imagePixels[i] & 0x00FFFFFF;
    }

    // copy in the changed pixels
    bitmap.WritePixels(rect, imagePixels, bitmap.BackBufferStride, 0);

    // Specify the area of the bitmap that changed.
    bitmap.AddDirtyRect(rect);

    // Release the back buffer and make it available for display.
    bitmap.Unlock();
}

In our implementation we faded the entire background image during every cycle. In a slightly more fancy version we could partition the screen into smaller spaces and keep track of which partitions actually contain any pixels that needs fading, increasing the complexity a bit but drastically cutting down on the amount of bitmap updates needed. That improvement is left as an exercise for the reader :)

In closing, I found that this was a very interesting project to work on and it was really invigorating to be forced to think about bitwise operations and bit shifting. In the normal projects we do, there are seldom any need for going into that level of low-level funkiness.

I usually start learning new technologies by doing something more than hello world example. This time I wanted to learn Silverlight and decided to build Othello game. I have done it with other technologies as well like Java ME so I was quite familiar with the game concepts. So I just rushed to code.

My first task was to create the game board. Game board in Othello is 8x8 in size and each of the places can be in one of the following state: white,black or empty. I first created a UserControl called GameButton to visualize the state of the game board place. The Game button contains visualization of all the states. When the state changes from white to black or vise versa the state change is animated by flipping the button along x-pane.

Next I created the main Window with one Grid called LayoutRoot. Because I have strong background on Windows Forms I  thought that it is impossible to creating the board dynamically without writing some code behind code (you will notice how wrong I was).

List<List<GameButton>> buttons = new List<List<GameButton>>();
for(int i = 0; i < 8; i++)
{
    buttons.Add(new List<GameButton>());
    for(int j=0; j < 8; j++)
    {
        GameButton button = new GameButton();
        button.ButtonState = GameButtonState.Empty;
        button.SetValue(Grid.RowProperty, i);
        button.SetValue(Grid.ColumnProperty, j);
        LayoutRoot.Children.Add(button);
        buttons[i].Add(button);
    }
}
buttons[3][3].ButtonState = GameButtonState.White;
buttons[3][4].ButtonState = GameButtonState.Black;
buttons[4][3].ButtonState = GameButtonState.Black;
buttons[4][4].ButtonState = GameButtonState.White;

This code smells, my game state (Model) is not separated from the view. Also I have UI logic both in XAML file and code behind. This means that designer tools like Expression Studio will not have any glue what controls the Grid contains.

I knew that there has to be a better way to do this in XAML. I investigated a bit and found out that this can be fairly easily implemented. Here is the result of new version written in XAML.

<Grid x:Name="LayoutRoot" Background="White">
    <ItemsControl x:Name="GameButtons"  ItemsSource="{Binding GameBoard}">
        <ItemsControl.ItemTemplate>
            <DataTemplate>
                <ItemsControl x:Name="Row" ItemsSource="{Binding}">
                    <ItemsControl.ItemsPanel>
                        <ItemsPanelTemplate>
                            <StackPanel Orientation="Horizontal">
                            </StackPanel>
                        </ItemsPanelTemplate>
                    </ItemsControl.ItemsPanel>
                    <ItemsControl.ItemTemplate>
                        <DataTemplate>
                            <local:GameButton ButtonState="{Binding GameRegionState}"/>
                        </DataTemplate>
                    </ItemsControl.ItemTemplate>
                </ItemsControl>
            </DataTemplate>
        </ItemsControl.ItemTemplate>
    </ItemsControl>
</Grid>

As you can see I have two nested ItemsControls. The first one is bind to the GameBoard property (List<List<State>>) of the OthelloGame class. The Row ItemsControl contains now the GameButton and the ButtonState is bind. I have now only few lines of code in code behind to bind the game state to the view. Now this starts to look good. Also if I would like to have bigger board it could be easily done by just adding more States to the List.

I would still like to get rid of GameButton UserControl. It contains some actions what would be nice to get from code behind to XAML side and also it is not needed because the binding takes care of creating new instances of it. The problem is that in Silverlight the triggers, actions and conditions are very limited. For silverlight 4.0 there is interesting extension library for triggers and actions called Slex. It requires Silverlight 4.0 and I was using 3.0 so I had to forget it. So if I would move the GameButton to the main view, benefits wouldn’t be that big.  So the GameButton can stay. With WPF the GameButton would be dead and buried.

The transition from the Windows Forms to Silverlight/WPF is quite big. The controls etc. are not that different but the biggest challenge is to get your brains to work with new mindset. Lot of things that was done before in code can be done in XAML with DataTemplates, Triggers, Actions and more.

Below is my first Silverlight application live and kicking. Computer uses minmax algorithm with a few optimizations on the normal level and calculates 4 moves ahead. 

Download full source here.

In this posting, I’ll give an introduction to how you can use the new features provided by ASP.NET AJAX to call methods in web services from your own JavaScript code with very little fuss. (Well, at least that’s the idea…)

First, I want to take some steps backward and describe the history, the steps that led to the advent of ASP.NET AJAX. JavaScript has historically been a client-only language, providing some client-side events that can be used to e.g. perform certain events every time the user hovers the mouse over a certain part of the web page, or every time an HTML <button> is clicked. All of this is taking place on the client computer only, in the web browser. There is no interaction between the JavaScript code and the server providing the web page on which the JavaScript code is hosted.

As the web applications started to be more and more advanced, the need for more interaction arose. The gap between the client and the server needed to be eradicated, somehow. The solution - or bridge, if you like - is named XMLHttpRequest. This is the very foundation that all of AJAX (including ASP.NET AJAX) relies upon.

XMLHttpRequest is a mechanism through which a web browser (Firefox, Internet Explorer, Safari, etc.) can make a request to the server without refreshing the whole page. The request is made by client-side script, in other words, JavaScript (as much as we love it or hate it…). The initial implementation of the XMLHttpRequest was made by Microsoft as a wrapper on top of the MSXML, using ActiveX (so it was not a “pure” JavaScript functionality at that time; rather JScript). Later on, other browser vendors followed along, modeling their implementation after the Microsoft one, and eventually the XMLHttpRequest was standardized by the W3C. [1]

So, what good does this XMLHttpRequest API do? Well, as previously mentioned, it enables client-side code (JavaScript) running in the web browser to make server-side requests for certain information, without the need for a full page reload. This makes all forms of interesting interactive web sites (or rather, web applications is a more descriptive term) possible. For example, you could have a page fetch live news from a newsfeed server, and display it on a web server, without the need for any refreshing of the page. You could have a form where the user enters a monetary value and chooses the source/target currencies, and presses a “Convert” button. The value is then converted between the given currencies, with no need for any 1990’s-style page refreshing. :-)

In the Microsoft ASP.NET world, ASP.NET AJAX was introduced between the release of ASP.NET 3.0 and 3.5 (a pre-release named Atlas was available slightly earlier). ASP.NET 3.5 (Visual Studio 2008) has ASP.NET AJAX support out-of-the-box.

(In the ASP.NET AJAX nomenclature, Microsoft talks about this “avoiding full page refresh” thing as partial page updates. I’ll use this phrase for the rest of this article.)

ASP.NET AJAX can be used in two modes: “ASP.NET mode” and “JavaScript mode”. In ASP.NET mode, what you do is basically more or less embed the controls that you want to use partial-page updates for in an <asp:UpdatePanel/> control. That way, ASP.NET AJAX will “seamlessly” handle the page updates, and tunnel them through the AJAX (XMLHttpRequest) pipe. Very convenient and easy to use for the developer, but not always optimal from a performance and technical point of view. I did a simple test when writing this blog article. The source code to my test page looks like this:

<%@ Page Language="C#" AutoEventWireup="true" %>

<script type="text/C#" runat="server">

    protected void Button_Click(object sender, EventArgs e)
    {
        Label.Text = "Moo!";
    }
    
</script>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <asp:ScriptManager EnablePartialRendering="true" runat="server" />
    <asp:UpdatePanel ID="UpdatePanel" runat="server">
        <ContentTemplate>
            <asp:Button ID="Button" runat="server"
                        Text="Click Me!"
                        OnClick="Button_Click" />
            <asp:Label ID="Label" runat="server" />
        </ContentTemplate>
    </asp:UpdatePanel>
    </form>
</body>
</html>

In other words, quite a simple page. The idea is that you click a button, and the button makes the text for a certain control be changed to “Moo!”. Since this is embedded in an UpdatePanel, this is supposed to take place using partial-page rendering techniques. The page looks like this when rendered:

Now, let’s inspect what it looks like in Fiddler when the “Click Me!” button is clicked. This is what we get:

The amount of overhead is immense; not speaking byte-wise, but percentage-wise. What we wanted to do is to fetch the “Moo!” text and place it in a control. This is a four byte string (if we’re talking ASCII and not UCS-2…) + maybe a trailing CR+LF or something like that. Let’s be nice and say that 10 bytes for this update would be reasonable.

Instead, we got 571 characters being sent over the wire. That’s an incredible 5700% of the “reasonable size” being used for the request!

Now, in reality, this is much less of a problem than I’m making it appear to be… Computers are fast nowadays, and broadband connections are common. Still, that old 640 KiB geek in me screams when I see something like this… :-) And of course, in this example, it might not be a problem, but who’re saying it wouldn’t be in a more complicated use case? What if you have more controls on the page, more viewstate to persist (which could be disabled altogether, btw.) and so forth? This can actually turn out to be a performance killer.

The reason for this extraneous information being transferred is this: The UpdatePanel control is built in a generic way. If you look closely at my screenshot (click on it to see the full picture), you see that what is transferred is the full HTML for the content of the UpdatePanel control. This makes it simple to implement (in the UpdatePanel control itself), and also has some other advantages, but is sometimes very much less than optimal, and can also make the page give a more sluggish feeling than necessary.

In our specific example, what we could have done instead is to just get the updated Text field and set the innerHTML property of the Label to this value. This should provide a much more optimized experience. :-) By using the client-side ASP.NET AJAX functionality, this is actually quite simple! I’ll go ahead and add a webservice to my web project, called “LabelWebService.asmx”. The .asmx file is left unmodified, and the code-behind file is modified to look like this:

using System.Web.Script.Services;
using System.Web.Services;

namespace eCraft.AjaxWithUpdatePanel
{
    /// <summary>
    /// Simple webservice for fetching the text for a label on a web page.
    /// </summary>
    [WebService(Namespace = "http://labs.ecraft.com/Samples/CallingWebServicesFromJavascript/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [ScriptService]
    public class LabelWebService : WebService
    {
        [WebMethod]
        public string GetText()
        {
            return "Moo!";
        }
    }
}

In other words, a very simple proof-of-concept web service that just returns a dummy value. Note the special attribute ScriptService on this class (from the System.Web.Script.Services namespace). What this attribute does is enable JavaScript proxy generation for your web service, enabling the service to be called from JavaScript embedded in an ASP.NET page. We might go through how this works behind the scenes some other time; for now, just accept the fact that it somehow magically creates a JavaScript wrapper class that lets you call your web service from JavaScript.

So, let’s skip the talk and go straight on to the code, shall we? This is the modified test page, now with some embedded code for calling the web service through JavaScript:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="eCraft.AjaxWithUpdatePanel.Default" %>

<script type="text/javascript">
       
    function Button_Click()
    {
        var ws = new eCraft.AjaxWithUpdatePanel.LabelWebService;
        ws.GetText(GetText_Succeeded);        
    }

    function GetText_Succeeded(result)
    {
        var label = $get('<%= Label.ClientID %>');
        label.innerHTML = result;
    }
    
</script>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
</head>
<body>
    <form id="form2" runat="server">
    <asp:ScriptManager ID="ScriptManager1"
        EnablePartialRendering="true" runat="server">
    <Services>
        <asp:ServiceReference Path="~/LabelWebService.asmx" />
    </Services>
    </asp:ScriptManager>
        
    <asp:Button ID="Button" runat="server" Text="Click Me!"
        OnClientClick="Button_Click(); return false;" />
    <asp:Label ID="Label" runat="server" />
    </form>
</body>
</html>

As you see, the page has been slightly changed from before. Maybe one of the most important changes that has taken place is that we skipped the <asp:UpdatePanel/> control altogether, but kept the <asp:ScriptManager/> one. We also added an <asp:ServiceReference/> control. This is what makes the page aware of the web service that we are about to call, and it helps the JavaScript intellisense to recognize the proxy class representing our web service.

We have also introduced two new JavaScript functions: Button_Click() and GetText_Succeeded(). The <asp:Button/> control have also been modified to perform an OnClientClick rather than an OnClick event. (The “return false” part is important, since we would otherwise get a full page postback – that’s the default behavior of the <input type=”button”> element, which is what the Button control gets rendered as.)

In the Button_Click() function, we create an instance of our web service wrapper class. The cool thing about this is that if you remove the code inside that function, and start typing “var ws = new e“, you should get something like this:

The eCraft.AjaxWithUpdatePanel.LabelWebService class is apparently known to Visual Studio, helping us a lot. You can now use code-completion to write the full class name, just like you could for C# code. This is a good enhancement that Microsoft has done to the JavaScript language, making it more convenient to work with (even though I’m really looking forward to a possible successor to the JavaScript language altogether… The language is too “weak” and dynamic in my taste.)

If you look at my Button_Click code again, something noteworthy is that the web service call is done slightly different than it would be done in C#. Instead of just calling the web service and getting back the result as a return value from the method, we are setting up a callback that will get called once the web service method is finished. This is a clear difference from traditional web service client code. This shows the asynchronous nature of the AJAX technology (after all, that’s what the A in AJAX stands for…). All web service calls are asynchronous when being used from JavaScript like this, and asynchronous service calls usually use callbacks to call a user-supplied method/function when the call has finished.

The disadvantage of this is that your code can become harder to read; it is less obvious what the flow looks like. The advantage is that you can make multiple server requests at once, and in a load-balancing scenario, there could even be multiple physical servers to serve your different requests, increasing performance. It is also a good preparation for starting to work with service calls in Silverlight, which always uses asynchronous calls (at least when calling WCF services, but I guess the same goes for traditional web services as well).

Finally, let’s look at the Fiddler output for my modified version of the program. You’ll be amazed (we hope :-). This is what it looks like:

Whoha! What’s that? It clearly looks very different to before, and also extremely optimized.

The reason why the content here looks very differently is that we’re now making a web service call rather than getting HTML data for updating the UpdatePanel. But also, it doesn’t look like the SOAP stuff that you could expect to get back from a normal web service call. This is because it uses the JSON format for serializing the data. JSON is a highly optimized format for serializing data over e.g. HTTP connections, and it is the default when using the ScriptService attribute like we’re doing here. (It usually works well, but it might not be suitable for all web service calls, perhaps especially if the data you are returning is of XML format. If necessary, you can always change to “raw XML”  as the response format. See this external blog posting for more details on that.)

Regarding the performance, we can see that the 571 bytes from the UpdatePanel sample has now shrank to a whopping 12 bytes. Quite an improvement (97,9% actually…). With the risk of being repetitive; in this case, it might not have mattered that much, but you should be able to clearly see the potential that this method has over standard <asp:UpdatePanel/> usage. The performance is simply outstanding. The cost you have to take is that you have to write client code to update the contents of the HTML controls. Sometimes, this can be a bit of work, but it can be simplified a bit. (instead of e.g. creating an HTML table with rows and cells, you could create it from beforehand and just use style=”display: none” to hide the cells. This makes it easy to un-hide them through JavaScript; hopefully simpler or better than inserting a bunch of new nodes in the DOM tree…)

Alright, time to close up this blog posting. In this posting, we have gone through the basics behind how AJAX works. We have also done some field testing of ASP.NET AJAX performance, first using UpdatePanel and later on using direct web service calls from JavaScript. We saw the clear performance advantage with JavaScript calling a web service vis-a-vis using the UpdatePanel, but can also understand that the UpdatePanel is often a better (or at least “simpler to implement”) choice, especially if you have a lot of code and controls in the existing implementation that you simply want to AJAXify. The UpdatePanel also makes the code slightly simpler to read and understand, since it “looks” more like traditional ASP.NET code (but this might actually be a disadvantage, since it works differently under the hood – abstraction can be good, but it can also fool you at times).

Anyway, we now know the alternatives, so we can wisely consider them both in real-world scenarios, and use whichever one is more suitable in each specific case. Remember that system architecture is no “one size fits all” business.

See you in my future posts; until then, take care.

As mentioned in a previous posting, Fiddler can be a great tool when debugging HTTP-based communication, particularly for webservices, WCF and similar (but really, any kind of HTTP traffic can be debugged with the tool). There is just one slight problem with it: by default, it is not usable for debugging localhost-based servers. In other words: if your server URL looks something like http://localhost:12345/MyService.asmx, you will not be able to debug it with Fiddler. That is, unless you apply “The Dot Trick”, which will be described in this blog posting.

First, let’s discuss the apparent problem and its cause, then we’ll move on to how we can workaround this. Let’s create a scenario: You are having problems with a web request in an application; the web request causes an exception for some reason. More specifically, the request is from a web application (ASP.NET .aspx file) to a web service (.asmx file). Also, you cannot/don’t want to debug this using Visual Studio’s built-in debugger, for one reason or another. This is the error message you’re getting, as presented on the ASP.NET web page:

Now, let’s start Fiddler. This is the output we get:

Switch back to IE, and press F5 to refresh the page (and hopefully reproduce the problem). After doing this, the error appears again in the web page, but… if you now look in the Fiddler window, it looks exactly the same as before you hit F5. How could this be, what on earth is happening?!?

The answer is this, taken from the Fiddler web page: “Internet Explorer and the .NET Framework are hardcoded not to send requests for Localhost through any proxies, and as a proxy, Fiddler will not receive such traffic” [1] This makes sense if you think about it: a proxy running somewhere in your local network can not fetch data from your local machine, when accessing a localhost-based URL. It could do a best-effort and try to rewrite the url to http://yourmachine:12345 (where yourmachine is the name of your machine), using the IP address provided in the proxy request, but… there’s no guarantee that http://yourmachine:12345 would be the same as your local http://localhost:12345 URL. In fact, when using the Visual Studio built-in web server (a.k.a. Cassini), this would not work at all: Cassini is designed to only listen on localhost traffic!

Therefore, it is understandable that someone at Microsoft at some point took the decision that WinINET and/or IE/Microsoft.NET  should disregard proxy configurations for localhost-based URL:s.

So, having stated what the problem is and some theory behind it, let’s move on to the whole point of this blog posting: There is a nifty little workaround to this problem, making it possible to debug traffic to localhost in Fiddler! But only if you have a way to modify the URL, so in some cases it would still be hard/impossible to use this. In our specific use case (an ASP.NET page calling a webservice) though, we can benefit greatly from knowing this. The workaround is what we can call “the Dot Trick”.

What you simply do is this: change the URL from something like http://localhost:12345/MyService.asmx to be http://localhost.:12345/MyService.asmx. Did you notice the dot? Right after the “localhost” and before the colon a dot (period character) has been inserted. This is what the browser window with the ASP.NET page looks like now (very similar to before, only difference being that the dot has been inserted in the URL):

But now look at our Fiddler buddy! This is what the Fiddler window contains:

Much better, isn’t it? We can now investigate “the red line” and possibly see what was causing this problem. However, that is out of the scope for this blog posting. :-)

Alright, that’s it for this time. In this blog posting, we’ve learned one of the caveats of Windows HTTP traffic, and how to work around it. I hope the information was useful to some of you; it has sure helped me.

PS: Rumor has it that “the dot trick” sometimes doesn’t work, e.g. with Windows 7. In that case, you can try http://ipv4.fiddler:12345/MyService.asmx instead. This will be intercepted by Fiddler and converted to localhost:12345, intercepting the traffic as needed.

There is this saying that “there is no computer system with a decent level of self-respect that doesn’t include at least one Windows Service”. Generally, this rule seems to be pretty true. Even if you try to build as much as possible of the system with a platform such as Microsoft BizTalk Server  or Windows SharePoint Services (because of personal or customer-specified preferences), there are likely to occur certain parts of the system that are simply not feasible or practical to implement within the boundaries of the platform.

Here are a few technical scenarios where a Windows Service could be suitable:

• You want to perform some background processing at certain time intervals, and no other job scheduler is available. For example, you might want to wake up every 5 minutes and poll a database, and perform some operations for each record found. Such scenarios can also be considered being implemented with BizTalk Server or SQL Server Integration Services (SSIS), if available.
• You want to listen to data arriving on a certain input channel, and do some form of processing every time data arrives. The input channel could be a TCP socket (like port 80 or 21), an MSMQ queue, or anything else. This scenario is also a valid candidate for being implemented with BizTalk.

However, we now assume that you have investigated the alternatives and decided that a Windows Service is the most suitable option in your case.

Writing a Windows Service is not that difficult, especially with the help provided by the .NET Framework all the way back since version 1.1 (Visual Studio 2003). Still, there are some things that could be worthwhile to think about when doing this. Some of these practices relate to the actual coding of the service, and some relate to how the service is best being deployed and set up on the server you are deploying it to.

The target audience of this guide is anyone wanting to write a Windows Service, having previous experience with the .NET Framework and writing code in C#. You don’t need to have any previous experience with writing Windows Services per se. For those of you who have such experience, this guide might feel too simple for you; still, there might be some new and useful ideas to be found here even for you.

Let’s start with the basics . We create a new Solution and Project in Visual Studio (I’m using 2008 in my examples, but this should work with 2005 or 2010 as well):

The “New Project” dialogue in Visual Studio

As you see, you find the Windows Service project template under Visual C# –> Windows. You could here also choose another version of the .NET Framework, such as 2.0, if you were to install this service onto a server which limits you in terms of which version of the .NET Framework is installed.

I prefer to set the solution name here to a the namespace “root” for the projects within this solution, and let the new project use the same namespace with “.Service” appended to it.

When you click OK, you get a skeleton class that looks like this (Service1.cs, “View Code”):

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Linq;
using System.ServiceProcess;
using System.Text;

namespace eCraft.Labs.WindowsServiceSkeleton.Service
{
    public partial class Service1 : ServiceBase
    {
        public Service1()
        {
            InitializeComponent();
        }

        protected override void OnStart(string[] args)
        {
        }

        protected override void OnStop()
        {
        }
    }
}

In other words; a simple Windows Service, that doesn’t really do anything. :-)

Now, what do we do first? Well, for starters, rename the Service1 class to something more useful. (You should really never keep the default file names such as Service1, Class1 etc. in Visual Studio, but always rename the files to something more appropriate.) If you want to make it simple, just call it “Service”. I just checked one of our own Windows Services, and it’s called just that. ;-)

OK, the project has been created and you are now probably eager to see how you can get this program running as a Windows Service, right? Before we do so, let’s do something important first: we want to change the service’s visible name. This name is the name that will be seen in the Windows Services list (services.msc), and also something that you can refer to using the “net start/net stop” commands (more about those later). Since it becomes a bit awkward to change this name later on, it’s better to do it now, before you install the service into Windows. You find the “visible name” of the service in the “Design View” of the Service1 class (or whatever you renamed it to). Take up the Design View and look for the Properties dialogue:

As you see, the ServiceName is listed at the very end of this dialog. Change it to something appropriate for your specific need – I strongly recommend having a name without spaces here (the reason for this will be discussed in a later post), like WindowsServiceSkeleton in my case

Now, it is time to compile the solution (Ctrl-Shift-B). You should now get an .exe file in the Debug folder called eCraft.Labs.WindowsServiceSkeleton.Service.exe:

The compiled results of the project.

To get this program installed now as a service, you would do like this: Start up the Visual Studio 2008 command prompt (or whichever Visual Studio version you are using). Change to the bin\Debug directory. Your command prompt should now be something like this:

Now, to make this service be installed into the Windows Service list, all you need to do is this:

installutil /i <name of .exe file>

When you run this command, the output should look something like this:

Results of running installutil.

It looks as if it has failed (“No public installers with the RunInstallerAttribute.Yes attribute could be found”), and… this is actually correct! We forgot something important: for the service to be installable, you need to have an installer class in it. Let’s go back to Visual Studio and choose “Add New Item” to our project. This time, choose this item template:

The Add New Item dialogue.

The naming of this file is not so easy, actually. If your service is called Service.cs, two logical names would be either ServiceInstaller.cs or Installer.cs. The problem is that both of these names would cause name clashes with other classes that this class needs to use. We call it ProjectInstaller.cs for now (of course, if you called your own service class PizzaService.cs, you could always call the installer PizzaServiceInstaller.cs as well…).

If you are an observative person, you might recognize that Visual Studio adds a reference to the System.Configuration.Install assembly when you press the Add button. This is because the ServiceInstaller class derives from a base class in that assembly.

The code for the ProjectInstaller.cs class looks like this:

using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Configuration.Install;
using System.Linq;


namespace eCraft.Labs.WindowsServiceSkeleton.Service
{
    [RunInstaller(true)]
    public partial class ProjectInstaller : Installer
    {
        public ProjectInstaller()
        {
            InitializeComponent();
        }
    }
}

This will be enough to get the service installable, but… the Service itself will not be installed. This is not done automatically; we need to write installation code for it. So, we modify the file to look something like this:

using System.ComponentModel;
using System.Configuration.Install;
using System.ServiceProcess;

namespace eCraft.Labs.WindowsServiceSkeleton.Service
{
    [RunInstaller(true)]
    public partial class ProjectInstaller: Installer
    {
        public ProjectInstaller()
        {
            InitializeComponent();

            ServiceProcessInstaller processInstaller = new ServiceProcessInstaller();
            ServiceInstaller serviceInstaller = new ServiceInstaller();

            // Run the service as Local System, with automatic startup. These could be modified as needed for your specific
            // service. (The account and start type can always be modified afterwards through the Windows Services MMC console;
            // these are just the defaults.)
            processInstaller.Account = ServiceAccount.LocalSystem;
            serviceInstaller.StartType = ServiceStartMode.Automatic;
            
            // This must be the same as the value we specified earlier, in the in Service.cs "Design View".
            serviceInstaller.ServiceName = "WindowsServiceSkeleton";

            // These are the values that will be displayed int he Windows Services MMC console.
            serviceInstaller.DisplayName = "Windows Service Skeleton";
            serviceInstaller.Description =
                "This service acts as a Windows Service Skeleton, helping people who are learning how to write good Windows " +
                "services.";
            
            Installers.Add(serviceInstaller);
            Installers.Add(processInstaller);   
        }
    }
}

(Of course, customize the DisplayName and Description the way you like.) Let’s build the solution again, and go back to our command prompt. Re-run the previous command. This time, it should work much better:

The service seems to have been installed correctly. Let’s look it up in the list of Windows Services (tip: you can easily get to the list of Windows services by pressing Win-R (for “Run”), and typing “services.msc” in the textbox).

Yahoo! It’s there. Cool, huh? Let’s do one more thing before we end this Part 1 of the Windows Service series of blog postings: we start the service. This time, we make it simple (I’ll show you another way to do it in the next blog posting); we just click on the green “play” arrow in the MMC console. If all works out well, the service will now start, and the Status will be changed to “Started”. You can also look in the event log and you’ll see that the service was started:

Well, that’s it for now! You can now stop the service in the Services MMC console.

We have now gone through the basics of creating a fully functional (but yet meaningless, since it doesn’t do anything) Windows Service, that can be successfully installed using the installutil command. In the next blog posting, we’ll move on to make the service actually do something useful… :-) Until then, I wish you all a great Christmas holiday.