Marcelo's WebLog : Development

Mouse Gestures for Internet Explorer

marcelolr — Fri, 18 Dec 2009 22:00:00 GMT

If there's something that I detest while working on my computer is having to switch between mouse and keyboard. Depending on what I'm doing, I'll typically have a keyboard-centric or mouse-centric approach.

For example, coding is very much a keyboard-centric approach, and I very much dislike having to use the mouse for anything.

Browsing, on the other hand, is largely a mouse-centric thing I do. I still haven't found anything that allows me to navigate links with the keyboard as effectively as I can with the mouse.

Being a mouse-centric experience, all that I can do to keep using the mouse just makes things better. If you haven't checked out Mouse Gestures for Internet Explorer, that's a pretty nifty add-on. I haven't had problems with it so far,

Enjoy!

Of course these opinions are mine and are not meant to represent those of my employer.

Remember JScript closures capture all variables in scope

marcelolr — Tue, 15 Dec 2009 22:00:00 GMT

Just a gentle reminder to readers, that different languages will capture outer variable with their own nuances, and sometimes these will make a difference.

So, for example, C# will capture only what's needed in the inner function. See this post from Bill Wagner for a great discussion on the topic. Raymond Chen also covers this here.

One gotcha found in C# and VB.Net, for example, is that there is a single closure per scope, so if you have multiple functions capturing variables, they will all get the same scope.

ECMAScript also has some gotchas. In particular, just declaring the inner function is enough for all variables in scope to be captured, regardless of whether they are ever used.

You can try it right now in your address bar (yes, another silly trick).

javascript:(function(b){var a=1;var f=function(){alert(eval("a+b"));};f();})(2)

Here is the formatted version of the code:

(function(b) {
var a=1;
var f=function() {
alert(eval("a+b"));
};
f();
}
)(2)

Running this will product a messagebox displaying '3'. So here we have a function that doesn't actually reference any variables directly, but they are still in scope because 'eval' can find them. Yes, parameters are included as well - they are function variables for all practical purposes.

If you had other locals in the function, for example a large array, that wouldn't be collected until the inner function was out of scope for the program, and you'd have to remove the reference 'by hand' by setting it to null for example.

Enjoy!

Debugging Crash Dumps with Visual Studio 2010

marcelolr — Mon, 07 Dec 2009 22:00:00 GMT

If you're visually oriented, you need to check out this video, with escalation engineer Tess Fernandez showing off some very nifty debugging features, including the ability to work with managed-code dump files and the "thread aggregating" stack views. See the whole thing, or jump to ~2:10 to get the dump, ~3:20 to open the dump, ~6:40 to view the parallel callstacks.

For more on the parallel stacks view, this video is your friend.

Enjoy!

Microsoft Web Platform & You

marcelolr — Thu, 03 Dec 2009 22:00:00 GMT

If you build web sites and applications, you owe it to yourself to check out the resources at http://www.microsoft.com/web/ and to subscribe to the feed of the team blog to keep up to date with tools and capabilities. No reason to pass up on free software or to avoid leveraging the software you already have.

Enjoy!

MSXML XHTML DTDs - making the web better

marcelolr — Mon, 30 Nov 2009 22:00:00 GMT

The fix to requests for XHTML DTD files from the W3C Web server has been recently released. Windows Update should offer the fix automatically, but you can download and install the fix manually from the following links for various MSXML versions:

http://support.microsoft.com/?kbid=973688 [MSXML4 SP2... if you haven't tried SP3 yet see below]
http://support.microsoft.com/?kbid=973685 [MSXML4 SP3]
http://support.microsoft.com/?kbid=973686 [MSXML6 Out-Of-Band, for XP SP2 and Win2K3]
http://support.microsoft.com/?kbid=973687 [MSXML3 and MSXML6 for all OSes where these components are in-band]

What exactly is this about? Well, there are a number of cases where this can happen, but one common scenario that we've seen people run into when writing AJAX web pages is to request a page of information from the server, load it into an XML document and extract some information or merge it into the existing page.

The problem with this approach is that when you load the document into an MSXML document "by hand" (ie, not through responseXML on the XHR object), DTD processing is enabled, and the DOCTYPE declaration directs MSXML to go look up the XHTML DTD so you can use entities like  .

Multiply this by each web browser accessing a popular site, and you can imagine why no-one is happy with this situation: web sites break when the resource is not available, the W3C servers get overloaded, and users of web sites lose functionality with odd scripting errors.

The fix caches the XHTML DTDs in MSXML - these resources haven't changed for years and will likely end up in different URLs if something new comes along. So now clients save at least one round-trip (possibly more) and always get the DTD support they need.

Try running this bit of script in a .js file to see the awesomeness in action.

If you don't have the update, you might get an error such as the following.

You have error The server did not understand the request, or the request was invalid.
Error processing resource 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'.

If you do have the update, you'll see the parsed XML. Run this with Fiddler open and you'll "see" the absence of network activity.

Enjoy!

Vistual Studio visualizer for OData

marcelolr — Thu, 19 Nov 2009 22:00:00 GMT

Fabian Winternitz is one of our awesome tools developers, and you can see some of his work in this post. That's a Visual Studio extension that will display searchable diagrams for the model exposed by any service endpoint that exposes OData metadata. Which these days includes a lot of software.

Personally, I think it's great to see on one hand the level of support for the ecosystem, and on the other hand the balance of power, expressiveness and simplicity that OData provides. Back when everything started in the early days of Project "Astoria", I don't think anyone had any idea as to how broad a spectrum of software components would play in this space, but it looks like sticking to simplicity and proven standards paid off.

Enjoy!

XmlLite says: error C2146: syntax error : missing ';' before identifier 'IXmlReader'

marcelolr — Sat, 06 Jun 2009 00:00:00 GMT

This is something that I've been asked more than once, and so here goes an answer that might help if you run into this.

Let's say that you create a new project and borrow code or do something of the sort, and suddenly start getting an error message such as this one

xmllite.h(49) : error C2146: syntax error : missing ';' before identifier 'IXmlReader'

This typically points to a missing macro. You can fix this by adding this to your include headers:

#include "objbase.h"

If you're using Visual C++-style projects, this may already be included via stdafx.h including the Windows headers for you.

Debugging and PDBs

marcelolr — Wed, 13 May 2009 00:00:00 GMT

Debugging is hard. There are many things we do to make it easier on ourselves.

Feature-level things like building tracing and logging capabilities.
Design-level things like having clear points at which state is checked for consistency (internal or parameters passed in, for example), so we narrow down the areas where things might have gone wrong.
Code-level things like making sure that exceptions bubble up without losing the stack.
Operational-level things like using tools to capture dumps on failure and monitoring performance counters, to have good data about the program and its environment.

John Robbins has a great post about build-time and environment-setup-time things you can do to make your debugging life easier, and PDB files are a big part of it. If you haven't debugged symbol-indexed and source-indexed programs in the past, you're in for a treat.

http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

Enjoy!

Abstraction, simplicity and predictability

marcelolr — Fri, 17 Apr 2009 00:00:00 GMT

As a short follow-up to my last post on reasoning about code, I wanted to touch upon abstraction in general - meaning "information hiding" in the general sense, and not necessarily a particular programming mechanism such as polymorphism or some such thing.

Abstraction buys us a number of good things for a design - the ability to think about things using fewer concepts (because we can focus on the more general stuff) and the ability to change system behavior by changing an isolated part (the abstracted part), to name the first two that come to mind. In general, abstraction is a great way to have the consumer of the abstract focus on something, by hiding or diverting focus away from the implementation particulars.

There is a price to the use of abstraction, however. Well, there's more than a single thing in practice, but I want to focus on one. When you choose what to hide, you may run into the risk of making the system behavior harder to predict, and as such more difficult to reason about.

For example, if my abstraction doesn't explain some basics of the performance characteristics of the implementation, my only recourse is to profile to understand how the system will behave overall (you should profile anyway, but that's a separate matter). Or an abstraction might not give clear rules as to what happens when an object enters an error state - should you "not touch it", try to dispose of it, continue using it, or what?

I'm not advocating any particular solutions or tradeoffs here, but instead I just want to bring awareness to the fact that there is a trade-off to be considered. It's good to know how others will reason about our code, even if just to say "this isn't specified and you can't count on anything, so you should be careful and something". Whether the "something" is 'ignore this', 'bail out', 'work around this', 'assume worst case', 'terminate the process', or something else, there should still be a clear way of explaining and reasoning about our code.

Reasoning about code

marcelolr — Thu, 16 Apr 2009 00:00:00 GMT

When we have conversation about API design, or more generally about fragments of code that we write or we think customers will write, we often talk about reasoning about code. We typically mean that someone reading the code will be able to understand the implications of making an API call for example, and write clean code accordingly. There is always a component of simplicity in code someone can reason about.

For example, someone might say that functional-style code is easier to reason about, because there are no side-effects and so you can concentrate on whatever local computation a given function does. Or someone might say that it's hard to reason about code that deals with an object that has entered an error state, because the results of operations are undefined and it's hard or impossible to keep track in your head about what the consequences of any given API call might be.

I think that beyond simplicity, the core of code you can reason about is predictability. To the extent that you can predict the behavior of a fragment of code, and it's straightforward enough, you can reason about what the code does and what the impact of changes would be.

Going back to the previous examples, functional-style code is easier to reason about because once you predict what it does locally, you understand the complete picture - there are no other, off-to-the-side effects. When an object is in an error state, you can't use it anymore ("you can't touch it", you might say) if you can't predict what it will do - the core of the problem is that you can no longer infer things about its behavior and put it together with other concepts to use it.

Using partial methods to extend generated code

marcelolr — Wed, 15 Apr 2009 00:00:00 GMT

To wrap up a bit on the partial class support for generated code scenario, let's look at a case we missed. Although our workflow is great for "structural" code (fields and simple properties and such), what about methods? For example, let's say that we want to add validation logic to a property setter.

The problem we'll run into is that the property setter has already been defined in the generated file, and there's no way to extend this directly. Well, we can always add code to the generated file, but we're back to square one with the problem of having our changes overwritten if the code is re-generated.

The solution C# offers is the use of partial methods. Partial methods can be declared more than once, but must have a body only in at most a single file. The interesting thing is that it's OK for a partial method to have no body it all, in which case the compiler can simply ignore the method everywhere - no calls will be made, and the method itself won't exist in the assembly.

For example, we can have a FirstNameChanged method that takes in the new value of the property declared in the code-generate file, and called by the FirstName property setter. If we choose to supply an implementation for the method in another file, we'll get called - otherwise, nothing happens.

Note that there are restrictions as to what the signature of a method may look like - in general, you can't depend on values being returned directly or through out parameters, but modifying things through ref parameters (or mutable parameters) is OK.

For example, let's say I have a file with this code.

namespace CsNamespace
{
  using System;
  using System.Text;

  public partial class Cs
  {
    partial void SayHello();
    partial void SayHelloHere(StringBuilder builder);

    public static void Main(string[] args)
    {
      Cs cs = new Cs();
      Console.WriteLine("Invoking SayHello...");
      cs.SayHello();

      StringBuilder sb = new StringBuilder();
      Console.WriteLine("Invoking SayHelloHere...");
      cs.SayHelloHere(sb);
      if (sb.Length == 0)
      {
        Console.WriteLine("Nothing happened.");
      }
      else
      {
        Console.WriteLine("Something happened!");
        Console.WriteLine(sb.ToString());
      }
    }
  }
}

Now, if I compile it on its own, this is the output I get.

Invoking SayHello...
Invoking SayHelloHere...
Nothing happened.

However I can go ahead and add an additional file to the project.

namespace CsNamespace
{
  using System;
  using System.Text;

  public partial class Cs
  {
    partial void SayHello()
    {
      Console.WriteLine("Hello");
    }

    partial void SayHelloHere(StringBuilder builder)
    {
      builder.AppendLine("Hello");
    }
  }
}

Now, if I compile both files and run, this is the output I get.

Invoking SayHello...
Hello
Invoking SayHelloHere...
Something happened!
Hello

As you can see, all the partial calls were now made into the implementation I defined in the extra file.

Enjoy!

Using partial classes with nested classes for maintainability

marcelolr — Tue, 14 Apr 2009 00:00:00 GMT

C# allows you to create nested classes - that is, classes that exist "within" a different class. Depending on what visibility you give these classes, they can be just as public as anything else (the Environment.SpecialFolder enumeration is such an example). If you use 'internal', other classes in the assembly will be able to see it, but not classes in other assemblies.

The special thing about nested classes is that you can declare them as private (the default), in which case only the containing type gets to access the class. This allows for a more controlled usage of the class, and is great for helper classes that should only be used by a single class.

One of the problems you may run into when using nested types is that if they have any reasonable size at all, it's likely that the file in which they're used ends up looking very odd - you usually end up with a much bigger file than in the rest of your project, and when you're on a method it may be difficult to tell which class the method is in. In a way, it breaks down the good advise of not having many classes in a single file.

Can you have your cake and eat it too? Of course (this would be a poor blog post otherwise I guess). Partial classes come to the rescue again. In this case we're not using them to be able to separate tool-generated from "us-"generated code, instead we're using them to separate a nested class into its own file.

To work on the previous example, let's say I have a file that declare a class Cs and uses a nested class NestedClass.

namespace CsNamespace
{
  public partial class Cs
  {
    public static void Main(string[] args)
    {
      // Here we can also refer to Cs.NestedClass as 'NestedClass'.
      NestedClass instance = new Cs.NestedClass();
      instance.FirstName = "Marcelo";
      instance.LastName = "Lopez Ruiz";
      System.Console.WriteLine(instance.FullName);
    }
  }
}

Now I can include this in a separate file and compile both of them together in the same project. Note that the class I've marked as partial is Cs - in this example, I have no need to mark NestedClass as partial, as its complete definition can be found in this single file.

namespace CsNamespace
{
  public partial class Cs
  {
    private class NestedClass
    {
      public string FirstName { get; set; }
      public string LastName { get; set; }
      public string FullName
      {
        get { return this.FirstName + " " + this.LastName; }
      }
    }
  }
}

Other classes in the project will now need to "behave", and they can't break the encapsulation provided by the private nested class.

public class AnotherClass
{
  public void Foo()
  {
    // Uncommenting this gives error, for example:
    //
    // error CS0122: 'CsNamespace.Cs.NestedClass' is 
    // inaccessible due to its protection level
    //
    // Cs.NestedClass instance = new Cs.NestedClass();
  }
}

Enjoy!

Using partial classes for cleaner, more maintainable code

marcelolr — Sat, 11 Apr 2009 00:00:00 GMT

Frequently you'll write classes that represent a concept that is also described elsewhere. For example, you'll have a class that represent a row in a table, a service the web or the graphical design of a form. These external concepts have descriptions which can be consumed by machines, for example through SQL metadata queries or through XML descriptions of structure or services.

It's often handy to generate the code from these descriptions. For example, I can query a database to find out the columns a table has, and then create a class with one field per column. I can then create instances of this class to represent and manipulate rows. Handy-dandy, except that now I run into a problem when I want to re-run this code generate process: if I overwrite the existing files, I'll lose whatever changes I made by hand since the last generation.

C# has a nice feature that helps with this: partial classes. When you add the partial keyword to a class, you're telling the compiler "there might be additional things defined for this class in another file". Note that you can't use partial to split code between assemblies or anything funny - it's just compiler magic, and at the end of the day it's a lot like copy-pasting the contents from one file inside another.

Let's see an example. Let's say I have a file cs1.cs, which contains structure that I mapped from somewhere, perhaps a table in a database or some known arrangements of keys in the registry.

namespace CsNamespace
{
  public partial class Cs
  {
    public string FirstName { get; set; }
    public string LastName { get; set; }
  }
}

Now, let's say that I want to also add a "calculated field" to this, FullName. And while I'm at it, I also want to turn this class into an assembly entry point, so I can just compile the class and have a program. I can write the following file and save it as cs2.cs.

namespace CsNamespace
{
  public partial class Cs
  {
    public string FullName
    {
      get { return this.FirstName + " " + this.LastName; }
    }

    public static void Main(string[] args)
    {
      Cs instance = new Cs();
      instance.FirstName = "Marcelo";
      instance.LastName = "Lopez Ruiz";
      System.Console.WriteLine(instance.FullName);
    }
  }
}

This will now work just fine when compiled together.

> csc.exe /out:cs.exe cs1.cs cs2.cs
...
> cs.exe
Marcelo Lopez Ruiz

You can read more on partial classes on MSDN.

Enjoy!

GetCurrentMethod and lambdas - watch out

marcelolr — Wed, 01 Apr 2009 00:00:00 GMT

Got bit by this a few moments ago... Thankfully it didn't take long, but probably because this was fairly isolated in my case; I could imagine getting stuck for a bit longer if this were a larger piece of code.

Anyway, I was running method that goes through a array and looks for a reference to the method itself, using MethodBase.GetCurrentMethod. I had the following code.

public void AnInterestingMethod()
{
  var result = Thingy.ListInterestingMethods(this.GetType().Assembly);
  Assert.IsTrue(result.Any(method => method == MethodBase.GetCurrentMethod()));
  ...

And yet I wasn't finding a match. After looking at this for a bit, I realized that of course the GetCurrentMethod call won't execute in this method, but in the lambda, with its own anonymous function.

The following rewrite shows finds the method as expected.

public void AnInterestingMethod()
{
  var result = Thingy.ListInterestingMethods(this.GetType().Assembly);
  MethodBase m = MethodBase.GetCurrentMethod();
  Assert.IsTrue(result.Any(method => method == m));
  ...

Now the GetCurrentMethod call executes in the interesting method itself, which of course makes it show up in the list.

Enjoy!

Velocity at DevConnections

marcelolr — Sat, 21 Mar 2009 00:00:00 GMT

Next Monday I'll be at DevConnections in Orlando, talking about Velocity (Microsoft Project Code Named "Velocity", if you like formality).

It's going to be a bit of a challenge to sum up all that awesomeness into a single session, but I promise I'll do my best, and I'll be around for the rest of the event in case anyone wants to get in touch. Contact through email and blog will be slow, but should get back in rhythm after the event.

In case you find the online list a tad long to search through, the session is titled an unsurprising MDA02: Microsoft Project Codenamed Velocity: A Distributed In-memory Cache.

See you in Orlando!