After you finally manage to get Table Storage working (see nice tutorial here) you’ll try to deploy it to your staging environment. That means you need to change the configuration.

There are three settings to use: AccountName, AccountSharedKey and TableStorageEndpoint.

Unfortunately, the values you need for them aren’t what you would naturally expect.

AccountName: This isn’t your account name, but the name of your storage account. (I guess that’s why it has to be a unique name at the time you create it.) On the summary page of your storage project you will only see the value you need in the list of endpoints. It’s the first part of each of the three domain names.

AccountSharedKey: This is the Primary Access Key as found in the summary page of your storage project in the developer portal.

TableStorageEndpoint: This isn’t the endpoint as described in the summary page, but rather a shortened version. Just lop off the AccountName part of the endpoint you use as described in the summary page. That should give you something like http://table.core.windows.net.

For more information see this article on MSDN.

It is so time-consuming to get right, that it really makes sense to follow the advice in the documentation. First, test locally. Then test your local hosted app using the live Storage account. Finally, load your app and test that in the staging environment.

Saying that, I haven’t yet managed to get the second scenario to work. It just crashes on start-up. (Help!)

I started to learn how to use the Azure Cloud Service from Microsoft this week. Currently it’s still in Tech Preview stage. Unfortunately you can tell that from the SDK documentation.

Here’s some useful links to get you going:

1. Screencasts: http://msdn.microsoft.com/en-us/azure/dd439432.aspx
   These are quite basic, but trust me, you need them to be basic to get you started.
2. SDK: http://www.microsoft.com/downloads/details.aspx?FamilyID=80e3eabf-0507-4560-aeb6-d31e9a70a0a6&displaylang=en
   Contains CHTM-style documentation, tools and samples. Don’t expect too much from the docs; they explain enough to get you confused, and then have an API reference. You need to unzip the samples and get into them to start understanding how everything fits together.
3. Visual Studio Templates: http://www.microsoft.com/downloads/details.aspx?FamilyID=8e90b639-1ef0-4e21-bb73-fc22662911bc&displaylang=en
   This gives you a set of project and item templates which you can use to create and publish Azure applications. Don’t worry about the extra projects it adds to a solution, or the config files. You will learn more about them later.
4. The Azure developer center on MSDN: http://msdn.microsoft.com/en-us/azure/default.aspx

Assuming you already registered for Azure, that’s all you really need to get started.

The biggest problem I found at first was deploying an app. Once you have generated an Azure project in Visual Studio, you expect to be able to publish it from Visual Studio too. Unfortunately you can’t, and it takes a little more effort. I’ll write more about that in another post.

I also needed help trying to understand what to focus on to get started. So here’s a big tip: Ignore .Net Services, Live Services, and SQL Data Services. They aren’t part of Azure per se. You can come back to them later. First you just need a hosted project and some storage – either blob storage or table storage. (There’s also queue storage, but I bet no one will want to use that straight away – it’s for tying two apps together, which no one will want to do at first.)

I recommend you download the SDK and the Visual Studio templates, create yourself a “Web Role” project (which is really the equivalent of an ASP.Net project), and work on that. Then move onto table and blob storage. You can use the screencasts to help you.

Good luck getting started!

I’ve been very quiet recently. (I’m trying to not be so loud, Scott. ) You see, I’ve been writing a lot of ASP.Net code for a site I’m working on. And, to be honest, I’ve been having a lot of trouble. The source code for .Net has been very helpful, and I’ve learnt a lot about what’s going on under the covers of ASP.Net because of it.

(Note: I won’t comment here on the quality of the code I’ve found – I’ll leave that up to you to judge. But in any case, I’ve been trying to build on top of it.)

One thing I’ve found to be important is the reliance on Web Controls. (It’s got something to do with javascript libraries, but that’s another story.) Getting away from the "standard" way to do ASP.Net isn’t easy though. Even the ninjas on the ASP.Net MVC team seem to be having trouble. However, with the magic of lambdas and extension methods in C#, I think I might have just about managed to get something usable. I thought I’d publish my work here, and see what comments I got.

I think it’s best to start with what my ASP.Net code looks like once I’ve got everything working. (Notice I still have some Web Controls in there, but that’s because I’ve not worked out how to do sorting of data without web controls yet.)

The inspiration for this was taken from the improvements made to NVelocity by the gurus on the Castle Project. I thought it looked great, and I’d like something similar, but I didn’t really want to learn a whole new scripting language and integrate it into my working environment just for rendering a bit of HTML. So I built some C# classes to do a similar thing for me instead. It’s not as nice as NVelocity, but it’s okay for now.

Warning: The following code may contain statements of a disturbing nature to more sensitive readers. We cannot be held responsible for any confusion, delusion or mental illness caused by this code.

It starts by taking a collection of Task objects, and calling the extension method "ForEach" on them:

<% Tasks.ForEach(sections => {
   sections.NoData = tasks => {
%>
   <p>
   Hey, you've got nothing to do.</p>
   <p>
<%
   };
   sections.BeforeAll = tasks => {
   %>
  <table class="task-list">
    <tr class="task-list-header">
      <th>
        <asp:LinkButton runat="server" CommandName="Sort" CommandArgument="StartDate"
          Text="Started" />
      </th>
      <th>
        <asp:LinkButton runat="server" CommandName="Sort" CommandArgument="DueOn"
          Text="Due" />
      </th>
      <th>
        <asp:LinkButton runat="server" CommandName="Sort" CommandArgument="Priority"
          Text="Priority" />
      </th>
      <th>
        <asp:LinkButton CssClass="task-description" CommandName="Sort" CommandArgument="Title"
          Text="Description" runat="server" />
      </th>      <th>
      </th>
    </tr>
   <%
   };
     sections.Before = task => {
    %>
    <tr class="<%= this.tableCssClasses.Next() %>">
    <%
   };
   sections.Each = task => {
    %>
    <td>
      <div class='calendar calendar-icon-<%= task.StartMonth %>'>
        <div class="calendar-day">
          <%= task.StartDayOfMonth %></div>
      </div>
    </td>
    <td>
      <div class='calendar calendar-icon-<%= task.DueMonth %>'>
        <div class="calendar-day">
          <%= task.DueDayOfMonth %></div>
      </div>
    </td>
    <td>
      <%= task.Priority %>
    </td>
    <td class="task-title">
      <a href='<%= Href.For("~/Tasks/{0}/Show.aspx", task.ID) %>'><%= task.Title %></a>
    </td>
    <td>
      <asp:Button ID="Button1" runat="server" CssClass="button" CommandName="Delete" Text="Mark Done" />
    </td>
    <%
   };

   sections.After = task => {
    %>
    </tr>
    <%
   };

   sections.AfterAll = task => {
    %>
    </table>
    <%
   };
 });
%>

It might take a while to grasp what’s going on here. The code actually starts using an Extension method to IEnumerable that looks like this:

public static void ForEach<T>(this IEnumerable<T> enumerable, ForeachSectionSetter<T> sectionSetter) {
  if (enumerable != null) {

    if (sectionSetter != null) {
      ForeachSections<T> sections = new ForeachSections<T>();
      sectionSetter(sections);

      if (enumerable.Count() == 0) {
        if (sections.NoData != null)
          sections.NoData(enumerable);
        return;
      }

      if (sections.BeforeAll != null)
        sections.BeforeAll(enumerable);

      int itemIndex = 0;
      T previousItem = default(T);

      foreach (T item in enumerable) {
        if (sections.Before != null)
          sections.Before(item);
        if (itemIndex % 2 == 1 && sections.Odd != null)
          sections.Odd(item);
        if (itemIndex % 2 == 0 && sections.Even != null)
          sections.Even(item);
        if (itemIndex > 0 && sections.Between != null)
          sections.Between(previousItem, item);
        if (sections.Each != null)
          sections.Each(item);
        if (sections.After != null)
          sections.After(item);
        itemIndex++;
        previousItem = item;
      }
      if (sections.AfterAll != null)
        sections.AfterAll(enumerable);
    }
  }
}

The delegate ForEachSectionSetter is used by the calling method with a lambda expression. As a parameter it receives an ForeachSections object, which looks like this:

public class ForeachSections<T> {
  public Action<T> Each { get; set; }
  public Action<IEnumerable<T>> BeforeAll { get; set; }
  public Action<T> Before { get; set; }
  public Action<T,T> Between { get; set; }
  public Action<T> Odd { get; set; }
  public Action<T> Even { get; set; }
  public Action<T> After { get; set; }
  public Action<IEnumerable<T>> AfterAll { get; set; }
  public Action<IEnumerable<T>> NoData { get; set; }
}

The calling method gets the chance to set the properties of this class before it is returned to the constructor of the ForEach method for processing. And because each property is already preset to a default value (Null in this case), the constructor can use the ForeachSections object just like a set of default or optional parameters. The caller can simply set values to the properties it needs, and ignore the rest.

If I had tried this another way, using overloadable constructors, it would have led to multiple constructors with indistinguishable signatures. If I’d have used property initializers, I wouldn’t have been able to run the whole routine without requiring a second call to the object, which actually wasn’t possible.

Basically, I couldn’t think of another way to do it.

The properties of the ForeachSections object are all delegates too. That means that we can use them with lambdas, which gives us lambdas inside of a lambda. (Hmm, very confusing!)

So what do you think? Could you use something like this? Can you make it simpler? Leave me a comment if you can.

Have you wondered if and when you should use the new LINQ features in .Net 3.5?

Like, where should I put a new extension method? Should I use Func<T> or a custom delegate? How do I best implement a mix-in (extension methods on an interface)?

Well, Mircea Trofin has just published a new draft of some LINQ design guidelines. You might just find your answers there.

Visual Studio 2008 has lots of goodies in it, like LINQ syntax, CSS editing, and testing tools. There’s a lesser-known feature which I really appreciate though – the “Remove and Sort Usings” command in the C# editor.

You activate the command by placing your cursor over the using statements and clicking on the right mouse-button.

Using this groovy tool, I’ve been able to go through my old ugly C# files and get rid of all the superfluous using statements, then tidy them up, all at the click of a button. It’s something I always wanted to do, but had no time for, and didn’t want to pay for an extra tool to do it for me.

The only problem with the feature is that you have to go through every file and right-click on the “using” statements to tidy them up. That can get a bit tedious, but it’s worth it.

But now it’s the Visual Studio Extensibility Team to the rescue!

The VSX team at Microsoft have just released PowerCommands for Visual Studio 2008. It’s a free tool for Visual Studio with loads of new tools for making a VS-developer’s life easier. And one of those new tools is a Remove and Sort Usings command at the project level.

You activate it with a right-click on the project itself.

The tool then does the same Remove and Sort command for every file in the project.

Tip: Make sure your project is buildable before using the tool. If there is an error stopping the build from running, you will get dialogs asking you to confirm every change in every file.

PowerCommands for Visual Studio 2008 also contains commands for:

• Collapse Projects
• Copy Class
• Paste Class
• Copy References
• Paste References
• Copy As Project Reference
• Edit Project File
• Open Containing Folder
• Open Command Prompt
• Unload Projects
• Reload Projects
• Remove and Sort Usings
• Extract Constant
• Clear Recent File List
• Clear Recent Project List
• Transform Templates
• Close All

So, where can you get the tool?

The official site for PowerCommands is at the Visual Studio Gallery, but when you get there, you won’t see a download button. You actually have to click the “Learn More” button to go to the download page at the MSDN code gallery.

You can read more about PowerCommands on the Visual Studio Team Extensibility blog.

Yesterday I thought I’d learn about the LinqDataSource in ASP.Net 3.5, and got an interesting surprise.

The new LinqDataSource can also be used with a LINQ-to-SQL model to perform updates. You simply add the DataSource to your page, set the table name, and set EnableUpdate to true. Then, using a standard DataControl, you can make updates to your data entities.

The question is, how does this work? It appears to be a bit magical.

The Magic of LINQ

In a previous post, I mentioned that LINQ-to-SQL updates can be done in two ways: either you make a call to retrieve a row, then update it, or you provide known values for all fields and try to update using optimistic concurrency.

If the LinqDataSource used the first technique, the performance might be bad. Plus, it would have to only update those fields that had been updated by the DataControl, and ignore the rest. That wouldn’t make sense, so I correctly supposed that was not what was happening.

It makes more sense that the LinqDataSource would use the values input by the user to make the changes. It could use optimistic concurrency to compare all the entered values.

The problem is, I don’t always display all fields from a particular row on the form, so how would the LinqDataSource know what the missing fields were. Remember, all the fields involved in the update are required for the optimistic concurrency to work. That is usually all the fields in a row, and they aren’t usually all displayed.

So, have a guess. Where does the LinqDataSource store it’s values?

Let’s think now. Where would be the easiest place to keep it? To keep it really simple, I’ll let you ignore all other aspects of building an application, like security or performance.

Yep, you guessed it – ViewState.

The ViewState actually contains all values for all the fields in a LINQ-to-SQL entity by default. Those values are sent to the client, even if the user isn’t supposed to be able to see them.

Aaaarrgghhhh!

Now, let’s not get overexcited. The ViewState is encoded, so it’s not easy to just go and change it. But it’s not impossible. In general, I don’t think it’s such a great idea to have all data sent to a client by default. Someone is going to overlook something one day, and there’ll be a costly mistake.

And what if you display a large grid using the LinqDataSource. Well, you aren’t just getting the ViewState from the grid sent back and forth with your page, but the LinqDataSource is going to store all your data retrieved in the ViewState too.

Bummer!

Great control. Large overhead.

Kicking out the ViewState

The good news is that the ASP.Net team realized that this was a problem and did something about it.

If you look carefully, you will notice that the LinqDataSource has a property StoreOriginalValuesInViewState. By default (sigh) that property is set to true. If you set it to false, the control won’t work any more. Simple as that.

Here’s what the official documentation has to say about that:

If you set the StoreOriginalValuesInViewState property to false, the original values are not persisted in view state for the data-bound control. In that case, LINQ to SQL cannot verify the integrity of the data. LINQ to SQL will throw an exception that indicates a data conflict even if the data in the data source has not actually changed.

That’s in the remarks section of the LinqDataSource.StoreOriginalValuesInViewState property documentation.

Funnily enough, the same section states the problem with stuffing data into the ViewState:

Storing the original values in view state can cause the page size to become unnecessarily large and can expose sensitive data to a malicious user.

Now, I don’t know about you, but that looks like a pretty serious warning to me. Why isn’t it in a more obvious place, like as a comment that pops in up Intellisense whenever you use a LinqDataSource?

Check the UpdateCheck

So how do you handle it? How can you use the LinqDataSource?

The answer lies in the generation of the LINQ-to-SQL model which you generate. Each entity field has a Column attribute which allows you to specify if it is used for checking during an optimistic concurrency field comparison.

For example, you could create a Model with the following Property:

[Column(Storage="_AddressID", UpdateCheck=UpdateCheck.Never, ...
public int AddressID
...

Notice the UpdateCheck.Never value. That means that the field will not be used in the optimistic concurrency check.

The documentation helps a little again:

By default, when update and delete operations have been enabled, the LinqDataSource control stores the original values for all the records in view state. The LinqDataSource control stores values for all primary keys and all properties not marked with UpdateCheck.Never in the Column attribute. You set the UpdateCheck property of the Column attribute in the O/R Designer.

Admittedly, I haven’t yet tried that, so I don’t really know how if you can change that setting for a field without changing generated code, which would be a big no-no. I’ll just have to get back to you on that.

Stamp In, Please

However, there is a shortcut trick.

Basically, if you add a field of type timestamp to your record, only that field will be used for the concurrency check, and only that field’s data will be stored in the ViewState.

If the underlying data source contains a timestamp field that is automatically updated during an update, you can store only that value in view state. In that case, the timestamp property in the entity class is set to IsVersion=true and all the properties are set to UpdateCheck.Never. Because a timestamp field is automatically updated by the database every time that data in that record changes, LINQ to SQL determines from that value if data has changed. This helps reduce the size of view state, and no sensitive data is exposed. LINQ to SQL will check for data consistency by comparing the timestamp value in view state with the timestamp value in the database.

The documentation is great, if you know where to find it.

Conclusion

So, the answer is, if you use the LinqDataSource to throw a quick application together, make sure you use a timestamp field in your table. Call it UpdatedOn, or something. It will make the use of the LinqDataSource a lot easier, if only because you’ll sleep better not worrying about it.

Until recently I thought this was a well-known feature. After demonstrating it a few times, I found out it wasn’t.

A long time ago, in an cubicle far, far away, someone created the .Net Framework. To cut a long story short, they simultaneously produced guidelines for creating Exception classes, which you should always use or face having your fingernails pulled out with a staple-gun.

The guidelines state:

“Use the common constructors shown in the following code example when creating exception classes. “

[C#]

public class XxxException : ApplicationException
{
public XxxException() {… }
public XxxException(string message) {… }
public XxxException(string message, Exception inner) {… }
public XxxException(SerializationInfo info, StreamingContext context) {…}
}

If you don’t believe me, you can look here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconerrorraisinghandlingguidelines.asp

Now, I don’t know about you, but I can’t remember all that every time I create a custom exception class. Maybe that’s why the guidelines also state:

In most cases, use the predefined exception types. Only define new exception types for programmatic scenarios, where you expect users of your class library to catch exceptions of this new type and perform a programmatic action based on the exception type itself.

But let’s ignore that. It’s not relevant.

So, did you know that there is a Visual Studio code snippet that does the work for you? Here’s how you use it.

1. Create a new class.
2. inside the namespace definition of the new class, type

   Exception

3. Press the tab key twice.

You then get the following code, free of charge:

[global::System.Serializable]
public class MyException : Exception {

  public MyException() { }
  public MyException(string message) : base(message) { }
  public MyException(string message, Exception inner) : base(message, inner) { }
  protected MyException(
  System.Runtime.Serialization.SerializationInfo info,
  System.Runtime.Serialization.StreamingContext context)
    : base(info, context) { }
}

What’s more, you get code snippet functionality which automatically changes the names of all the constructors when you change the name of the class.

I wonder what other code snippets are available. Do you know of any cool ones? What are your favorites?