Gilles' WebLog : Code

WF 4.0 Tracking on .NET Endpoint

gzunino — Fri, 12 Jun 2009 04:05:00 GMT

Vikram has a very nice acticle on tracking in WF 4.0. Worth reading it at: http://blogs.msdn.com/endpoint/archive/2009/06/11/introduction-to-workflow-tracking-in-net-framework-4-0-beta1.aspx ....(read more)

BizTalk Decompiler for Reflector 5 on CodePlex

gzunino — Thu, 28 Jun 2007 01:44:00 GMT

My BizTalk Decompiler only works with Reflector 4. The updated version for Reflector 5 has been available for a while on CodePlex: http://www.codeplex.com/reflectoraddins...(read more)

Debugger Visualizer for BizTalk 2006: MessageContext

gzunino — Mon, 20 Mar 2006 21:10:00 GMT

Visual Studio 2005 added support for Debugger Visualizers. With debugger visualizers, developers can define what information (and in what form) is shown in the debugger for a specific type. There are many visualizers for various .NET types floating around. Here is a small list of the most popular ones: ASP.NET Cache, Regular Expression, XmlDocument (and other Xml related types), a powerful looking DataSet visualizer and there is even a WindowsIdentity visualizer.

I am not going to explain in details how to write your own visualizer. You can find step by step instructions on MSDN. Most existing debugger visualizers I mentionned in the previous paragraph also have home pages where you will find details on how to write your own or even source code.

I'd like to share some tricks you might find useful when writing your own visualizers:

You can write visualizers for public (obvious!) or internal or private types. The trick for non public types is to use the Assembly Qualified Name of the type you want to visualize. For instance, BizTalk 2006's MessageContext property is actually an internal type (see purple type name below):

[assembly: DebuggerVisualizer(typeof(<type of visualizer> ), typeof(<type of visualizer source>), TargetTypeName = "Microsoft.BizTalk.Message.Interop.MessageContext_ManagedViewOfNative, Microsoft.BizTalk.Pipeline, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35", Description = "<description>")]

Your visualizer code runs non JIT'ed. So make sure you do not perform too much work or it will be slow. If you do too much, the expression evaluator will time out and interrupt your visualizer with an "Expression Evaluation timed out exception".
Use DataGrid instead of DataGridView. I know I used a DataGridView in my visualizer, but the DataGrid is faster, especially when running non JIT'ed.

To illustrate these points, I wrote a BizTalk 2006 MessageContext debugger visualiser. You can download the complete solution BTSVisualizers.zip below. It works with Visual Studio 2005 and BizTalk 2006 only.

Load the visualizer solution in Visual Studio and build the release comfiguration.To install the MessageContext visualizer, shut down all instances of Visual Studio and copy BTSVisualizers.dll to %VS8ROOT%\Common7\Packages\Debugger\Visualizers. (If you installed Visual Studio at the default location, that would be C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\Visualizers) That's it!

The next time you debug a pipeline (by attaching to BTSNTSVC.exe), you can hover the mouse on the "Context" variable of the message and see all entries in the message context:

Unfortunately, this visualizer will not display anything useful unless you are debugging a BizTalk artifact by attaching to BTSNTSVC.exe. This is because most debugging tools (like pipeline.exe) do not populate the message context.

HTTP response split attacks, HttpWebRequest and the NET Framework 1.1 SP1

gzunino — Sun, 05 Sep 2004 19:04:00 GMT

The .NET Framework 1.1 SP1 shipped recently and was pushed to Windows Update so you probably were already offered to download it. There is a package for Windows XP and or Windows Server 2003.

This release contains several fixes but also attempts to enhance security. This is the case of System.Web.HttpWebRequest. It now detects if an HTTP reponse split attack might be in progress and raises "The server committed an HTTP protocol violation" error.

For instance, look at this example of HTTP headers returned by some server:

HTTP/1.1 200 OK
Via: 1.1 SOMEPROXY, 1.1 ANOTHERRANDOMPROXY
Content-Length: 4171
Date: Fri, 03 Sep 2004 18:02:23 GMT
Content-Type: text/xml
Last-Modified: Fri, 03 Sep 2004 17:08:42 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content Length: 51

When presented with this response, the SP1 version of HttpWebRequest will fail because you can't have a space in a header name. It should really be Content-Length. As you can see, the client application will raise an exception but the server is really at fault here and should be fixed. The client only protect itself by refusing a non-conformant, potentially dangerous response.

This change has already been noticed, mostly by user of .NET based RSS aggregators and they figured out that there is a way to disable the security improvements by altering the appropriate .config file.

This setting is only recognized by .NET 1.1 SP1. If you only have .NET 1.1, your application will fail if it encounters this setting. It might make installers slightly more complex.

Now, let me get on my soap box for a second: I know it is tempting to revert back to the unsafe header parsing to "fix" this but resist the temptation. If you find a site that exposes this behavior, contact them and ask them to fix it.

One possible solution to implement Picking: 2D trees

gzunino — Mon, 07 Jun 2004 03:32:00 GMT

Most Computer Aided Design applications (like Microsoft Office Visio 2003) present users with a design surface where various objects can be dragged and dropped. When the user clicks on the graphical of an object on the screen, the application has to locate the internal representation of the object that was clicked knowing only the (x, y) coordinates of the mouse pointer at the time of the click. This process is also known as “Picking”.

Picking can be seen as a special case of a more general problem: Range searching. Assuming we have a set of records with certain attributes, a range searching algorithm finds all the records satisfying specified range restrictions on a specified set of attributes. This is an important and complex problem.

Most of the time, range searching algorithms split problems into two phases: a preprocessing phase where adequate data structures are built and a searching phase where the aforementioned data structures are searched for matching records.

To simplify this post, we will assume that we have a set of points in the plane (these are our records) and the attributes are the coordinates of the points (x, y). We are trying to answer the following question: given a rectangle rect, what are the points that are inside this rectangle?

A brute force solution would be to test every single point against the rectangle’s coordinate. However, this method is sub-optimal since it performs a lot of un-needed comparisons. It turns out that we can solve this problem in a better way by using two-dimensional trees. Those trees are very similar to binary search trees but divide up the geometric space in a manner that is convenient for range searching.

A 2D binary tree is built almost like a binary search tree. The only difference is that we use the y and x coordinates of the points as keys in a strictly alternating sequence. At the root, we use the y coordinate (if the point to be inserted as a smaller y coordinate than the point at the current node, go left otherwise go right). At the next level we use x as the key. Basically, we start by using y as the key for the root and alternate between y and x for every level in the tree.

At the root, we divide the plane in two regions: the region of all the points below the point at the root on the left and all those above go on the right subtree then all the points above the point at the root and to the left of the point in the right subtree go in the left subtree of the right subtree of the root. The process goes on recursively and it creates vertical and horizontal dividing lines. An horizontal diving line is created at level y for all points above coordinate y and a vertical dividing line is created at level x for all the points on the right of a given value x. With this technique, we can quickly eliminate a lot of points from the possible set of points to test.

The search phase takes advantage of the previously built 2D tree. We test the point at each node against the range along the dimension used to divide the plane for that node. There is one interesting special case: searching should be allowed to analyze both subtrees (right and left) if a dividing line cuts the rectangle being considered. Note that the searching code and the tree construction code should be synchronized: the search code should not be able to look for x coordinates at a level where the tree was built using y as a key.

Now, here is my implementation. Each node in the tree will be represented by the node class below. The class holds a reference to the right and left child and the point coordinates. This is pretty standard:

class Node

{

private Point point;

private Node left;

private Node right;

/// <summary>

/// Construct a node with the given point.

/// </summary>

/// <param name="p">Point.</param>

public Node(Point p)

{

Point = p;

}

/// <summary>

/// Get/Set the point associated with the node.

/// </summary>

/// <value></value>

public Point Point

{

get { return point; }

set { point = value; }

}

/// <summary>

/// Get/Set the right child of this node.

/// </summary>

/// <value>Node.</value>

public Node Right

{

get { return right; }

set { right = value; }

}

/// <summary>

/// Get/Set the left child of this node.

/// </summary>

/// <value></value>

public Node Left

{

get { return left; }

set { left = value; }

}

Our 2D trees are implemented by the following Tree2D class. The class maintains one private member rootNode which is the root of the tree. The constructor is pretty straightforward: it simply inserts all the points into the tree.

The Insert and Pick method implement the algorithm as previously described. Pick simply adds any matching point to the end of an ArrayList.

class Tree2D

{

/// <summary>

/// Root node of the 2D tree.

/// </summary>

private Node rootNode = null;

/// <summary>

/// Constructor with an array of points.

/// </summary>

/// <param name="points">

/// Array of points to insert into the tree.

/// </param>

public Tree2D(Point[] points)

{

if (points != null)

{

foreach (Point p in points)

Insert(p);

}

/// <summary>

/// Inserts a point into the 2D tree.

/// </summary>

/// <param name="p">Point to insert.</param>

public void Insert(Point p)

{

Node current = rootNode;

Node previous = null;

bool useX = false;

bool useLeftSubtree = false;

while (current != null)

{

// Should we explore the right subtree or the left subtree ?

useLeftSubtree = useX ? (p.X < current.Point.X) : (p.Y < current.Point.Y);

previous = current;

current = useLeftSubtree ? current.Left : current.Right;

useX = !useX;

}

// Insert the node

if (rootNode == null)

rootNode = new Node(p);

else

{

if (useLeftSubtree)

previous.Left = new Node(p);

else

previous.Right = new Node(p);

}

/// <summary>

/// Get the set of points which are in the given rectangle.

/// </summary>

/// <param name="rect">Rectangle to test points against.</param>

/// <returns>ArrayList of points within that rectangle if any, null if none.</returns>

public ArrayList Pick(Rectangle rect)

{

ArrayList pointsFound = new ArrayList();

RecursivePick(rootNode, rect, false, pointsFound);

return pointsFound;

}

/// <summary>

/// Traverses the 2D tree to find which points are in the given rectangle.

/// </summary>

/// <param name="rootNode">Root node of the tree to observe.</param>

/// <param name="rect">Rectangle to test points against.</param>

/// <param name="useX">

/// true if we should use the X coordinate at this level or the Y coordinate.

/// </param>

/// <param name="pointsFound">ArrayList collecting all the points found.</param>

private void RecursivePick(Node rootNode, Rectangle rect, bool useX, ArrayList pointsFound)

{

if (rootNode == null)

return;

// Should we analyze the left subtree and/or the right subtree ?

bool analyzeLeftSubTree = useX ? (rect.Left < rootNode.Point.X) :

(rect.Top < rootNode.Point.Y);

bool analyzeRightSubTree = useX ? (rootNode.Point.X <= rect.Right) :

(rootNode.Point.Y <= rect.Bottom);

// Analyze the left subtree

if (analyzeLeftSubTree)

RecursivePick(rootNode.Left, rect, !useX, pointsFound);

// If the point is inside the rectangle, add it to the result list

if (rect.Contains(rootNode.Point))

pointsFound.Add(rootNode.Point);

// Analyze the right subtree

if (analyzeRightSubTree)

RecursivePick(rootNode.Right, rect, !useX, pointsFound);

}

The previous class can be used with some equivalent of the following code, where points is an array of Point and pickRadius is the tolerance of picking (i.e. the region around the mouse pointer that is considered large enough to match a point and makes picking easier to use for the user).

Tree2D tree2D = new Tree2D(points);

ArrayList pointsFound = tree2D.Pick(new Rectangle(e.X - pickRadius,

e.Y - pickRadius,

2 * pickRadius,

2 * pickRadius));

By inspecting the algorithm, it is possible to see that the construction of a 2D tree with N random points takes 2N ln N comparisons on average. Range searching with a 2D tree seems to take about R + log N to find R points in reasonable ranges in a region containing N points. However, I have not analyzed precisely the complexity of search yet so I may be wrong. Any feedback is greatly appreciated. Observe that this method is optimized for situations where the number of points found R is relatively small.

It is possible to extend this method to three (or more) dimensions in a straightforward way: simply cycle through dimensions like we did for x and y while going down the tree.